If you can run the demo program in an emulator (such that you can play the game) or your flash cart has savestate options then grab one of those. Less useful here it seems.īanner is going to be things like the icon and the text the DS sees to tell it what the game's name is in the menu. These are usually flanked by overlays (for the ARM9) which are snippets of code that get swapped in and out of memory as they are needed, though for something like this were you don't want to expect new code to come in from somewhere else then not likely to be seen.īoth useful when you have a lot of files to parse which is most ROMs, and a lot of download play options. Basically a library - you can usually swap ARM7.bin files between ROMs of a similar vintage and nothing will change, or indeed you might sometimes fix anti piracy in a few things. Ostensibly it is for code but any number of graphics, text, levels, music and more have been fished out of them over the years, and download play files are even better candidates.ĪRM7.bin. The workhorse of DS commercial games (some homebrew went other ways) and what contains the main code for the game. Might still be all the same names but different data.ĪRM9.bin. That said I would also pull apart the contained NDS file in that to see what it contains - if the kiosk demo is in fact the kiosk program (they ran on a DS put in a box) then it might be the nds file (in other things you might see utility.bin and a few other names/extensions) they sent over contains the good stuff. Things could well be stuck in the ARM9 as well, not sure what compression it would use (it might be the normal LZ but it could also be the BLZ binary compression, might also be sub files contained within and extracted to VRAM when they are needed but compressed normally) Most download play things are packed pretty tightly as you have what 4 megs of RAM to do anything with (does not sound like much but consider that the original GBA games were 8 megs each).
0 kommentar(er)
