When things turn out unexpectedly simple
As I said in the previous post, melonDSi can't boot any DSi-enabled cart. I'd been banging my head against the problem for a long while, attempting to work out how the launcher on the ARM9 worked and why it was failing, but went nowhere. The code is a pain to track, relying on all sorts of threads and callbacks and things.

Shows that taking a break does wonders.

Just yesterday, I idly looked at that bug again. Reproduced the freeze, then pressed F11 (debug key printing some status to the console) a few times to see if I could see a pattern. The ARM9 seemed to exhibit typical 'idle thread' behavior; the ARM7 however, seemed to get stuck in a loop. A quick glance at my IDB of the firmware code confirmed this:

AES wait routine

If you aren't fluent in ARM assembly, this function waits for the AES engine to finish whatever crypto operation it is doing, by checking the busy flag in AES_CNT.

But, in our case, the ARM7 got stuck inside this because, somehow, said busy flag remained set forever.

Some logging of AES operations shown that, while loading the game, the firmware would start a decrypt operation with a block count of zero. melonDSi didn't check for that case, and instead waited for data input that would never come (heh), causing the busy flag to remain set forever. You guess how this goes.

After quickly fixing this bug, I tried loading a cart game again. It still froze on a white screen, but the logs showed it was getting further. In particular:

UNIMPLEMENTED ARM9 NDMA3 START MODE 04, 04100010->021153A0 LEN=1 BLK=1 CNT=A4044000

That meant the game was actually booting, and attempting to load its data, using NDMA ('new DMA' implemented in the DSi) for whatever reason. NDMA start mode 04 is for cart slot DMA, which is triggered every time a data word is transferred from the cart.

This was quickly taken care of, too. A bunch of the NDMA start modes mirror those of 'old' DS DMA, so I just hooked those into the functions responsible for taking care of DS DMA. The only one that needs more extensive checking is GXFIFO mode, since it has a maximum block length of 112 words, I'm not sure how that interacts with the block subdivision system of NDMA.

Anyway, with this, I was finally able to boot DSi-enabled games.

Nothing terribly exciting to show tho. After all, most of the DSi-enhanced games out there don't have much extra features other than making use of the DSi cameras, so we have to do something to emulate them.

Loading DSi ROMs is also a bit finicky as they have to be one specific way for it to work (right now, with the DSi-specific data encrypted). And, some of the ROM dumps out there lack the DSi-specific data, so it would be good to add some verification and warn the user if their ROM is a bad dump.


Speaking of which, I am thinking of the ways I can make this evolve, now that it's atleast working to some extent. Namely:

* lowering the entry barrier, that is, upgrading dsidumper to dump all the required material in one go

* getting rid of some of the required files. boot2_7/9.bin can be sourced from the NAND directly, provided I can find a way to derive the required decryption keys. initmem7/9.bin could be made optional, the required data can also be sourced from certain particular BIOS dumps (the ones that NO$GBA requires) (and dsidumper could also be upgraded to produce such augmented BIOS dumps). Not sure about aeskeys.bin.

* rewriting the trainwreck that is the SD/MMC controller code. As an example, Flipnote Studio tends to softlock while saving due to bugs in that code. It was written mainly to get things working, and it shows, but now that we know that things are working, we can afford to rewrite it cleanly. Some other DSi parts (AES engine, ...) could use some cleanup, but they aren't as bad.

* adding features such as cameras and wifi connectivity

* ability to direct-boot DSi games, and work out something for DSiware

* the holy grail, eventually, merging all that back into regular melonDS
Saizo7 says:
Oct 20th 2019
Awesome work! Can't wait for you to tackle wifi connectivity!
ChaosEternal says:
Oct 20th 2019
Oh man, that's super cool! I love hearing about the technical details of this stuff.
MelonMan says:
Oct 20th 2019
That's good to know, I might be able to run it then. Thanks for your efforts. Question - can we run TWiLight Menu ++ because I'm pretty sure that it can run on a DS.
poudink says:
Oct 20th 2019
as far as I can tell, melondsi can only run the DSi firmware and dsi-enhanced games, and since twilightmenu is more of a replacement for the firmware, I don't think it'll work yet.
Jinkson says:
Oct 21st 2019
melonDS is quickly becoming the premier DS emulator. Is there any info on the roadmap for ARM dynarec? Getting fullspeed melon on raspberry pi or the Switch would be a dream.
MelonMan says:
Oct 21st 2019
I have an rpi 3b+ so I could do some testing if it ever came out.
MelonMan says:
Oct 22nd 2019
And I think an arm64 JITis being worked on.
poudink says:
Oct 23rd 2019
the x64 jit isn't even done. I doubt they've started an arm64 jit.
Comlud says:
Oct 24th 2019
Oh! Happy to see solutions coming up! Keep it up!
AsPika2219 says:
Oct 24th 2019
I hope all DSi games will playable very sooner! :D
Generic alias RSDuck says:
Oct 24th 2019
an arm64 dynarec already exists. It's already in use in the unstable switch release made not too long ago. https://github.com/RSDuck/melonDS/tree/switch
MelonMan says:
Oct 24th 2019
Will DraStic becoming open-source help melonDS in some way?
poudink says:
Oct 25th 2019
oh wow, that's nice.
Sigma says:
Oct 26th 2019
Just in case you didn't know, there are some DSi exclusive cartridges apart from the DS-compatible games that can use the camera. They aren't really all that relevant or demanded, but I thought you might like to know and see if they can be run on the emu at some point. Also, I'm really excited for the whole DSiWare thing! I still remember playing Four Swords on the DSi.
WarSlay says:
Oct 26th 2019
Incredible work!!! ur amazing dude,
this is that we waiting for several years!!
Post a comment
Name:
DO NOT TOUCH