Homebrew Why are DS roms bigger than real memory?

[ethanpet113]

I've noticed that the nintendo DS only appears to have 4mb of real memory, but the size of roms seems to well exceed this. I was working on some homebrew and wondering how this is handled because I only know how to address real memory and load things from the fat filesystem.

 

[Rydian]

Well if your resources need to change (or be user-editable) then loading from FAT is used, otherwise you can just use the nitro filesystem (like ROMs use) to access resources embedded in the .NDS file. NitroFS, I think it's called (no experience with it so not sure what to link).

 

[Kyohack]

EDIT:
Rydian beat me to it!

It's been a while since I've done anything homebrew-related on the DS, but I might be able to answer your question.

Your ROM isn't entirely loaded into RAM. The arm7 and arm9 binaries are loaded into RAM, and any needed overlays are loaded (overlays can include files and data, from what I understand.) If you have files that are needed by your homebrew, you can access them from the SD card filesystem (which is the fat filesystem that you mentioned), or you can load them via the nitroFS filesystem. I believe the nitroFS is what you may be looking for. Here's some more information on that: http://blea.ch/wiki/index.php/Nitrofs

DevkitPro includes an example of how to use the nitroFS: http://libnds.devkitpro.org/a00067.html

And if it interests you, here's a list of other devkitPro examples: http://libnds.devkitpro.org/examples.html

 

[FAST6191]

3 methods if you count the homebrew ones and want to advance beyond includes in the binary.

1) DS filesystem stuff. The DS cart protocol is annoying but doable (the popular hacking tool ndstool is actually part of devkitpro). I would not suggest it for homebrew for various reasons including it is likely to be read only unless you can otherwise argue against it.

2) GBA RAM. 32 megs from 08000000 to 09FFFFFF in memory is available. Used also in the case of ram expansions. Some older flash carts (these days most notably the EZ4) will load into RAM first before launching which troubles some things like tetris grand masters which ended up in the 50 megs range though this is technically part of 1).

3) DLDI and related methods. Here files are fetched from the SD card as per normal SD reading procedure ( http://chishm.drunkencoders.com/DLDI/ ). Related methods include the older nos_gba_fat I think it was and possibly pafs (part of the now deprecated PAlib) though I am not sure what that actually really was and you do not want to be using it anyway (issues with support). If you are so inclined you can stick an image of the would be fat filesystem that contains all your and attach it to the resulting DS file (it is called FCSR if you decide to go searching). Additionally later DLDI patches and the better supported carts got access to an additional feature called ARGV (more in the form of a workaround for those that lack it http://devkitpro.org/wiki/Homebrew_Menu ).

All three can interplay in various things (aside from DS roms which only do 1) save for the browser which has RAM support). Commercial DS games additionally use overlays (small binary fragments compiled for given addresses and loaded in whenever necessary) and I have even seen games use them almost exclusively rather than more conventional files.

If it was not already clear unless poor obfuscation is your aim the DS filesystem and such like are vastly inferior methods to DLDI.