The allocation of the 256 blocks is as follows:

The Directory, FAT and Root block are system files. They are not listed in the Directory, but do appear in the FAT. The Root block is always block 255. The start block of the FAT and Directory can be found in the Root block, see below.

The root block (block 255) contains information such as:

• The date when the card was formatted
• The color and icon for this VMS in the Dreamcast file manager
• Location and size of the FAT and Directory system files

0x000-0x00f : All these bytes contain 0x55 to indicate a properly formatted card.
0x010       : custom VMS colour (1 = use custom colours below, 0 = standard colour)
0x011       : VMS colour blue component
0x012       : VMS colour green component
0x013       : VMS colour red component
0x014       : VMS colour alpha component (use 100 for semi-transparent, 255 for opaque)
0x015-0x02f : not used (all zeroes)
0x030-0x037 : BCD timestamp (see Directory below)
0x038-0x03f : not used (all zeroes)
...
0x046-0x047 : 16 bit int (little endian) : location of FAT (254)
0x048-0x049 : 16 bit int (little endian) : size of FAT in blocks (1)
0x04a-0x04b : 16 bit int (little endian) : location of directory (253)
0x04c-0x04d : 16 bit int (little endian) : size of directory in blocks (13)
0x04e-0x04f : 16 bit int (little endian) : icon shape for this VMS (0-123)
0x050-0x051 : 16 bit int (little endian) : number of user blocks (200)
...

The File Allocation Table works similar to a MS-DOS FAT16 File Allocation Table. It serves two purposes; it indicates which blocks are unallocated, and it links the blocks of a file together. Each of the 256 blocks have an entry in this table consisting of a 16-bit integer value (little endian). The entry for block 0 is stored first in the FAT, and the entry for block 255 is stored last. The entry is interpreted like this:

0xfffc    :  This block is unallocated
0xfffa    :  This block is allocated to a file, and is the last block in that file
0x00-0xff :  This block is allocated to a file, and is not the last block in that file

Note that mini-game files are allocated starting at block 0 and upwards, while a data file is allocated starting at block 199 selecting the highest available free block. This is probably because a mini-game should be able to run directly from the flash, and thus needs to be placed in a linear memory space starting at a known address (i.e. 0).

Although block 200 through 240 are marked as "free" in the FAT, they can not be used for anything.

The Directory lists all the user files stored in the VMS. The Directory consists of a sequence of 32-byte entries each potentially describing a file. When the VMS is formatted, enough space is allocated to the Directory file to accommodate 200 entries. This is enough, since each file must be at least one block long, and there are only 200 blocks available for user files. The actual blocks making up the Directory can be found using the Root block and the FAT, although it should be safe to assume that the Directory has been allocated to blocks 241 through 253; 253 being the first block of the Directory, and 241 the last.

An entry in the directory is either all NUL-bytes (denoting an unused entry), or a structure describing a file. This structure looks as follows:

0x00      : 8 bit int : file type (0x00 = no file, 0x33 = data, 0xcc = game)
0x01      : 8 bit int : copy protect (0x00 = copy ok, 0xff = copy protected)
0x02-0x03 : 16 bit int (little endian) : location of first block
0x04-0x0f : ASCII string : filename (12 characters)
0x10-0x17 : BCD timestamp (see below) : file creation time
0x18-0x19 : 16 bit int (little endian) : file size (in blocks)
0x1a-0x1b : 16 bit int (little endian) : offset of header (in blocks) from file start
0x1c-0x1f : unused (all zero)

• Century (e.g. 19)
• Year within century (e.g. 99)
• Month within year (e.g. 11)
• Day within month (e.g. 1)
• Hour of day (e.g. 22)
• Minute of hour (e.g. 50)
• Second of minute (e.g. 12)
• Day of week (0 = monday, 6 = sunday)

The software for the "Nexus 4 meg" 3rd party memory card can transfer the contents of the memory card flashrom to a PC and storing it in a file designated a "DCM-file". This is basically just a raw memory dump of the entire flashrom, however it must be noted that order of the bytes have been reversed in groups of 4. This means that the first byte of the file is actually the fourth byte of the flashrom, the second byte in the file is the third byte of the flashrom and so on.

"DCI-files" are another Nexus specific file format. A DCI-file contains only the blocks of a single file. The first 32 bytes of the file is the directory entry for the file (see above), exactly as it appears in the flashrom (no byte swapping). The "location of first block" field should be ignored when reading.

After the first 32 bytes each block of the file follows, in order. The blocks are byte-swapped just like in a DCM-file.