NeoRomFS.txt

NeoRomFS
========
I don't know if the idea of having a filesystem for the cart games is a good idea,
but I can come up with a few instances of when it would possibly be useful.

sucks that most of those are for my own testing purposes.

* 6502 (or other CPU) emulator
loading source or binary files

* FM/sound sequencer
loading various files from P ROM board?
 - FM and SSG instrument presets/library

* loading external files on custom development cart hardware
if you're cool, you can create a dev environment for your game that allows you to
test changes without having to recompile every time. maybe.

================================================================================
[Why use this over incbin?]
really good question, and if you can't think of a reason to use it, then don't.
save yourself the overhead and keep the bytes for more data.

================================================================================
[What goes into a filesystem?]
Need to think about this.

references to look at:
* romfs, which is probably the ideal solution (http://romfs.sourceforge.net/)
* cramfs, though I could probably do without the compression (except on CD?) (http://sourceforge.net/projects/cramfs/)
* GBFS by tepples
* FAT16B (the canonical "FAT16")
* FAT32

================================================================================
[Simplest filesystem I can think of]
Work in progress since this part was written at 4AM one day...
(Note that this is a read-only filesystem.)

Root Element\
* Number of Entries
Entry List\
repeat for number of entries {
* Name (null terminated)
* Type (0=File, 1=Directory, 2=Device?)
* Size
* Pointer to Data
}

================================================================================
[quick romfs overview]

offset	    content

	+---+---+---+---+
  0	| - | r | o | m |  \
	+---+---+---+---+	The ASCII representation of those bytes
  4	| 1 | f | s | - |  /	(i.e. "-rom1fs-")
	+---+---+---+---+
  8	|   full size	|	The number of accessible bytes in this fs.
	+---+---+---+---+
 12	|    checksum	|	The checksum of the FIRST 512 BYTES.
	+---+---+---+---+
 16	| volume name	|	The zero terminated name of the volume,
	:               :	padded to 16 byte boundary.
	+---+---+---+---+
 xx	|     file	|
	:    headers	:

Every multi byte value (32 bit words/"longwords") must be in big endian order.

The following bytes are now part of the file system; each file header
must begin on a 16 byte boundary.

offset	    content

	+---+---+---+---+
  0	| next filehdr|X|	The offset of the next file header
	+---+---+---+---+	  (zero if no more files)
  4	|   spec.info	|	Info for directories/hard links/devices
	+---+---+---+---+
  8	|     size      |	The size of this file in bytes
	+---+---+---+---+
 12	|   checksum	|	Covering the meta data, including the file
	+---+---+---+---+	  name, and padding
 16	| file name     |	The zero terminated name of the file,
	:               :	padded to 16 byte boundary
	+---+---+---+---+
 xx	| file data	|
	:		:

================================================================================
[NeoRomFS]
This section is currently a work in progress as well.

Cart version expects a linear database; CD version loads "non-standard" files.

<Header>
$00-$07		(str.) "NeoRomFS"
$08-$0B		(long) size of data in filesystem (bytes)
$0C-$0F		(long) ????

<Default Filesystem (Cart)>
/				Filesystem Root
	mc/				[Device] Memory Card
	bram/			["Device"] MVS Backup RAM
	pc2neo/			[Device] PC2Neo cable

<Default Filesystem (CD)>
/				Filesystem Root
	mc/				[Device] Backup Memory
	pc2neo/			[Device] PC2Neo cable


<Memory Card/Backup Memory>
NeoRomFS provides a soft layer over the memory card functions.
Data is written to the card using the original SNK file system.

<MVS Backup RAM>
Where available, NeoRomFS can provide a soft layer over the MVS Backup RAM.

<PC2Neo Cable>
(unsure if this should be handled by NeoRomFS or elsewhere)