ROM header

Nintendo required SNES developers to include a header in the game's data that describes what hardware the game cartridge contains. This is not needed by the SNES hardware, though the game software can access it as ROM data.

However, emulators and flashcarts rely on this header to know how to emulate the game cartridge. Homebrew games should also provide a valid header. Example code: lorom-template

The header is located at the CPU address range $00FFC0-$00FFDF, right before the interrupt vectors, with an optional second header at $00FFB0-$00FFBF. This means that the location of the header within the actual ROM file will change based on the cartridge's memory map mode - with LoROM games placing it at $007Fxx, HiROM games placing it at $00FFxx, and ExHiROM games placing it at $40FFxx. Therefore, if it's correctly filled out, an emulator will have a higher chance of being able to figure out where the header is. See: Header Verification below.

This internal ROM header is to be confused with the additional 512-byte headers used by copier devices. See: ROM file formats

See also: Memory map

Cartridge header

Header contents

First address	Length	Contents
$FFC0	21	Cartridge title (21 bytes uppercase ASCII. Unused bytes should be spaces.)
$FFD5	1	ROM speed and memory map mode (LoROM/HiROM/ExHiROM)
$FFD6	1	Chipset (Indicates if a cartridge contains extra RAM, a battery, and/or a coprocessor)
$FFD7	1	ROM size: 1<<N kilobytes, rounded up (so 8=256KB, 12=4096KB and so on)
$FFD8	1	RAM size: 1<<N kilobytes (so 1=2KB, 5=32KB, and so on)
$FFD9	1	Country (Implies NTSC/PAL)
$FFDA	1	Developer ID
$FFDB	1	ROM version (0 = first)
$FFDC	2	Checksum
$FFDE	2	Checksum compliment (Checksum ^ $FFFF)
$FFE0	32	Interrupt vectors

$FFD5

Address $00FFD5 indicates the ROM speed and map mode.

001smmmm
   |++++- Map mode
   +----- Speed: 0=Slow, 1=Fast

Available modes include:

• 0: LoROM
• 1: HiROM
• 5: ExHiROM

$FFD6

Address $00FFD6 indicates what extra hardware is in the cartridge, if any.

Possible values include:

• $00 - ROM only
• $01 - ROM + RAM
• $02 - ROM + RAM + battery
• $x3 - ROM + coprocessor
• $x4 - ROM + coprocessor + RAM
• $x5 - ROM + coprocessor + RAM + battery
• $x6 - ROM + coprocessor + battery
• $0x - Coprocessor is DSP (DSP-1, 2, 3 or 4)
• $1x - Coprocessor is GSU (SuperFX)
• $2x - Coprocessor is OBC1
• $3x - Coprocessor is SA-1
• $4x - Coprocessor is S-DD1
• $5x - Coprocessor is S-RTC
• $Ex - Coprocessor is Other (Super Game Boy/Satellaview)
• $Fx - Coprocessor is Custom (specified with $FFBF)

When coprocessor is Custom, $FFBF selects from:

• $00 - SPC7110
• $01 - ST010/ST011
• $02 - ST018
• $03 - CX4

Expanded cartridge header

The expanded header's presence is indicate by putting $33 in $00FFDA, which is the developer ID. Some early games may indicate just $00FFBF by setting $00FFD4 to zero.

Expanded header contents

First address	Length	Contents
FFB0	2	ASCII maker code
FFB2	4	ASCII game code
FFB6	6	Reserved, should be zero
FFBC	1	Expansion flash size: 1 << N kilobytes
FFBD	1	Expansion RAM size: 1 << N kilobytes - for GSU?
FFBE	1	Special version (usually zero)
FFBF	1	Chipset subtype, used if chipset is $F0-$FF

Checksum

The checksum is a 16-bit sum of all of the bytes in the ROM, potentially with some portions repeated. It is always computed as if the ROM is a power of 2 in size, though some SNES games are not. For example, some games use multiple ROM chips together, and so their size is often the sum of two powers of 2 (e.g. a 3MB game might use a 2MB ROM and a 1MB ROM together).

Before calculating the checksum, if the data is not already a power of 2 in size, we must repeat some of the data until it is a power of 2 in a way that matches how it will be mirrored in the memory map. For most ROMs that are not already a power of 2, this is normally done just by duplicating the last third of the ROM. In general, though, this resizing is done as follows:

1. Find the largest power of 2 less than or equal to the data size.
2. If data remains past this point:

Find the smallest power of 2 greater than or equal to this remainder.

Pad the remainder with 0s to meet this power of 2.*

Now that the remainder is a power of 2, repeat this data until the remainder matches the size of the first part of the ROM (the power of 2 in step 1).

* Note: This padding is outside the specification, and emulators are inconsistent about how to pad. It is recommended to ensure your ROM file's remainder reaches a power of 2 boundary.

Because the ROM header will be part of the computed checksum, before computing the checksum we must first fill the header's checksum and complement values with $0000 and $FFFF. Any value plus its complement will produce the same result, so this ensures the resulting checksum matches the ROM even after the computed checksum is placed in the header.

Once ready:

1. Start with a 16-bit checksum = 0.
2. Add every byte from the prepared data to the checksum. (Overflow is discarded.)
3. Store the checksum in the ROM header ($FFDC or equivalent).
4. Store checksum ^ $FFFF in the ROM header ($FFDE).

Header Verification

The primary way to verify a candidate header is to evaluate the checksum it contains. Some flash-carts appear to use only the checksum to distinguish LoROM from HiROM.

If no valid checksum can be found (e.g. ROM-hacks or homebrews often omit it), additional heuristics may be used to estimate validity:

• ROM checksum matches.
• Checksum and compliment sum to $FFFF.
• Map mode matches header location.
• Specified ROM size is not smaller than file size.
• A reset vector < $8000 is invalid because it points outside of ROM.
• The first instruction at a valid reset vector is likely to be: sei, clc, sec, stz, jmp, jml
• The first instruction at a valid reset vector is unlikely to be: brk, cop, stp, wdm, $FF (sbc long)
• ROM and RAM sizes are reasonable.
• Game name field is ASCII characters only.