Simulate ARM9 RAM starvation to fix DSi PictoChat - #2744
Open
puhitaku wants to merge 2 commits into
Open
Conversation
With ARM7 main RAM priority (EXMEMCNT bit 15), a BIOS CpuSet/CpuFastSet from the ARM7 into main RAM keeps the bus busy for the whole transfer and the ARM9 is starved. melonDS has no bus arbitration, so the ARM9 kept running at full speed. The TWL SDK relies on the starvation: its ARM7 startup zero-fills 0x02000000-0x022A0000 in 192KB chunks (one per VBlank) after the ARM9 title has started. Without it the ARM9 builds its heap inside the region being cleared and loses heap metadata. DSi PictoChat then fails WM_Init with a NULL buffer and shuts down with "Communication error". UpdateBusStarve() stops the ARM9 (CPUStop_ARM9BusStarve) when the ARM7 starts such a transfer of at least 4KB, and DecreaseARM7BytesToWrite() releases it once the transfer's bytes have been written. Interpreter mode only, at present.
CPUStop_ARM9BusStarve is saved with CPUStop, but ARM7BytesToWrite, the write count that releases it, was not. A state saved while the ARM9 is starved would leave it stopped forever after loading. Save the count too. This changes the layout of the NDS section, so bump the savestate major version.
Member
|
This is a hack hack specific to a single software, not sure whether we want to merge this. |
Author
|
Per-app hack switch may be a viable option I guess, like other emulators do, while I'm not sure that kind of feature is present in melonDS though. @RSDuck does it sound good to you? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #707
After some investigation, it turns out the data race between ARM7 and ARM9 was the cause of "Communication Error" in DSi PictoChat.
Chain of events
EXMEMCNTbit 15 (so ARM7 has main RAM priority). After that, ARM7 startup code waits for ARM9's "go" bit and zero-fills main RAM withCpuFastSetcall, one 192 KB chunk per VBlank.Fix
Instead of emulating bus arbitration, I implemented a simulation of starvation. When ARM7 issues a BIOS
CpuSet/CpuFastSetof 4 KB or more into main RAM whileEXMEMCNTgives it priority,UpdateARM9Starve()stops the ARM9. ARM7 consumes the bytes counterARM7BytesToWrite, and the ARM9 resumes when the transfer's bytes are written.Caveats
CPUStop; since that changes the NDS section layout,SAVESTATE_MAJORis bumped to 15.Testing
Refs
I've reviewed and modified every line myself after coding agent figures it out, and this PR is hand-written, but I'm pretty new to GBA/NDS world so things may appear strange. I'm eager to fixup those after a review. Thanks!