|
| Home | Downloads | Screenshots | Forums | Source code | RSS | Donate |
| Register | Log in |
| < melonDSi beta releaseStatus update > |
|
When things turn out unexpectedly simple Oct 20th 2019, by Arisotura |
|
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:  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 |
| 36 comments have been posted. |
| < melonDSi beta releaseStatus update > |
| Pages:123 |
|
Rodrigo says: Oct 29th 2019 |
| Is it possible to make an Android port of MelonDs (U) MelonDsi? |
|
MelonMan says: Oct 29th 2019 |
|
Rodrigo: Someone tried it but I think it is discontinued. https://github.com/rafaelvcaetano/melonDS-android |
|
DizzyPatron says: Nov 1st 2019 |
| Not sure if it has already been asked or not, but will MelonDS eventually include a way to use AR codes and other cheat codes? I don't think it currently has one, does it? |
|
MelonMan says: Nov 1st 2019 |
| DizzyPatron: It is in the todo list, so it might be supported in 0.9 or something. https://github.com/Arisotura/melonDS#todo-list |
|
MelonMan says: Nov 1st 2019 |
|
I dumped initmem7 & 9 (dsidumper) and firmware.bin(dsbf_dump)from my 3DS using TWLMenu++. They are both 15 KB. Are they OK? |
|
MelonMan says: Nov 1st 2019 |
|
Ok, initmem is mostly filled with 00 00 00..... firmware.bin is mostly filled with FF FF FF Oh, well. Back to the drawing board. |
|
poudink says: Nov 1st 2019 |
| I don't think the 3DS has the DSi firmware. it has part of it for the DSi system settings but not sure if it has everything. |
|
kevincrans says: Nov 2nd 2019 |
| Since JIT beta builds are almost ready, I have a feature request for the TODO LIST FOR LATER. If an Android/Switch port is on the Agenda, Windows 10 runs also on Snapdragon(ARM64) emulating x86 (32-bit), while Chromebook runs x86 and x86_64 Android apps, so remember to take things one step at a time, so you can reuse code. Maybe porting to Android or Switch is easier that way. Originally I intended write my post about Vulkan, but decided not to. Thank you for reading and good luck with the development of MelonDS emulator! |
|
luanzito says: Nov 3rd 2019 |
|
Hey, I have a suggestion (actually i want to ask something): Is it possible to desynchronize the ds time with the pc? You could add a option to set your own time setting, I use to do Pokémon RNG and the DS clock is really important. Currently I can't do it on pc because there is no emulator that let you change the date and time. |
|
poudink says: Nov 3rd 2019 |
| I mean there's a switch/android port being made but not by arisotura |
|
kevincrans says: Nov 3rd 2019 |
| My apologies, I thought that one was inactive. In that case, I have a feature request for the TODO LIST FOR LATER besides JIT for all related platforms. Vulkan is available on Nintendo Switch, Linux, Android, Windows (and even on Mac according to Wikipedia). For your information: Vulkan 1.0 supports Android 7, Android 8 and 32-bit in general, Vulkan 1.1 does not, so I recommend Vulkan 1.0. If you will implement this, this will be the second huge performance benefit for all platforms besides JIT. I really hope the JIT beta builds will release soon, I'm really excited! |
|
MelonMan says: Nov 4th 2019 |
|
Switch port made by hydr8gon. https://github.com/Hydr8gon/melonDS |
|
poudink says: Nov 4th 2019 |
| I think RSDuck's fork of the Hydr8gon port is more active. |
|
poudink says: Nov 4th 2019 |
| oh also, vulkan doesn't necessarily mean performance boost. It might not make much of a difference at all in this case. |
|
kevincrans says: Nov 4th 2019 |
| I agree on that one, I'm running it on a high-end PC, but if you're running it on a low-end Android phone with OpenGL ES vs Vulkan, that's where the whole idea is for. It's not that stupid for a long-term goal with cross-compatibility in mind. |
| Pages:123 |