Vanfanel wrote:However there are lots of games not working in these "experimental" versions as you know.
I spent a few days looking at it and although I'm no closer to finding the root cause, it is definitely IRQ related. None of the IRQ code has changed since 2.50, with the exception of moving the private IRQ stack to a private Dynamic Area. A few things I spotted whilst debugging:
- A specific instruction in the JIT exit code is being overwritten with the Hypervisor instruction. This is causing some of the crashes
- irq_R13 which normally points to the private IRQ stack is sometimes being changed back to the actual IRQ stack. This is causing the remainder of the crashes
Both are random though and occur without fail on the Pi and seldom on RO5 SA under emulation. Inferno for example is now working on RO5 SA, but hangs on the Pi.
Its frustrating trying to track it down, so I've switched to testing games for the time being in the hope I'll have a brainwave as to the cause, or how to track down the root cause.
Speaking of brainwaves, whilst testing Drifter yesterday one of the issues causing it to break was a reliance on the CPU pipeline that I couldn't fix at runtime. After a few hours pondering a solution, I realized that with a few additional instructions in the Abort handler I could partially add CPU stage 2 pipeline support - certainly enough to get Drifter to work:
Updated Modules and obey.zip on the dev site, which get
Drifter running. It's hanging when you quit the level, which only occurs on RO5, so there's possibly another SWI that behaves differently under RO5.
Incidentally, the fix for The Last Ninja was a bug that relied on a quirk of RO3.71 (and below) OS_SpriteOp 36 (set Pointer) to work. I'd already applied a fix for this to get a few other games working, but it appears there are two issues in OS_SpriteOp 36. The implementation was changed in RO5 to match the PRM exactly and it's this that's broken quite a few games.