UNIF
From NESdevWiki
The Universal NES Interchange Format is a proposed replacement for the iNES ROM format, intended to remove the restriction and ambiguity of using arbitrary mapper numbers and store a wider range of data.
Contents |
[edit] File format
UNIF (file name suffix .unif, or .unf for outdated filesystems) consists of a short header followed by individual chunks containing various information about the ROM image. Multibyte values are stored in little endian.
Header:
- 00-03: File format identifier - ASCII text "UNIF"
- 04-07: Format revision - DWORD
- 08-1F: Reserved
Chunk header:
- 00-03: Chunk ID string, ASCII text
- 04-07: Chunk data length, DWORD
- 08-..: Chunk data
Chunk types:
- Some chunks have fixed lengths, while others are variable
- Each chunk has a revision number associated with it. The highest revision number among all of the chunks used should be placed in the main file header.
[edit] MAPR
- Length: variable
- Revision: 1
- Status: Required
- This describes the mapper hardware used on the cartridge. Do NOT use a mapper number here - instead, use a board name. The string is NULL-terminated.
- Examples:
[edit] READ
- Length: variable
- Revision: 1
- Status: Optional
- This should contain commentaries for the user of the ROM image. In the case of a homebrew game, this can contain credits, licensing information, mapper emulation information, or instructions on how to copy the program onto a cartridge.
[edit] NAME
- Length: variable
- Revision: 1
- Status: Optional
- A NULL-terminated string containing the name of the game should be stored here.
[edit] TVCI
- Length: 1 byte
- Revision: 6
- Status: Recommended
- This indicates Television Standards Compatability Information:
- 0 - 60 Hz system (NTSC)
- 1 - 50 Hz system (PAL)
- 2 - Multi-region
- Licensed games released in North America or Japan are 60 Hz (NTSC), while those released in Europe are 50 Hz (PAL).
[edit] DINF
- Length: 204 bytes
- Revision: 2
- Status: Optional
- Dumper information block:
- 100 bytes - NULL-terminated string containing the name of the person who dumped the ROMs from the cartridge
- 1 byte - ROM dump date - day
- 1 byte - ROM dump date - month
- 2 bytes - ROM dump date - year
- 100 bytes - NULL-terminated string containing the name of the software used to dump the ROMs
[edit] CTRL
- Length: 1 byte
- Revision: 7
- Status: Optional
- A bitfield containing information about the controllers used by the game.
- Bit 0: Regular Joypad
- Bit 1: Zapper
- Bit 2: R.O.B
- Bit 3: Arkanoid Controller
- Bit 4: Power Pad
- Bit 5: Four-Score adapter
- Bit 6: (expansion)
- Bit 7: (expansion)
[edit] PRG#
- Length: variable
- Revision: 4
- Status: PRG0 Required, others Optional
- Chunks "PRG0" through "PRGF" contain the binary data of the PRG ROMs on the cartridge. If more than 1 PRG ROM chip is present on the cartridge board, one chunk should be used for each chip, arranged in the logical order in which they are addressed via the mapper hardware. Most cartridges will only use "PRG0".
[edit] PCK#
- Length: 4 bytes
- Revision: 5
- Status: Optional
- Chunks "PCK0" through "PCKF" contain CRC-32 checksums which can be used to make sure that the corresponding PRG ROM blocks contain the correct data when burning to EPROMs.
[edit] CHR#
- Length: variable
- Revision: 4
- Status: CHR0 Required if CHR ROM is present, otherwise all are Optional
- Chunks "CHR0" through "CHRF" contain the binary data of the CHR ROMs on the cartridge. If more than 1 CHR ROM chip is present on the cartridge board, one chunk should be used for each chip, arranged in the logical order in which they are addressed via the mapper hardware. Most cartridges will only use "CHR0" if they have CHR ROM at all; cartridges containing only CHR RAM should omit this chunk.
[edit] CCK#
- Length: 4 bytes
- Revision: 5
- Status: Optional
- Chunks "CCK0" through "CCKF" contain CRC-32 checksums which can be used to make sure that the corresponding CHR ROM blocks contain the correct data when burning to EPROMs.
[edit] BATR
- Length: 1 byte
- Revision: 5
- Status: Recommended
- The presence of this chunk indicates that the board contains a battery used to preserve the contents of its expansion RAM. This is necessary because many boards are capable of supporting a battery (having traces and holes for a mounting bracket) but are not fitted with a battery during manufacturing time.
[edit] VROR
- Length: 1 byte
- Revision: 5
- Status: Optional
- The presence of this chunk indicates that a mapper which normally supports only CHR ROM is being made to use CHR RAM instead, intended for homebrew games which use boards such as NES-NROM-256 or NES-MHROM with CHR RAM instead of CHR ROM.
[edit] MIRR
- Length: 1 byte
- Revision: 5
- Status: Recommended
- This chunk describes how the nametable mirroring is configured on the board. In many cases, the board name alone cannot indicate the nametable mirroring scheme used, as sets of solder pads are used at manufacturing time to choose the desired mode.
- 0 - Horizontal Mirroring
- 1 - Vertical Mirroring
- 2 - Mirror All Pages From $2000
- 3 - Mirror All Pages From $2400 (deprecated, as it is indistinguishable from option 2 above)
- 4 - Four Screens of VRAM
- 5 - Mirroring Controlled By Mapper Hardware (necessary for some MMC3 boards)
