A DS game keeps its data in files and directories, a file system called NitroFS (or NitroROM). It is made of two tables whose places the
header gives: the file name table (FNT) holds the names and the structure, and the file allocation table (FAT) holds where each file is.
The layout is from GBATEK (“DS Cartridge NitroROM and NitroARC File Systems”) and agrees with the
structures in DeSmuME’s fsnitro code. The explorer lists the directories and files, and each file opens as bytes.
File name table
Directory table
The table starts with one 8-byte entry for each directory. Directory numbers start at 0xF000, the root.
| Offset | Size | Field | What it holds |
|---|---|---|---|
0x00 | 4 | Sub-table offset | Where this directory’s list of names is, counted from the start of the file name table. |
0x04 | 2 | First file ID | 0x0000–0xEFFF: the number of the first file in the list. |
0x06 | 2 | Parent, or the count | In the root entry (0xF000): the total number of directories, 1 to 4096. In the others (0xF001 and up): the number of the parent directory. |
Name lists
The lists follow the directory table. Each is a run of entries ending with a zero byte.
| Offset | Size | Field | What it holds |
|---|---|---|---|
0x00 | 1 | Type and length | 0x01–0x7F: a file, with a name of that many characters. 0x81–0xFF: a directory, with a name of the length in the low 7 bits. 0x00: the end of the list. 0x80: reserved. |
0x01 | length | Name | Case-sensitive ASCII, not zero-terminated. |
| after the name | 2 | Directory number | For a directory entry only: 0xF001–0xFFFF. |
A file entry has no number of its own: files are numbered in order, starting from the directory’s first file ID.
File allocation table
| Offset | Size | Field | What it holds |
|---|---|---|---|
0x00 | 4 | Start | Where the file begins in the ROM; 0 is an unused entry. |
0x04 | 4 | End | Start plus the size; 0 is an unused entry. |
The entry for file n is the nth, from 0. A ROM can hold up to 61,440 files. The files named in the file name table and the files of the overlays are all in this table; an overlay’s file need not be named.
Overlay tables
An overlay is a part of a program that is loaded when needed, over other code. The header holds a table for the ARM9 and one for the ARM7, with an entry of 32 bytes for each overlay.
| Offset | Size | Field | What it holds |
|---|---|---|---|
0x00 | 4 | Overlay ID | |
0x04 | 4 | RAM address | Where it is loaded. |
0x08 | 4 | RAM size | How much is loaded. |
0x0C | 4 | BSS size | |
0x10 | 4 | Static initialiser start | The address of the first. |
0x14 | 4 | Static initialiser end | |
0x18 | 4 | File ID | 0x0000–0xEFFF: the file of the allocation table that holds it. |
0x1C | 4 | Reserved | Zero. |
What the viewer does
- It reads the directory table, follows every directory from the root and gives each file its number and its full path, and reports a directory that is reached twice, a directory that is not reached, a parent that disagrees with the directory it was listed in, and names that run past the table.
- It reads the allocation table and shows each file’s start and size, with the state: unused entry, end before start, beyond the file, or inside the header.
- It shows the tree of the file name table (the directory entries and each list), the table of files, and the files in the order they lie in the ROM. Files that overlap each other or other parts of the ROM are listed but left out of the tree.
- It does not read the formats of the files (NitroSDK graphics, models and sound files).