gbadev.org forum archive

Has anyone compared ALL of the various GBA/NDS file systems that have been used by various programs, to compare their features, pros/cons, limitations, and see which one is the best? I'll try to list some of them here:

FAT disk image
Moonshell IMFS
Pogoshell Filesystem
PinEightGBFS
Simple linked list with filesize and filename
Searching through a file to look for file ID tokens (JFIF, RIFF, MTHD, NES^Z, etc)

So which filesystems have been used in GBA/DS programs that I'm missing?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

my port of romfs to the ds, probably would work on the gba if someone wanted it.
http://gpf.dcemu.co.uk/ndsromdisk.shtml

It works similiar to gbfs for finding the disk image, but supports a stdio like api also has support for a ramdisk filesystem as well.

Also using FSCR images appended to the end of .ds.gba files works seems to work with fatlib on some of the carts that don't have fatlib support I'v heard, I've only used them with Ideas and no$gba emulators.

Troy(GPF)
http://gpf.dcemu.co.uk/

I've made a little table of a few so far:

Code:

Filesystem Name Dir NL name size date checksum Extra Inf. Compression Writable
-------------------------------------------------------------------------------------------------
FAT Yes 255 Name Size Date Attributes Yes
Moonshell IMFS Yes 64 Name Size CRC32 LZ77 No
Pogoshell (ROM) Yes 32 Name Size No
Pogoshell (SRAM) No 32 Name Size Date GBA Game ID User # RLE Yes
PinEightGBFS No 24 Name Size No
PocketNES No 32 Name Size No
PocketNES SRAM No 32 Name Size Date Sum First 16k MiniLZO Yes

columns:
DIR: filesystem supports directories and subdirectories
NL: Maximum length of a filename
name, size, date: Indicates if the filesystem stores this info
checksum: Some filesystems store file checksums
Extra Inf: Other misc information
Compression: This is for compression done at the file system level
Writable: There is code available for writing this on the GBA/DS itself.

Here's some information about each file system:
FAT
----
This is the FAT16/32 filesystem, either used on a disk, or using a disk image. Has plenty of overhead.
Directories are implemented as special files, containing directory entries. They are linked.
Uses a FAT to determine where clusters are on the disk
Uses fixed size file entries, as well as special invalid files to add long names.

Moonshell IMFS
-----------------
File system used by moonshell.
Directories are implemetned as an directory ID number for a file. Directories can be contained within directories.
Files can be compressed with LZ77, this is done at the filesystem level.
Identified by magic number "IMFS"

Pogoshell
-----------
Filesystem used by pogoshell on ROM. GBA files are stored separately from other files, and are aligned to 32k boundaries to support bankswitching the flash cartridge to run them. Pogoshell itself has ugly limitations on the number of files in a directory, but these are not part of the filesystem itself. Filenames are 32 characters or less, posing a problem for long names. It chops off the file extension if the name is too long.
Identified by magic number 0xFAB0BABE, must be aligned to 32k boundary.

Pogoshell SRAM
------------------
Separate file system used by pogoshell for storing SRAM. Split accross 3 64k pages of SRAM. No support for subdirectories. Originally, pogoshell used the GBA GAME ID to identify which rom a save was associated with, but Kuwanger has modified the shell to remove that "feature".
Files are always RLE compressed.
Stores a User ID# to allow multiple players to save with the same file.
Identified by magic string "MINSF2"

PinEightGBFS
---------------
Simple linked appended filesystem, just stores a 24 character filename, a relative pointer to the start of the data, and a relative pointer to the next file.
Identified by magic string "PinEightGBFS\r\n\032\n"

PocketNES
------------
Very similar to GBFS, but stores flags about how the emulator should treat roms. Each file gets a 48 byte header, containing filename, flags, and size.
No magic number, the emulator knows its size and uses that to determine where to look. But the position of NES^Z-48 can also be used.

PocketNES SRAM
-------------------
Linked structure in SRAM for storing savestates and sram files, all files are compressed with MiniLZO.
Magic number is 0x57a731d7 (stateidt).

Then there are a few filesystems I've forgotten about:
Zip File with no compression, used by scummvm ds.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Dwedit wrote:

PinEightGBFS
---------------
Simple linked appended filesystem, just stores a 24 character filename, a relative pointer to the start of the data, and a relative pointer to the next file.
Identified by magic string "PinEightGBFS\r\n\032\n"

Almost. GBFS isn't linked in the sense that PocketNES or Tar is. It consists of a header (containing the magic string and an offset to the directory table), a directory table (similar to that of PogoShell), and file data, where each file data is aligned to 16 bytes. GBFS must be aligned to 256 bytes for use with find_first_gbfs_file() in .gba or ds.gba. The file system itself doesn't support compression, but LOCKJAW: The Overdose demonstrates how to use GBA LZ77 decompression.

Is there demand for long file names or subdirectory support in GBFS?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Is there demand for long file names or subdirectory support in GBFS?

Only necessary if the filesystem gets browsed or listed, if it's just used as an incbin hack alternative, then it isn't necessary.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

I've put this table into wiki format, haven't finished putting all if the info in, but I also added romfs to the table, and split out FAT for old/new versions, and added a few columns.

Please, everyone feel free to add any more info that you know to it

http://dev-scene.com/NDS/DOCfilesystems

josath wrote:

Please, everyone feel free to add any more info that you know to it

http://dev-scene.com/NDS/DOCfilesystems

The wiki is configured to forbid anonymous editing. Creating an account on the wiki requires creating an account on the forum, which requires downloading and solving a visual CAPTCHA. This took me a couple tries on a PC, and users of DSLinux would have to use the e-mail method instead. And given that the forum and wiki accounts are linked, and a lot of public forums are known to delete inactive accounts, does posting only to the wiki and not to the forum mean my wiki account will be deleted?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

josath wrote:

Please, everyone feel free to add any more info that you know to it

http://dev-scene.com/NDS/DOCfilesystems

The wiki is configured to forbid anonymous editing. Creating an account on the wiki requires creating an account on the forum, which requires downloading and solving a visual CAPTCHA. This took me a couple tries on a PC, and users of DSLinux would have to use the e-mail method instead. And given that the forum and wiki accounts are linked, and a lot of public forums are known to delete inactive accounts, does posting only to the wiki and not to the forum mean my wiki account will be deleted?

I have a feeling not much wiki editing is going to be done from within dslinux. wiki viewing doesn't require an account. until we come up with better ways, captcha is a must, they were getting spammed. Also I don't think it will expire accounts.

josath wrote:

tepples wrote:

josath wrote:

Please, everyone feel free to add any more info that you know to it

http://dev-scene.com/NDS/DOCfilesystems

The wiki is configured to forbid anonymous editing. Creating an account on the wiki requires creating an account on the forum, which requires downloading and solving a visual CAPTCHA. This took me a couple tries on a PC, and users of DSLinux would have to use the e-mail method instead. And given that the forum and wiki accounts are linked, and a lot of public forums are known to delete inactive accounts, does posting only to the wiki and not to the forum mean my wiki account will be deleted?

I have a feeling not much wiki editing is going to be done from within dslinux. wiki viewing doesn't require an account. until we come up with better ways, captcha is a must, they were getting spammed. Also I don't think it will expire accounts.

I'm tired so I'll make this quick and straight to the point

The wiki is configured to allow only those with an active forum account to edit and expand the content of our page. Hopefully requiring people to create an active forum account would lightly encourage people to use it in one form or another plus I've only ever deleted accounts that were used to spam our forums. Our forum was experiencing a LARGE number of she-male porn related bot spam and the CATCHPA system was required to stop this.. the positive side effect is the new system I've installed has actually made the visibility of the Phrase easier to read.

The system has actually worked very well and while DSLinux sign ups might have become a non-trivial task... this is the first complaint I've heard so far - A large thank-you to everyone who continue to add content to the Dev-Scene project.

P.S I personally don't believe in the Wikipedia style of anonymous editing but thats another story.
_________________
MrShlee.com
Projects
Dev-Scene
MyTechpedia

gbadev.org forum archive

DS development > Comparison of the various GBA/DS "file systems"?

#107141 - Dwedit - Fri Oct 27, 2006 2:22 am

#107144 - GPFerror - Fri Oct 27, 2006 4:37 am

#107146 - Dwedit - Fri Oct 27, 2006 4:47 am

#107241 - tepples - Fri Oct 27, 2006 10:53 pm

#107257 - Dwedit - Sat Oct 28, 2006 1:18 am

#110613 - josath - Wed Nov 29, 2006 10:56 pm

#110619 - tepples - Wed Nov 29, 2006 11:24 pm

#110650 - josath - Thu Nov 30, 2006 2:47 am

#110801 - Mrshlee - Fri Dec 01, 2006 8:02 pm