ROM Hack How to add DLDI?

[Takaishi]

Hi, i want to know how to add DLDI support on a homebrew.
tnx

 

[FAST6191]

DLDI is the feature added to recent builds of libfat and gba_NDS_fat, gba_nds_fat is the old version so unless you are adding to an app that already uses GBA_NDS_FAT might I suggest using libfat.

It comes as part of devkitpro/devkitarm but you can get it as a seperate download here, there is also a short tutorial there:
http://chishm.drunkencoders.com/libfat/index.html

If you are adding to an already existing app you did not make really you need source code, also check it has not already been done:
http://forum.gbadev.org/viewtopic.php?t=12146

 

[Takaishi]

ok, but, wich code i need to add to my main file, or to the makefile,..or where?

 

[chuckstudios]

In your Makefile, you need to add the flag -lfat to the LIBS line, it has to go before -lnds9.

In your program, you first have to call fatInitDefault(); to start the FAT access. Then you use standard stdio functions like fopen, fread, fwrite, and fclose to do file input and output.

 

[Takaishi]

Excelent, that just what i needed. Thank you chuckstudios, FAST6191

 

[FAST6191]

Edit, far far too slow hitting reply and seemingly wrong. Oh well.

Sorry if I sound insulting, I assure you it is not my intent. DLDI is a feature of the libfat library (which acts as a go between for the DS and a flashcart, as I mentioned already GBA_NDS_FAT was the previous library most used to pull this off but it has since been dropped) that allows you to read contents on the FAT, as new carts appear and each seperate cart has different (often mutually incompatible) methods of accessing the FAT DLDI was born/adapted from a similar concept used in moonshell. It works by adding a small section of blank space (32KiB if I recall), adding a specially crafted read (and hopefully write) patch and then "calling" it every time FAT access is required.
As such you include it like any other library and call the functions it provides (you have to mount it before reading if memory serves and it is generally considered wise to unmount afterwards), the tutorial explains it far better than I can.

I am not so familiar with C? languages and makefile stuff in general but the makefile is really only needed for DLDI if you want it prepatched for a given cart and do not want to do it yourself (as I understand it you can add command line actions to them).

As for how you would want to add it if you are writing an app I can not say how you would want to do it: that is your call. In my opinion it depends on whether you are making an emulator/media player type app or a "game" type where only the textures/levels/sounds/monkey pictures are read into memory.
If it is the former then I suggest tying it into a file browser or if that is not desirable a hardcoded directory (I warn you though a fair few other apps do this and the root of my memory cards (even though I only use a few choice bits of homebrew) is very cluttered). Picodrive DS is considered a good example of a file browser: http://www.cryptosystem.org/projects/nds/picodriveds-0.1.7/ (tarball there although there is a bountysource site I seem to remember).

If it is a game where only the textures/level data..... is loaded with you only really altering the business side of the code then you can stand to hardcode the directories and even file names either in the app or get them read from a user editable "ini" file.

As for actually adding it to the code once again the tutorials on the sites I linked are your best bet, if you plan on doing a lot of of FAT access add it into the main section of the code, if it is for something like saves (kind of a waste in my opinion but that is just me) then you can probably add it to whatever section of code handles saves (although I would work it into the main section if possible).

 

[chuckstudios]

Also, I forgot to mention you need to #include "fat.h". To add onto what FAST6191 said about user-defined directories, I have found the iniParser library to be very adept at handling INI files, and it compiles without modification on the DS. It is also under the MIT license, so you don't have to make your projects which use it open source if you don't want to.