FDS disk format
The Famicom Disk System uses disks that are a modified version of Mitsumi Quick Disk hardware, with a custom data format stored on the disk.
Each side can hold more than 64KB of data.
For archive and emulation, dumps of these disks are often preserved using the FDS file format (.FDS).
Each disk side must be structured into block as follows :
1, 2, 3, 4, 3, 4, …., 3, 4
The 3, 4 pattern should be repeated once per file present on the disk.
Blocks type 1 and 2 represent information about the disk and how many files it has, and each block type 3 and 4 pair represents a single file. See Block format below.
Physically on the disk, there are “gaps” of 0 recorded between blocks and before the start of the disk. Length of the gaps are as follows:
- Before the start of the disk : At least 26150 bits, 28300 typical.
- Gap between blocks : At least 480 bits, 976 bits typical.
Gaps are teminated by a single ‘1’ bit. In terms of bytes, it would be $80, as the data is stored in little endian format.
At the end of each block, a 16-bit CRC is stored. This CRC is not calculated by the CPU executing the BIOS code, but by the RP2C33 handling the disk drive signals. It will automatically set $4030.D4 = 1 (leading to error code 27) if a block’s CRC value does not match the calculated one during loading.
The CRC algorithm used is the common CRC-16/KERMIT algorithm. The ‘1’ bit at the end of the gap is included in the calculation.
The commonly used FDS file format is limited to 65500 bytes per side and does not contain CRCs or gaps. The QD file format observed in rereleases on Nintendo platforms is limited to 65536 bytes per side and contains CRCs, but no gaps.
The actual disk capacity is somewhat larger, and there are a few variant disk formats that may have even more capacity.
| Offset | Length (bytes) | Description | Details |
|---|---|---|---|
| $00 | 1 | Block code | Raw byte: $01 |
| $01 | 14 | Disk verification | Literal ASCII string: *NINTENDO-HVC*Used by BIOS to verify legitimate disk image |
| $0F | 1 | Licensee code | See Licensee codes |
| $10 | 3 | Game name | 3-letter ASCII code per game (e.g. ZEL for The Legend of Zelda) |
| $13 | 1 | Game type | $20 = " " — Normal disk$45 = "E" — Event (e.g. Japanese national DiskFax tournaments)$4A = "J" — Unknown. May indicate Family Computer Network Adapter$52 = "R" — Reduction in price via advertising |
| $14 | 1 | Game version | Starts at $00, increments per revision |
| $15 | 1 | Side number | $00 = Side A, $01 = Side B. Single-sided disks use $00 |
| $16 | 1 | Disk number | First disk is $00, second is $01, etc. |
| $17 | 1 | Disk type (FMC) | $01 for FMC blue-disk releases, and $00 otherwise [1] |
| $18 | 1 | Unknown | $00 in all known games |
| $19 | 1 | Boot read file code | Refers to the file code/file number to load upon boot/start-up |
| $1A | 5 | Unknown | Raw bytes: $FF $FF $FF $FF $FF |
| $1F | 3 | Manufacturing date | See Date format |
| $22 | 1 | Country code | $49 = Japan |
| $23 | 1 | Unknown | Raw byte: $61. Speculative: Region code? |
| $24 | 1 | Unknown | Raw byte: $00. Speculative: Location/site? |
| $25 | 2 | Unknown | Raw bytes: $00 $02 |
| $27 | 5 | Unknown | Speculative: some kind of game information representation? |
| $2C | 3 | "Rewritten disk" date | See Date format. It's speculated this refers to the date the disk was formatted and rewritten by something like a Disk Writer kiosk. In the case of an original (non-copied) disk, this should be the same as Manufacturing date |
| $2F | 1 | Unknown | |
| $30 | 1 | Unknown | Raw byte: $80 |
| $31 | 2 | Disk Writer serial number | |
| $33 | 1 | Unknown | Raw byte: $07 |
| $34 | 1 | Disk rewrite count | Value stored in BCD format. $00 = Original (no copies). |
| $35 | 1 | Actual disk side | $00 = Side A, $01 = Side B |
| $36 | 1 | Disk type (other) | $00 = yellow disk, $FF = blue disk, $FE = prototype, sample, or internal-use (white or pink) disk. Some prototype disks have been observed with value $00, but this may indicate the field was simply not filled in. |
| $37 | 1 | Disk version | Unknown how this differs from game version ($14). Disk version numbers indicate different software revisions. Speculation is that disk version incremented with each disk received from a licensee. |
| $38 | 2 | CRC | (Omitted from .FDS files) |
The *NINTENDO-HVC* string, stored in ASCII, proves that this is a FDS disk. If the string doesn’t match, the BIOS will refuse to read the disk further.
If the FDS is started with a disk whose side number and disk number aren’t both $00, it will be prompted to insert the first disk side. However, some games make this number $00, even for the second disk to make it bootable too.
All files with IDs smaller or equals to the boot read file code will be loaded when the game is booting.
All bytes are stored in BCD format, in order of year, month, and day. The year is usually represented as the 1-indexed number of years since the start of the current Japanese calendar era, either the Shōwa era (1926) or Heisei era (1989). Values observed are $61-63 for 1986-1988 and $01-03 for 1989-1991. Disk Writer kiosks continued to use Shōwa era dates beyond the end of the Shōwa era, so disks written by the service up to its discontinuation in 2003 may have year values as high as $78.
A small number of games used the last two digits of the current year instead of a Japanese calendar date. Values observed are $85-$86 for 1985-1986.
This block contains the total number of files recorded on disk.
| Offset | Length (bytes) | Description | Details |
|---|---|---|---|
| $00 | 1 | Block code | Raw byte: $02 |
| $01 | 1 | File Amount | |
| $02 | 2 | CRC | (Omitted from .FDS files) |
More files might exist on the disk, but the BIOS load routine will ignore them, those files are called “hidden” files. Some games have a simple copy protection this way: They have their own loading routine similar to the one from the BIOS but hard-code the file amount to a higher number, which will allow for loading hidden files. This also allows the game to load faster because the BIOS will stop reading the disk after the last non-hidden file.
This block stores metadata for the file data block which follows it. Because the BIOS has to manually seek through the disk one byte at a time, it relies on the header block fields to correctly load or skip file data blocks.
| Offset | Length (bytes) | Description | Details |
|---|---|---|---|
| $00 | 1 | Block code | Raw byte: $03 |
| $01 | 1 | File Number | |
| $02 | 1 | File ID | The ID specified at disk-read function call. |
| $03 | 8 | File Name | Typically in uppercase ASCII. |
| $0B | 2 | File Address | 16-bit little-endian. The destination address when loading. |
| $0D | 2 | File Size | 16-bit little-endian. |
| $0F | 1 | File Type | 0: Program (PRG-RAM) 1: Character (CHR-RAM) 2: Nametable (VRAM) |
| $10 | 2 | CRC | (Omitted from .FDS files) |
File Numbers are generally in increasing order, first file is 0. The BIOS does not use file Numbers during reads, and file Numbers written when calling AppendFile/WriteFile are manually counted from the first file.
File IDs can be freely assigned, and this is the number which will decide which file is loaded from the disk (instead of the file number). For example, the parameter disks for Quick Hunter uses identical file Numbers for everything except the first file and only distinguishes them by file IDs. A file ID smaller or equal to than the boot read file code means the file is a boot file, and will be loaded on first start up.
The BIOS only writes to the PPU when the file type is not equal to 0, so types 2 and above are functionally identical to type 1.
This block stores the actual file data.
| Offset | Length (bytes) | Description | Details |
|---|---|---|---|
| $00 | 1 | Block code | Raw byte: $04 |
| $01 | – | File data | |
| – | 2 | CRC | (Omitted from .FDS files) |
| Offset | Length (bytes) | Description | Details |
|---|---|---|---|
| $00 | 1 | Block code | Raw byte: $05 |
| $01 | – | Test data | Repeating sequence of $6D, $B6, $DB to fill the disk side. |
| – | 2 | CRC | (Omitted from .FDS files) |
This block type and fragments of its data has been observed in retail disks. It appears to be test data used during the disk formatting process. FMC Disk Card Checker is capable of writing and verifying this block.
Because the disk format is only enforced in software by the BIOS disk I/O routines, custom formats are possible through the use of low-level disk I/O routines.
Some unlicensed disks have been observed to use non-standard formats, often as a means of copy-protection:
- Kosodate Gokko stores its main program without any block indicator and loads it using the BIOS’ disk IRQ handler. (data is prefixed with a $12 byte)
- Quick Hunter uses a block type of 0 to store its encrypted main program. (data is XORed with $C9) Note that common dumps of this disk lack the needed 0 byte.
- Graphic Editor Hokusai and Jingorou use a custom format (interleaved + encrypted PRG/CHR data) with fake file header/data blocks for their main programs.
- Game Doctor/Magic Card devices switch in a replacement BIOS to load custom disk formats.
- Block type 5 is used by some Magic Card 1M/2M/4M disks to store trainer data.
- FDS file format (.FDS)
- QD file format (.QD)
- FDS technical reference.txt by Brad Taylor
- Enri’s Famicom Disk System page (Japanese)
- Enri’s Famicom Disk System page (Japanese) (old/outdated)
- Fantasy’s FDS Maniacs page (Japanese). Technical information is in the ディスクシステム資料室 section.
- FDS Study site via archive.org (Japanese). The FDSStudy program can still be found here.
- fds-nori.txt - FDS reference in Japanese by Nori
- Forum post: .fds format: Can checksums be heuristically detected? - Includes a CRC implementation in C.
- Forum thread: Block type 5 in non-Game-Doctor FDS disks
- Forum thread: Copy protection methods on FDS disks
- ↑ FamicomWorld: FMC and FSC product codes