commit b022181a05eabb34efb9305a823282d6852fb6be (latest commit as of writing)
Issue
Starting with libnds v2.0.0, the DMA utility functions are using u16 to read and write from the DMA control registers. This behaves really weirdly; there seems to be some race condition when reading via u16 to check whether DMA is currently running. After looping through several DMA copies, it randomly crashes with YOUR GAME IS BOGARTED!!! PLEASE REPORT!!!, but I don't see any particular issue in https://github.com/devkitPro/libnds or https://github.com/devkitPro/calico.
Testing the same build below with DMA controls being accessed as u32 doesn't seem to exhibit the crash.
It should also be noted that all of this works on real hardware as well, tested using an original R4.
You may find an example below:
Set Slot-1 to R4
Extract provided zip (the root of the zip is the root of the "SD card")
Run akmenu4.nds, enjoy crashing in less than 10 seconds
I've also attached a different version of akmenu4.nds using u32 DMA control access. Previous files in the initial zip is required on the SD still.
akmenu4.zip
State your operating system:
Windows 10
DesMuME version
commit b022181a05eabb34efb9305a823282d6852fb6be (latest commit as of writing)
Issue
Starting with libnds v2.0.0, the DMA utility functions are using u16 to read and write from the DMA control registers. This behaves really weirdly; there seems to be some race condition when reading via u16 to check whether DMA is currently running. After looping through several DMA copies, it randomly crashes with
YOUR GAME IS BOGARTED!!! PLEASE REPORT!!!
, but I don't see any particular issue in https://github.com/devkitPro/libnds or https://github.com/devkitPro/calico.Testing the same build below with DMA controls being accessed as u32 doesn't seem to exhibit the crash.
It should also be noted that all of this works on real hardware as well, tested using an original R4.
You may find an example below:
akmenu4.nds
, enjoy crashing in less than 10 secondsdma16_example.zip