ROM Header
Standard header
The following table shows the standard contents of the ROM header. Most of the structure of the header is defined by the IPL3 routines commonly used in commercial games (which are actually contained in the ROM itself); only a few fields are accessed by IPL2 (which is burned in PIF ROM) and are thus hard-coded for all possible valid N64 ROMs.
Offset | Bytes | Name | Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x00 | 4 | PI DOM1 configura flags | These flags are used by IPL2 to configure access to the ROM (which is mapped in the PI DOM1 space, see memory map). IPL2 first configure the PI to its slowest speed to be able to read these 4 bytes, and then use them to configure the correct speed to access the ROM.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x04 | 4 | Clock override(?) | Usually 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x08 | 4 | Initial PC | Initial PC in RDRAM. IPL3 will jump to this address when it has finished initializing the hardware, to boot the ROM.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0C | 3 | ? | ? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0F | 1 | Libultra Version | This byte contains a ASCII letter that indicates the libultra version the game was compiled with. For instance, "L" would indicate libultra 2.0L.
This is not used by IPL or anything else, it is just for information; moreover, many games report the wrong version here. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x10 | 8 | Checksum | 64-bit checksum calculated on 1 Mbyte of ROM contents starting from offset 0x1000 (after IPL3). This checksum is computed with a custom algorithm implemented by IPL3 that verifies the integrity of the ROM before booting it. If the checksum fails, IPL3 refuses to boot the ROM and hangs the console.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x18 | 8 | ? | ? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x20 | 20 | Game name | String that contains the name of the game. The encoding is usually either ASCII or JIS X 0201 (a subset of Shift-JIS). Padding Is usually performed with 0x20 (ASCII space). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x34 | 7 | Unused | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x3B | 1 | Media format | An ASCII character identifying the physical support that this ROM was extracted from.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x3C | 2 | Game ID | Two letter code to identify the game. Normally, these are ASCII uppercase letters. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x3E | 1 | Country code | An ASCII character that specifies the country this ROM is intended for.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x3F | 1 | ROM revision | This byte is used to identify the revision of the game. Normally the value is 0x01 for the first revision, 0x02 for the second and so on. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x40 | 4032 | IPL3 | This area contains the IPL3 boot code. Each ROM ships its own IPL3 that is meant to work together with the CIC installed in the ROM. Before running IPL3, IPL2 checks its checksum also using a seed coming from the CIC, which binds each IPL3 code to a specific version of CIC. |
Advanced Homebrew ROM Header
The Advanced Homebrew ROM Header format is a convention that has been agreed upon in the N64 homebrew community to add additional information in the header, using unused fields. The goal of this convention is to let homebrew ROMs declare the correct saveype and controllers that are expected to play the game. The format has been introduced by the EverDrive 64 flashcard and has been later enhanced by the homebrew community.
This is useful because emulators normally work using a game database which matches games using checksum to find out which savetype and controllers are expected by the game, to help gamers play the game. For instance, when a N64 emulator detects that a Perfect Dark ROM is loaded, it will automatically emulate a 16Kb EEPROM to save the game (that was the original support present in the physical cartridge for the original game), and will possibly also emulate a preinstalled Transfer PAK, as the accessory can be used with the game. This is done purely by matching the Perfect Dark ROM checksum in a database, so a homebrew game, which would probably not be present in game databases, would suffer from non-working saves and possibly wouldn't be able to use special controllers or accessories.
Instead, by using the Advanced Hombrew ROM Header, emulators can automatically configure the required emulated hardware as expected without having to keep any additional database, by simply decoding specific fields of the ROM header. In addition to emulators, also development flashcarts and loaders can use this format to automatically configure the correct savetype when the ROM is loaded.
Homebrew ROM Header special flags
Offset | Bytes | Name | Description | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x36 | 1 | Controller 1 | This byte contains the suggested / expected controller hardware that should be attached to port 1.
Values 0x01-0x7F indicate a standard N64 controller, possibly with some installed pak. Values 0x80-0xFE indicate a different kind of controller.
| ||||||||||||||||||||
0x37 | 1 | Controller 2 | This byte contains the suggested / expected controller hardware that should be attached to port 2. See byte 0x36 for more information. | ||||||||||||||||||||
0x38 | 1 | Controller 3 | This byte contains the suggested / expected controller hardware that should be attached to port 3. See byte 0x36 for more information. | ||||||||||||||||||||
0x39 | 1 | Controller 4 | This byte contains the suggested / expected controller hardware that should be attached to port 4. See byte 0x36 for more information. | ||||||||||||||||||||
0x3C | 2 | Game ID | This must contain the ASCII characters "ED". It is used as an ID to identify that the Advanced Homebrew ROM header format Is being used by this ROM. | ||||||||||||||||||||
0x3F | 1 | Savetype | This byte mostly contains information on the savetype. It must be decoded as a bitfield:
|
Support by emulators
Emulators not listed here do not support the advanced homebrew ROM header format.
Emulator | Current support |
---|---|
Ares | Supports Savetype only |
cen64 | Supports Savetype only |
Support by flashcarts
Support by flashcarts can vary depending on the USB loader being used and/or the flashcart operating system. Notice that flashcarts can emulate a specific savetype but have nothing to do with controllers, so the maximum expected support is related to savetype.
Flashcart | Loader | Current support |
---|---|---|
64drive | 64drive official C tool | None |
64drive menu | None | |
g64drive | Savetype supported | |
UNFLoader | None | |
Everdrive 64 | Menu | Savetype supported |
ed64 | None | |
UNFLoader | None |