@xenic
I'd lost google search during last monts but now works again for me.

In my experience with SAM460LE, I'd use a R7 240 (Orland Chipset ) low profile but have some issues with Radeon HD driver 3.x, sometimes my system hold. When I'd update to Radeon HD v5 all works great and get better performance, tested with Warp3DNova and Novabridge working without issues.
VideoDecoding hardware works great with 720p videos, HD videos need RadeonRX.
In my experience if you have Radeon SI grfx card with Cape Verde chipset you can use RadeonHD 3.x without issues, but with other chipset like Orland, RadeonHD V5 works better, at least with SAM460LE.

Now I have an X5040, but when I'd use SAM460LE RadeonV5 driver for SAM not have GART enabled (RadeonHDv3 on SAM not support GART too), I don't know if today this feature is enabled. When this feature is enabled grfx card theoricaly works faster because enable caches for data transfers gfx card with SAM system.
Other systems with PCIe support GART by default, its a limit only with SAM systems.

Today google search works again for me with ibrowse 3 and Odydssey 1.23r5

Using old guides you can configure Lightwave 5 for work with AOS4 with old graphic cards but some things lose when you try to use with RadeonRX or RadeonHD cards. Few months before finally I can configure Lightwave5 on OS4 fully working with preview render feedback, preview animations , rtg out and modeler connection.
I'll try tomorrow make a post here explaining how to config for newer cards.

https://www.youtube.com/watch?v=Hv-LQaLynYs

Exist any version of E-UAE for use MIDI serial or rediret to CAMD in OS4?. I'd try to find serial parameters in E-UAE but not found.
I have Yamaha Midi generator conected throught USB-to-midi in OS4.

I have same error after install Odissey3a and move their own libs to libs: it's an error, after that emotion fail.
Solution I'd remove Oddisey3a libraries from libs: , restore public clib4 in libs: and avcodec.library and left odissey3a libs in their own folder.

Now emotion works again included with videovortex.

Awesome month of news for AmigaOS4.

@jabirulo

I´d move to libs: . I´ll try restore my old libs and left Odissey 3 libs in progdir:libs/ and try again.

Update: I'd remove all Oddisey 3 libraries from libs: and restore public clib4 into libs and Emotion now works good again, it's not a problem of upd3.

I think I have problems with Emotion after update3, now emotion crash and some videos play but when close I receive error "emotion decode thread".
Really I'm not sure if its a problem with update3 or after install Oddisey alpha 3.

@Gregor

X5040

My keyboard (silicon graphics usb keyboard) blink 3 times light during boot up with upd 2 and upd 3.

I updated my X5k via Amiupdate without problems. First reboot not works, I need power off and power on and all works fantastic.

Now at Os4depot https://os4depot.net/?function=showfile&file=graphics/edit/pixy.lha

It's a small update, only critical bugs, and new free register key system.
In alpha/beta testing period of time Pixy will be free to register, only go to shareware when final release arrived.

https://www.youtube.com/watch?v=dqIjzlU0Aik

After few weeks talking with Sinisrus about how to continue with Pixy development and trying to find a solution finally we have reached a collaboration agreement where I'm to continue with Pixy development.
In few days I'll upload new alphaR6 and I hope a new version in few months.
Pixy It's Alive!!!, again

I'm usign last Ibrowse 3.0 Build 30.08 (22.12.2023) and not have problem using Google for search

@TheMagicSN

Thank you all for the collaboration you've been demonstrating recently between the MOS and AmigaOS4 communities to bring new titles to our systems.
We all win with these cross-community collaborations; in the end, we're all Amiga fans.

Recently I test SeriusSam in MOS a really works good and take advanced advantages of recent versions of TinyGL.

I'm looking forward to seeing SeriousSam working on my AmigaOS4.

I've always heard that the new Ehanced commands don't solve the old bugs and generate new ones.

I remember the first multiprocessor implementations in the era of MacOS 7 and Windows NT to XP. Usually use a MP library for some apps that's really send diferent task of aplication to diferent processor, really was't multithread or multiprocesing system simply manage diferent parts of app to the next free cpu.
Some apps like Lightwave can run on multiple processors but speed of render not was 2 or 4 times faster only increment around 20-30% with 2 processors and 40% with 4 processors. But if you launch multiple instances of lightwave on old Windows NT-XP every instace of app launch to different procesor.
For example If you have 2 processors and launch 2 instances of Lightwave and send render task, every render task was running on diferrent cpu, this give you double speed rendering but you need double of ram to run two times the same app. If you load only one Lightwave and send render task to Multiprocesor libraries you only obtain 20-30% of increment in render speed.

Today with modern OS multiprocesing and smpt apps really works but was a fake multiprocesing apps and OS in the era before Windows 7 and MacOSX.
An implementation like older OS and apps that simply send new tasks to next free core or the core with less workload It should be possible without making a change to AmigaOS that could cause incompatibilities and break system for existing apps. This is not the best multicore architecture but it can be a useful implementation for Amiga NGs with multiple cores. Adding a new Multiprocesor.library that can help you to send diferent task of new apps to different core can be usefull for new apps or games, for example if a game with an multiprocesor library in mind detect more than one core, can send IA of game to one core and the other task of game to other core and left main core free for OS.

I'm not an experienced developer, all of this is based on my experience as a user with multiprocessor computers in the 90s and 2000s. The early implementation of multiple processors for MacOS and Windows was easy because they did it this way and it didn't interfere with all the applications that were already developed without multiprocessing in mind. As Hans say, simply send every app to the next free core help user experience without make radical changes in the AmigaOS. It is a very crude implementation of the multiprocessor for the OS but should be easy and fast to implement than new OS with real multithread manager.

As prosisional way and until I'll found a solution I'd take X1550 graphic card for 7 euros in second hand maket with only pasive cooling system ( a disipator without blow ), I apreciate the quiet sound of my X5000.

After some testing in MOS really I'm not apreciate significative lost of performance X1550 vs X1950 card. I'm suppose that our Amiga techologies for 3D not use specs of this graphics card at 100%.

@afxgroup

It's a great news for all SAM460 owners, better news when it's available. Congratulations for Hans, he resolve an endemic and historical problem with coherence caches in SAM systems.