gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Unified filesystem / drivers?

#70006 - melw - Fri Feb 03, 2006 6:36 pm

Just wondering,

I know there's Chishm's FAT driver, supporting also CF devices. Recently Moonshell has also a support for SD. Whereas everything seems to be floating around, has anybody done something unified so that one could count on supporting all the flash cards, GBAMP, SuperCard, M3 all alike.

Personally I have just M3/SD, reading all the tens of threads about people complaining how something doesn't work on their setup I wouldn't want to go through the hassle releasing something that doesn't work on, let's say Supercard or GBAMP.

#70011 - linus - Fri Feb 03, 2006 7:02 pm

Well as far as i understand it...

SD support is not in because chishm doesnt like the assembly so someone is trying to convert it to C but everyone is using the assembly file for now anyways.

Moonshell has added unicode support

Thats about as much as i know - the moonshell probably has other improvments as well because scummvm works on the SCSD with the moonshell fat driver whereas none of the other fat drivers with SD would.

Well thats my two monkeys

#70039 - VanillaIcee - Fri Feb 03, 2006 10:06 pm

Yes, I agree this should be a priority. An all encompassing driver/library that abstracts out file handling, ideally as POSIX similar as possible.

I'd be willing to work on it if it is not currently being developed by others. I just don't want to reinvent the wheel. I can also beta test for M3/SD compatibility.

#70042 - tepples - Fri Feb 03, 2006 10:28 pm

VanillaIcee wrote:
An all encompassing driver/library that abstracts out file handling, ideally as POSIX similar as possible.

Then I guess it's about time for me to write an fopen() style wrapper around GBFS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#70053 - GPFerror - Fri Feb 03, 2006 11:45 pm

there is also my ported romdiskfs http://gpf.dcemu.co.uk/ndsromdisk.shtml

which uses posix style functions KOS_fopen etc.

#70058 - josath - Sat Feb 04, 2006 12:21 am

and make sure it doesn't corrupt our CF cards!

#70128 - melw - Sat Feb 04, 2006 1:51 pm

VanillaIcee, I have no idea if anybody's working on this... that's why I started the thread. And seeing how many homebrew apps lack support for M3/SD, here's another willing beta tester if any help is needed. I have also access to M3/CF but I guess those are much more common in any case...

Tepples, fopen() style wrapper would be great!

Also some kind of auto-detection, so that the same .nds would work on all the different cards...

Well, crossing fingers. Hopefully this will be true some day.

#70145 - realstar - Sat Feb 04, 2006 4:46 pm

In the short term, it would be nice if someone could
take the src from MoonShell that supports SD/CF
and organize an easy drop-in replacement for existing
software to use. I am sure most developers wouldn't
mind recompiling with the MoonShell version if it improves
compatibility and doesn't involve much effort to change to. :)

#70158 - VanillaIcee - Sat Feb 04, 2006 8:06 pm

Okay, so I'm new to NDS development (less than a week). Now is the assembly version being used because there are problems in the io_m3sd.c found in the latest moonshell source code?

Is there a complete reference for the registers/addresses of the M3 SD card? I found it once I thought, but if any of you know off the top of your head...

#70206 - chishm - Sun Feb 05, 2006 12:55 am

Actually, the current FAT lib supports flash carts, I just haven't released an FS builder yet. I can give the specs for the appended FAT FS format, but I'll have to dig them up. I'll also have MK2 / MK3 support soon, and once I figure it out, SC SD and M3 SD.

However, if someone isn't happy with the current lib, you are more than welcome to use parts of mine to create yours, as long as you aknowledge where it came from. disc_io already contains all the interfaces you need to do this, so it would save rewriting the hardware routines.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#70256 - HyperHacker - Sun Feb 05, 2006 4:16 am

For GBA flash carts, you could just create a FAT filesystem within a file (as if the file were a disk; pretty sure Linux can do this, dunno about Windows) and write it to the cart. Biggest problem would be supporting all the different flash carts out there. Maybe some info about how to work the cart (or code that does it) could be stored at the beginning, before the actual filesystem (just add its size to each address when working with the FS).

#70257 - tepples - Sun Feb 05, 2006 4:19 am

HyperHacker wrote:
For GBA flash carts, you could just create a FAT filesystem within a file (as if the file were a disk; pretty sure Linux can do this, dunno about Windows)

Problem is that Windows generally does not support loopback file systems as well as most of us would like. In addition, the method that Windows uses to provide long file names is subject to a U.S. patent that was recently upheld, so it's best to move away from FAT to a different file system that supports long(er) file names natively.

Quote:
and write it to the cart. Biggest problem would be supporting all the different flash carts out there.

If you don't need write support, and you don't need more than 256 megabits (32 megabytes), you can just assume the cart is a 31 megabyte linear array.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#70267 - chishm - Sun Feb 05, 2006 5:09 am

The method I use for flash carts is to build a proper FAT file system, then mark every file as read only and nearly all clusters as occupied. To add write support, I then define up to 4 SRAM overlays, that specify certain sectors should be placed in SRAM instead. These are copied to SRAM when the program is first run, and used from there everytime after that.

These overlays are used for: part of the FAT, so cluster chains can be updated; the end of the root directory, to add in more files; and to store the actual clusters.

The nice thing about FAT is that it is supported by pretty much every modern OS. Nothing else is as universal, and so there are no suitable replacements. Not to mention that the firmware in the CF and SD adapters are written to load files only from a FAT formatted disc.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#70269 - HyperHacker - Sun Feb 05, 2006 5:11 am

SRAM is fairly limited, though. You should be able to write to the card itself without too much trouble.

#70274 - chishm - Sun Feb 05, 2006 5:29 am

HyperHacker wrote:
SRAM is fairly limited, though. You should be able to write to the card itself without too much trouble.

If you think that it's too incompatible / slow to write now, just wait until you (sorry, I) have to adapt it to every single flash cart brand there is. Flash carts all use their own unlock sequence and their own flash chip registers. They also tend to use blocks of around 64KiB in size, which complicates things even more.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#70427 - chishm - Mon Feb 06, 2006 11:11 am

Can someone with a Supercard SD try this test? It should work on GBAMP CF, M3 CF, SC CF, and hopefully SC SD. It should list the contents of your root directory.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#70457 - Sintax - Mon Feb 06, 2006 6:04 pm

chishm wrote:
Can someone with a Supercard SD try this test? It should work on GBAMP CF, M3 CF, SC CF, and hopefully SC SD. It should list the contents of your root directory.
Says no valid filesystem when I try it.

#70505 - m2pt5 - Mon Feb 06, 2006 11:25 pm

Same result here.

Supercard SD FW 1.60
DS Original FW v2, currently FlashMe v6
512MB PNY SD card, FAT formatted

I booted it in GBA mode.

Thought: Was that meant to be run on an actual GBA or on a DS (or ahould it matter)?
_________________
Don't sign your posts, it's dumb.

#70523 - chishm - Tue Feb 07, 2006 12:35 am

It should be run in GBA mode on any console that supports it. I have uploaded a new test to the same link. Please try it and report on how it goes.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#70528 - Sintax - Tue Feb 07, 2006 1:24 am

Same thing. I just hopped onto irc if you need someone to test in a more timely manner.

#70534 - m2pt5 - Tue Feb 07, 2006 3:10 am

I tried both true GBA mode (from the system menu) and DS->GBA mode (select a GBA ROM from the sC menu and it goes into "GBA mode". I assume this is a bit different because the other screen used to remain lit with older firmware; or it's just lazy programming.)

Anyway, still no worky.
_________________
Don't sign your posts, it's dumb.

#70548 - chishm - Tue Feb 07, 2006 5:58 am

Ah well, looks like I'll just give up on the supercard SD until I get hold of one.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#70561 - rmt38 - Tue Feb 07, 2006 9:37 am

If you download the NDSPython source code, you can see how I integrate chishm's file-system code to be used as a device by newlib (the c library that comes with devkitarm). This means that you can use fopen, fstat.. etc on files on the compact flash card. Although because you have to mount the CF card as a device, you have to prefix all paths with cf0: or something similar.