This may be implied and/or obvious, but I would create a wrapper so you can easily swap out nocashWrite with printf for troubleshooting on real hardware. Emulators tend to be more forgiving than hardware so you will want to periodically test on hardware too.
It is possible to create dsi compatible homebrew that take advantage of the extra memory and increased processor speed. The new WiFi may not be supported but the rest of the system is very much the same as the ds. There some minor difference but for the most part they are the same. For example...
Adding 3in1 support is possible, but it more complicated than just initializing and making the memory available. The memory does not support byte reads or writes - only 16 bit reads and writes. Not insurmountable but plenty of places where it can go wrong as the compiler can add byte...
I started looking at it but I have been super busy lately. I had planned on responding after I had a better idea as to what is involved … but I never got that far. The “snubbing” was not intentional. I do plan on looking at it some more but I am not sure when I will have time.
I think the music issue is that the nds music code was taken from the heretic port. The issue being that the doom music and the heretic music play at different rates. So it sounds horrible. I vaguely recall pointing this out at the time but no one ever fixed it.
I started looking at this and I ran into a few issues ... flushing the cache and the signed/unsigned sample conversion to name a few. and then I ended up just making a simple streaming only example. not what you asked for but it seemed like fun.
this example uses a larger playback buffer - and...
If you are using the standard devkitpro makefile then add this to LIBS
#---------------------------------------------------------------------------------
# any extra libraries we wish to link with the project
#---------------------------------------------------------------------------------
LIBS...
The libnds OpenGL wrapper is fairly good for simple usage. But the ds 3d is quirky enough that in almost ever case creating something to target the ds hardware directly is going to be a better solution.
Memory pit does not reset the sound capture hardware. This cause memory corruption and crashes. The latest version of twilight menu++ is supposed to address this issue.
hardly conclusive, but without this version of memcpy the first level sits bounces between 20 and 21. with this version it stays steady at 20. either way it does not seem to impact performance much.
I did create a new build where I changed the makefile to generate arm code instead of thumb code...