Ore ga Omae o Mamoru: hangs on white screen

[scurest]

The game Ore ga Omae o Mamoru (俺がオマエを守る) hangs on a white screen immediately after booting. The emulator freezes and can't be interacted with/closed.

This is printed to stdout

unknown arm7 read32 0126F05C | 0126F060
unknown arm7 read32 0126F060 | 0126F060
unknown arm7 read32 0126F064 | 0126F064
unknown arm7 read32 0126F068 | 0126F068
unknown arm7 read32 0126F06C | 0126F06C
unknown arm7 read32 0126F070 | 0126F070
unknown arm7 read32 0126F074 | 0126F074
unknown arm7 read32 0126F078 | 0126F078
...goes on forever...

Using commit 3f7bc1a.

[RSDuck]

no$gba seems to be affected as well, while desmume works.

EDIT 3: ignore all of what I've written, it's probably wrong There seems to be code being overriden on the ARM7ARM9 by a memset implementation at 0x20108b8. The length parameter in r2 seems to be far to much (over 2mb!). It is derived by subtracting the values located at 0x27FFDA0 and 0x27FFDC4. I suspect the problem is that these values are either set too early or too late, though neither disabling advanced bus emulation in desmume nor changing timing constants in melonDS seems to make a difference.

EDIT 2: the memset seems to be called with the same crazy value in desmume too. The problem has something to do with the memset itself

[RSDuck]

after some more debugging I finally have a conclusive theory about all of this: there's a memory area in main ram which during the beginning contains code executed by the ARM7. Later it is cleared for some reason by the ARM9 first with the value 0xbb then 0xcc (or the other way around). In melonDS and no$gba the ARM7 happens to still execute code in this region, while this mem(e)set operation is going. The value 0xbbbbbbbb is interpreted as a conditional branch to nowhere which is taken. The game boots if the ARM7 is sped up (e.g. by only adding a single cycle per instruction). EDIT: it also works if you slow down the ARM9 (kDataCacheTiming and kCodeCacheTiming = 10 seemed to work for me)

[Arisotura]

urgl. there is a similar timing issue with the aging cart on some DS emulators.

[RSDuck]

the english translation allegedly works fine https://www.romhacking.net/translations/5796/

[Illidanz]

@RSDuck we added a check for that bugged value in the translation patch, see here.

[RSDuck]

ah I was already wondering if the english text somehow took longer or slower to load which changed this unintentionally

[ghost]

Still fucked. With JIT on the entire emulator crashes. With it off the game instantly hangs on a white screen.

[Arisotura]

after some more debugging I finally have a conclusive theory about all of this: there's a memory area in main ram which during the beginning contains code executed by the ARM7. Later it is cleared for some reason by the ARM9 first with the value 0xbb then 0xcc (or the other way around). In melonDS and no$gba the ARM7 happens to still execute code in this region, while this mem(e)set operation is going. The value 0xbbbbbbbb is interpreted as a conditional branch to nowhere which is taken. The game boots if the ARM7 is sped up (e.g. by only adding a single cycle per instruction). EDIT: it also works if you slow down the ARM9 (kDataCacheTiming and kCodeCacheTiming = 10 seemed to work for me)

looking back on this, it seems to be related to concurrent mainRAM access