Game freezes when attempting to access 0x023FFFAD (stylus down)

[jonko0493]

Hi!

I'm working on a game translation project and we added a little homebrew hack to allow players to skip opening logos with A/B/Start/stylus press. This has been tested on hardware and works like a charm and also works in DeSmuME, no$, DraStic, and melonDS 0.9.3.

However, in melonDS 0.9.4, the game freezes right before this code is executed, regardless of whether built-in or external BIOS/firmware are used. The culprit seems to be a memory access attempt to 0x023FFFAD (a common location for the stylus down state in memory) as removing that memory access makes the game work without issues as before.

ARM assembly snippet:

I also built melonDS from source and confirmed that this behavior is still present.

Thank you for your help in advance!

[Arisotura]

I fail to see why reading that particular byte in mainRAM would cause a freeze, other than maybe some problem with PU emulation.

does the freeze also happen with the JIT on?

if it does, we will need to find out which commit introduced this problem. can you share an example ROM that reproduces the issue?

[jonko0493]

Just tested with JIT on and the freeze still occurs. The game is Suzumiya Haruhi no Chokuretsu and for sure I can share something for testing -- do you mind messaging me on discord and i'll send you a patch? I'm Jonko#0493 there.

[Arisotura]

'aight!

[jonko0493]

Talked with Arisotura on discord and we determined that this is a PU region issue. I've done a series of experiments to try to help with some data:

c5,c0,2	PU Region 1 (c6,c1,0)	PU Region 2 (c6,c2,0)	melonDS Behavior	Console Behavior	Notes
15115011 (R1=read, R2=noread)	0200002B (02000000-02400000)	023E0021 (023E0000-02400000)	Freezes after first logo displayed (when region 2 is first accessed)	Plays without issue	Default game behavior
15115111 (R1 & R2=read)	0200002B (02000000-02400000)	023E0021 (023E0000-02400000)	Plays without issue	Plays without issue	mcr c5 routine replaced with a direct assignment
15115011 (R1=read, R2=noread)	0200002B (02000000-02400000)	023E0021 (023E0000-02400000)	Freezes after first logo displayed (when region 2 is first accessed)	Plays without issue	mcr c5 routine replaced with a direct assignment
15115001 (R1 & R2=noread)	0200002B (02000000-02400000)	023E0021 (023E0000-02400000)	Freezes on startup	Freezes on startup	mcr c5 routine replaced with a direct assignment
15115011 (R1=read, R2=noread)	0200002B (02000000-02400000)	0200002B (02000000-02400000)	Freezes on startup	Plays without issue	mcr c6,c2 assignment value replaced
15115111, 15115101 (R1&R2=read; R1=noread, R2=read)	023E0021 (023E0000-02400000)	0200002B (02000000-02400000)	Freezes after third logo	Plays normally except second logo is not displayed and severe audio/video lag	15115111 assigned before first logo, r1 & r2 swapped after first logo, 15115101 assigned after second logo

My read of this is that with overlapping regions, the region with write access takes precedence. This runs counter to the GBATek explanation:

Overlapping Regions are allowed, Region 7 is having highest priority, region 0 lowest priority.

Can provide samples for all of these states.

Edit: updated table since I messed up my initial testing by still having JIT enabled.

[poudink]

How can this be a PU issue if this still happens with the JIT on? Isn't support for that only available in the interpreter?

[RSDuck]

I never tested it, though I think PU exceptions should happen even with JIT if they're caused by an indirect jump.

[Arisotura]

That's interesting. I will have to test this on hardware in a homebrew setting... either there's something fishy with the PU implementation in the DS, or the game has a particular exception handler.

[Arisotura]

I did, and my test homebrew crashes on hardware, just as I'd expect. So if I were to guess, I'd say the game is using some specific exception handler and that's not being emulated correctly. Interesting.