#142749 - tempest - Fri Oct 12, 2007 4:13 pm
Hello, I'm developing a small app that involves reading files from the storage media in my SLOT-2 card, via libfat.
I would like to fasten my development cycle using emulators, but as far as I understood the only one with storage media support is no$gba, and I'm having no success in using that feature.
I noticed the "NDS Cartridge Backup Media" in the Setup window of the program, but even playing with it I can't get my homebrew to access the emulated storage media.
Can someone provide a hint? Thanks in advance!
edit: changed title to "Generic storage media support"
Last edited by tempest on Wed Mar 05, 2008 11:36 pm; edited 1 time in total
#142751 - Peter - Fri Oct 12, 2007 5:28 pm
| tempest wrote: |
| Can someone provide a hint? Thanks in advance! |
Maybe this: libfat/DLDI file IO on emulator
_________________
Kind Regards,
Peter
#142826 - dantheman - Sun Oct 14, 2007 4:12 am
I don't believe no$gba has support for filesystem access. iDeaS has support for the R4 DLDI file though, so you may wish to try that. I know Desmume also has filesystem access of sorts, which I think runs best when you manually run it in GBAMP mode somehow. I'm fuzzy on the details of that, sorry.
#142829 - GPFerror - Sun Oct 14, 2007 6:29 am
desmume sometime works with just use gbamp.dldi, if not you have to make a fat12 image of your directory and start it with desmume --cflash=fat12.img
ideas use r4 dldi driver, and select r4 booting through properties.
no$gba you can use fcsr images appended to the ds.gba file, patched with my fcsr.dldi driver.
Troy(GPF)
#144181 - tempest - Mon Oct 29, 2007 11:45 pm
Tried fcsr driver as described in the other posts suggested, works like a charm in no$gba and ideas, thanks!
Too bad, that same ds.gba with fcsr image appended is not working in real hardware (I have a Supercard SD), is this supposed to be? I know I can patch the image with scsd.dldi and place my files on the SD, but what if I want to keep everything (application + files) in a single file?
Thanks again for any hint!
#144187 - chuckstudios - Tue Oct 30, 2007 12:28 am
| tempest wrote: |
Tried fcsr driver as described in the other posts suggested, works like a charm in no$gba and ideas, thanks!
Too bad, that same ds.gba with fcsr image appended is not working in real hardware (I have a Supercard SD), is this supposed to be? I know I can patch the image with scsd.dldi and place my files on the SD, but what if I want to keep everything (application + files) in a single file?
Thanks again for any hint! |
Then you use EFSlib by Noda.
#149929 - Ultima2876 - Sun Jan 27, 2008 4:02 pm
I've tried getting EFSlib working with emulators, using the fcsr.dldi patching method, but no$gba always gives me the same "EFS init failed" error. =/
The FAT init works fine, indicating that there's something going on with EFS itself. I'm using the efs patcher and such, of course, because the same nds file (without the dldi patching stuff) works perfectly on hardware.
#150232 - josath - Thu Jan 31, 2008 8:42 pm
1. use EFS in real fat mode (where it just uses libfat directly)
2. build a FCSR image of your files, instead of putting them in NitroFS using ndstool
#151852 - tempest - Thu Mar 06, 2008 12:17 am
Thanks for all the suggestions. I'll give a quick summary of where my efforts got me. I got intrigued on the opportunities offered by fcsr dldi patch, and had some fun with it: I can produce .nds roms, with the fat12 appended filesystem that work unchanged on no$gba, desmume (just sometimes on ideas for some reason, but I can live without it), and my supercard sd (slot-2).
Strangely, the .ds.gba version of the same roms doesn't work on supercard sd, but who cares.
The downsides as I see them are that fcsr doesn't work at all on slot-1 cards (libfat with an emulator), if I understood correctly it doesn't support writes, and the whole filesystem is loaded into memory when the program starts.
My goal right now is really producing roms that will run unchanged (no need for dldi patching) on all flash cards and emulators. Embedding the filesystem seems to be the way to go, so I decided to give that EFSLib a run. I have some questions about that...
1) From what I've gathered from this post, real fat mode basically allows you to leave your existing libfat code unchanged, then you can apply fcsr dldi patching over it. But will this work on slot-1 devices too? fcsr works just on slot-2 devices...
2) if I understood correctly, using normal mode (opposed to real fat mode) means that you have to change your existing code to use the various efs_* functions. Do I have to apply dldi patching anyway in this case?
To summarize: is there ever a way to produce a .nds file that works everywhere, emulators, slot-1 devices, slot-2 devices, even at the costs of having an embedded filesystem, not being able to create new files and such?
Should such a way exist, it would then be needed to protect the roms from accidental dldi auto patch from the devices itselves (r4 does so): this utility seems to do this exact trick.