#79219 - chishm - Wed Apr 12, 2006 6:06 am
I am currently working on an update to the FAT library. I am looking to add the ability to call FindFirstFile / FindNextFile recursively, however, this will require a change to the API. This will most likely involve passing a struct amongst the file system methods (FindFirstFile, FindNextFile, GetAlias, etc), that will contain the current state, rather than relying on (ugly) global variables as it does now.
This API change will not affect functions that mimic the behaviour of standard C file functions (fopen, fclose, remove, chdir).
So this poll applies to developers who are currently using / going to use the FAT library. End users need not apply.
While I'm at it, are there any other changes wanted (not hardware related)?
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#79235 - tepples - Wed Apr 12, 2006 12:38 pm
The opendir() family already requires passing around a this-pointer.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79258 - chishm - Wed Apr 12, 2006 1:57 pm
| tepples wrote: |
| The opendir() family already requires passing around a this-pointer. |
I'd model the new functions off of the opendir() family, except they do not contain all of the functionality that I want to provide. Also, to save memory / not include use of malloc, FindFirstFile (or equivalent) will not allocate memory for the structure -- this will be the task of the user.
FAT_fopen does allocate the memory for FAT_FILE* (from a static block), but this is wasteful, and limits the maximum number of simultaneously open files to 4 (unless customised by the programmer using the library). This may also be a time for FAT_fopen to be changed to rely on the user to allocate the memory, if people so desire it. However, this will break away from the standard fopen specs.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#79279 - 0xtob - Wed Apr 12, 2006 5:31 pm
chishm: If the usability and/or functionality of the FAT lib benefits from whatever changes you're making, I'll be happy to adapt my code to the new lib.
By the way, is it possible to determine the amount of free space on the card with the current FAT lib? If not, would it be much work to add this? OK, I could just create a "dummy" file of the needed size and check if it has the correct size, then delete it again and write the "real" file, but it's not the most elegant solution :-)
Bye,
Tob
#79293 - tepples - Wed Apr 12, 2006 6:53 pm
| chishm wrote: |
| tepples wrote: | | The opendir() family already requires passing around a this-pointer. |
I'd model the new functions off of the opendir() family, except they do not contain all of the functionality that I want to provide. |
What kind of functionality were you talking about? The kind that could be done with stat()?
| Quote: |
| FAT_fopen does allocate the memory for FAT_FILE* (from a static block), but this is wasteful, and limits the maximum number of simultaneously open files to 4 (unless customised by the programmer using the library). |
MS-DOS has the FILES= variable in config.sys. Even Windows and Linux have a limit of n open files per process.
| Quote: |
| This may also be a time for FAT_fopen to be changed to rely on the user to allocate the memory, if people so desire it. However, this will break away from the standard fopen specs. |
Have FAT_InitFilesEx() take a buffer and size, and then have FAT_InitFiles() call FAT_InitFilesEx() with a nominal sized buffer. (Put FAT_InitFiles() and its buffer in a separate file so that it doesn't get linked in if the program only calls FAT_InitFilesEx().)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79304 - Mighty Max - Wed Apr 12, 2006 7:29 pm
Imho we could use a change in the interface anyways, so that it would be good if we'd combine them.
What i'm thinking on is the add of another abstraction layer to seperate the filesystem. We have done this with the hardware, so your FAT lib can use different hardware.
In the current situation, this is done by the individual, and different #define lines on different builds.
It would be nice if the "combined device driver" would allow access to gbfs with a "gbfs://" prefix or "fat://" for the normal fat lib. Or defaults to fat if nothing is specified.
_________________
GBAMP Multiboot
#79312 - HyperHacker - Wed Apr 12, 2006 9:42 pm
3 things I can think of that would be useful to add, if they don't already exist:
1) Some way to determine the current directory. Especially useful if the path was always stored at some specific memory location, then when you launch another .nds, it could see what directory it's in.
2) Ability to browse the filesystem of the inserted DS card if possible.
3) Ability to open the memory card/DS card itself as a file, like you can in Linux.
As for the API changes, I wouldn't mind having to fill out some information, but between FAT_OpenFilesEx() and passing structs to API functions, this is starting to sound like the Windows API...
#79340 - josath - Thu Apr 13, 2006 12:48 am
| Mighty Max wrote: |
| It would be nice if the "combined device driver" would allow access to gbfs with a "gbfs://" prefix or "fat://" for the normal fat lib. Or defaults to fat if nothing is specified. |
Even nicer would be if it couldn't find a fat partition, then it automatically falls back to using gbfs.
Also:
It seems enabling Supercard SD breaks the Supercard CF driver. But this is using the fat lib from RAIN, which has the asm driver, so I can't really blame you.
EDIT:
Once the API gets stable enough, I'd suggest making a c++ wrapper. I'll probably take a crack at it if nobody else does.
#79406 - tepples - Thu Apr 13, 2006 12:46 pm
| josath wrote: |
| Even nicer would be if it couldn't find a fat partition, then it automatically falls back to using gbfs. |
GBFS doesn't support nested folders yet.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79413 - sofakng - Thu Apr 13, 2006 2:21 pm
chishm, are you going to be implementing a way to include the FAT system inside of an NDS file? (so people with regular flash carts will work [not only the compact flash cards])
Also, does your FAT driver support writing? (will it be supported on regular flash carts like my question above?)
#79434 - tepples - Thu Apr 13, 2006 6:04 pm
| sofakng wrote: |
| chishm, are you going to be implementing a way to include the FAT system inside of an NDS file? |
You mean bin2s'd and linked into the .nds that gets ? This would be called a loopback file system.
| Quote: |
| Also, does your FAT driver support writing? (will it be supported on regular flash carts like my question above?) |
"Regular flash carts" are as different as CF and SD. F2A, EZ-Flash, EZFA, EFA, EFA II, G6, etc. all need different procedures to communicate with the ASIC and read and write the flash chip.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79460 - sofakng - Thu Apr 13, 2006 8:50 pm
Well, all I'm looking for is something that will work with all NDS homebrew systems... (regardless whether the user is using an EZ-Flash II, SuperCard, etc, etc...)
All I need is a way to permanently save a file (eg. it should work on all NDS systems)...
Does nothing like this exist?
#79488 - tepples - Fri Apr 14, 2006 12:35 am
If no CF or SD card is available, you'd probably have to create a 64 kilobyte read/write file system in GBA SRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79499 - sofakng - Fri Apr 14, 2006 1:13 am
Does the GBA SRAM last between games? (eg. the users play the game, saves, and then turns the system off to return to it later and resume the game where he left off)
If so, which library/API is available to work with this file system?
#79514 - tepples - Fri Apr 14, 2006 2:27 am
| sofakng wrote: |
| Does the GBA SRAM last between games? (eg. the users play the game, saves, and then turns the system off to return to it later and resume the game where he left off) |
Yes, provided that the flash cart's battery is charged.
| Quote: |
| If so, which library/API is available to work with this file system? |
Currently there is no well-known fopen() style library to work with GBA SRAM, but manual bytewise copies to and from the 64 KB region starting at 0x0A000000 work. See the GBA beginners' FAQ. (Note that the DS places GBA SRAM at 0x0A000000, not 0x0E000000 like the GBA.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79926 - chishm - Mon Apr 17, 2006 6:28 am
Sorry for the long delay before replying, I was away and the PC I had access to couldn't get to this site.
0xtob:
I'll be able to add free space reporting, but it will only be accurate to multiples of free clusters. This is probably best anyway, as it will give a worst case scenario of the amount of space available for a new file.
tepples:
Yes, the planned functionality is for file size, cluster, etc reporting. Since I'm completely rewriting the API, I could just have the default InitFiles accept a memory buffer to allocate from. However, this idea is still in flux.
Mighty Max:
I agree that we need a 3rd layer, to support multiple file systems. GBFS will hopefully become less needed for flash cart users when I am done (take a look at the FCSR device in the current FAT library), but there are still other reasons to abstract away direct file system access. Each support file system will only need to support file listing, directory changing, and file opening / reading / writing functionality. Then the 3rd layer provides the rest of the stdio functionality like fgets, etc.
HyperHacker:
Allowing to determine the current directory means paths will have a size limit. At the moment there is no path length limit, but if this were done it would most likely be limitted to 1024 characters. This already occurs in many desktop OSes, so it isn't too restricting.
DS cards use a completely different file system (here after refered to as "NitroFS"). NitroFS requires the header of the currently inserted DS card to be intact, to provide values required in locating and parsing the file system on the card. Unfortunately, the header is destroyed by many NDS loaders (like the GBAMP, ndsmall, etc) and there is no easy way around this.
sofakng:
This would be done by the FCSR (Flash Cart with SRAM driver), which is already included in the current FAT library. I just haven't had time / motivation to release a stable file system builder. It simulates a disk of up to 32MB in size, with 64KB of free space using SRAM overlays.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#79942 - sofakng - Mon Apr 17, 2006 12:34 pm
| chishm wrote: |
sofakng:
This would be done by the FCSR (Flash Cart with SRAM driver), which is already included in the current FAT library. I just haven't had time / motivation to release a stable file system builder. It simulates a disk of up to 32MB in size, with 64KB of free space using SRAM overlays. |
Is the SRAM a permanent storage or temporary (eg. only when the DS is turned on)?
If you make any progress on a driver for this type of file system, please let me know. I'd be VERY interested in using it. Thanks!
#79944 - tepples - Mon Apr 17, 2006 1:27 pm
| sofakng wrote: |
| Is the SRAM a permanent storage or temporary (eg. only when the DS is turned on)? |
It's permanent as long as your flash cart's battery stays charged.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79982 - sofakng - Mon Apr 17, 2006 11:18 pm
chishm/tepples:
What about adding writing support for SD cards to the FAT driver? I've heard that only CF cards support writing to the file system and SD only allows reading...
#80005 - chishm - Tue Apr 18, 2006 1:27 am
| sofakng wrote: |
| What about adding writing support for SD cards to the FAT driver? I've heard that only CF cards support writing to the file system and SD only allows reading... |
This is a hardware issue and not related to the API. SD writing support will be included when it works in C.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#80102 - tepples - Tue Apr 18, 2006 8:16 pm
What prevents an ARM7 assembly language implementation? Or are you planning to have this work on platforms other than the GBA and Nintendo DS?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.