creating a DLDI patch extractor.

[vuurrobin]

no idea where to put this, user contributions didn't looked right, and seeing as dldi is part of libfat, I putted it here >.<. move when needed.


hello,

seeing as pretty much all cards firmware auto-patch the homebrew games, and to use the homebrewmenu as the default menu you need the dldi patch, I decided to try and create an dldi patch extractor. or has one already been created?

now if I understand correctly from reading the source code of dlditool and homebrew menu, the patch should be in main memory, start with magic string "\xED\xA5\x8D\xBF Chishm" (4 byte number, 7 byte string and 1 byte terminating null character), is DO_driverSize long with a maximum of 32KB (DO_driverSize is the pointer to the magic string + 0x0D). is this right?

then I can just copy all of it to a file, right? is there anything else I would need to do?



crossposted this with gbadev.

[WinterMute]

Funnily enough I wrote such a tool while messing with hbmenu, I just committed it to devkitPro SVN.

svn co https://devkitpro.svn.sourceforge.net/s ... ldiextract

Some cards have DLDIs that won't work with hbmenu unfortunately, these have been compiled with arm9 specific instructions which fail when run on the arm7.

[vuurrobin]

that wasn't there before...

I tried it, and it works. the homebrewmenu already worked when using it with my normal DSTT menu, so the patch works on arm7. I already patched the homebrewmenu with the patch (which wasn't as easy as one would think), changed its name to TTMENU.DAT so that my card would execute that on startup and I can succesfully play games with the homebrewmenu .

thanks.

[WinterMute]

When I said I just commited to SVN, I quite literally meant just then :p

What do you mean "wasn't as easy as one would think"? It's really just a matter of running dlditool with appropriate parameters.

FWIW, a simple rename won't get you the exit to menu functionality, you can either add patch the bootstrap with your dldi or change the name of the default file to TTMENU.DAT in the bootloader code.

[vuurrobin]

What do you mean "wasn't as easy as one would think"? It's really just a matter of running dlditool with appropriate parameters.

...and in the right order, because I somehow managed to patch the dldi file instead of the nds file .

FWIW, a simple rename won't get you the exit to menu functionality, you can either add patch the bootstrap with your dldi or change the name of the default file to TTMENU.DAT in the bootloader code.

I'l try to get the return to menu working tomorrow.

[vuurrobin]

yay for double posts...


I tried the exit to menu without changing the bootloader, and the program locks up instead of returning to the menu. maybe it would be better if the ds would shutdown if the menu can't be found.

I then tried to edit the bootloader, and apparantly the name of the menu needs to be exactly 12 characters long, or else it also locks up instead of returning to the menu. and filling a smaller name up with null characters didn't help either. not sure what is causing this.

I also tried the return to menu from some older programs (like DSOrganise, pocket physics, and anguna), and it didn't work at all. I asume that they overwrite the bootloader since they were created with older devkitPro toolchains.

I also notised that the menu would show some names of files and directories in upper case while they are lower case. a bug in libfat?

how hard would it be to get an array in the bootloader that you can modify from the homebrewmenu code? because then we can pass the name of the menu (which should be argv[0]) to the bootloader, as well as aditional arguments, like the last directory the menu was in.

[WinterMute]

I tried the exit to menu without changing the bootloader, and the program locks up instead of returning to the menu. maybe it would be better if the ds would shutdown if the menu can't be found.

Um ... it does, assuming you're using latest libnds.

I then tried to edit the bootloader, and apparantly the name of the menu needs to be exactly 12 characters long, or else it also locks up instead of returning to the menu. and filling a smaller name up with null characters didn't help either. not sure what is causing this.

Yes, the bootloader can only use DOS filenames (8.3), it's a vastly cut down libfat so we can get it to fit in small places.

I also tried the return to menu from some older programs (like DSOrganise, pocket physics, and anguna), and it didn't work at all. I asume that they overwrite the bootloader since they were created with older devkitPro toolchains.

Not sure what you mean here, how would you expect code built with older toolchains & libs to exit to the menu?

I also notised that the menu would show some names of files and directories in upper case while they are lower case. a bug in libfat?

the upper case filenames are those in 8.3 format which have no lfn entry, not 100% sure how that's normally dealt with - vfat is case insensitive but case preserving which leads to all sorts of interesting weirdness.

how hard would it be to get an array in the bootloader that you can modify from the homebrewmenu code? because then we can pass the name of the menu (which should be argv[0]) to the bootloader, as well as aditional arguments, like the last directory the menu was in.

Not really sure offhand, in theory relatively easy, in practice maybe not so much. If hbmenu is used as a replacement "firmware" then it's argv[0] won't exist.

[vuurrobin]

Um ... it does, assuming you're using latest libnds.

I am using the latest devkitARM and libnds, and programs shutdown if no bootloader has been set. but if it has been set, but tries to execute an nds file that doesn't exists, it freeses.

Yes, the bootloader can only use DOS filenames (8.3), it's a vastly cut down libfat so we can get it to fit in small places.

too bad. but guess it can't be helped then.

Not sure what you mean here, how would you expect code built with older toolchains & libs to exit to the menu?

not sure. I just wondered if it was possible and posted here in case someone else was wandering it to :P .

Not really sure offhand, in theory relatively easy, in practice maybe not so much. If hbmenu is used as a replacement "firmware" then it's argv[0] won't exist.

if argv[0] doesn't exits, then you can just use a default name like its using now. and argv[0] will be present when using the bootstrap program.

I think that the hardest part is correctly recognising the array in the bootloader and making sure that the arguments are in a valid memory place once the menu has started.