UNIF

UNIF (Universal NES Image Format) is a differently constrained and more descriptive format for holding NES and Famicom ROM images. It has not really caught on due to network effects. Nonetheless, certain games can only be stored as UNIF.

Since the standard has not been updated since 2000, this has not been updated to reflect the more recent findings that influenced the development of NES 2.0.

Official deprecation

On December 15th 2008, Tennessee Carmel-Veilleux, author of the UNIF format, sent a private Email to Jeremy Chadwick (founder of Parodius Networking) requesting that the official UNIF website be permanently deleted:

I would like you to completely terminate my site at http://www.parodius.com/~veilleux. Please delete it all, it is completely unlike who I am now, and it burns me that people would associate me with the stupid comments that are on there. I would really appreciate it. Plus UNIF was dead right from the get-go. I would thus really appreciate if you could deal with that.

...

Thanks in advance for getting rid of the UNIF website.

As such, the UNIF format should be considered officially defunct (i.e. should not be used or implemented).

Existing ROMs using UNIF (commonly .unf extension) should be converted to NES 2.0 or left unsupported.

Format

UNIF images start with a 32-byte header:

Offset	Length (bytes)	Value
0	4	"UNIF"
4	4	le32, minimum version number required to parse all chunks in file
8	24	all nulls

Followed by any number of Type+Length+Value blocks:

Offset	Length (bytes)	Value
0	4	Type, varies, defined below
4	4	le32, length
8	length	content encoding varies by type

Types

The following Types are known:

Type	Length	Minimum version required	Encoding	Content meaning
MAPR	variable	1	null-terminated UTF-8	A unique human-readable identifier specifying the exact hardware used; not an iNES mapper number, and not a full text description of the mapper; required
PRGn	variable, usually power of two	4	raw	the contents of the nth PRG ROM; at least PRG0 is required; n is in hexadecimal
CHRn	variable, usually power of two	4	raw	the contents of the nth CHR ROM
PCKn	4	5	le32	the CRC-32 of the nth PRG ROM
CCKn	4	5	le32	the CRC-32 of the nth CHR ROM
NAME	variable	1	null-terminated UTF-8	the name of the game
WRTR	variable	unknown	null-terminated UTF-8	unofficial, invalid. The name of the dumping software. Should be in a DINF chunk instead
READ	variable	1	null-terminated UTF-8	comments about the game, especially licensing information for homebrew
DINF	204	2	special	Dumping information Offset Length (bytes) Value 0 100 null-terminated UTF-8 dumper name 100 1 day-of-month of dump 101 1 month-of-year of dump 102 2 le16, year of dump 104 100 null-terminated UTF-8 the name of the dumping software or mechanism
TVCI	1	6	byte	TV standard compatibility information- 0. NTSC only 1. PAL only 2. compatible with both
CTRL	1	7	byte	Controllers usable by this game (bitmask) 1. Standard controller 2. Zapper 4. R.O.B. 8. Arkanoid controller 16. Power Pad 32. Four Score 64. expansion (leave cleared) 128. expansion (leave cleared)
BATR	1	5	byte	Boolean specifying whether the RAM is battery-backed.
VROR	1	5	byte	"If this chunk is present, then the CHR-ROM area will be considered as RAM even if ROM is present."
MIRR	1	5	byte	What CIRAM A10 is connected to: 0. PPU A11 (horizontal mirroring) 1. PPU A10 (vertical mirroring) 2. Ground (one-screen A) 3. Vcc (one-screen B) 4. Extra memory has been added (four-screen) 5. Mapper controlled

Shortcomings

Prior to 2013, no encoding was specified for any of the fields; 7-bit-clean ASCII was assumed, making NAME inadequate for the vast majority of non-US games. In the first quarter of 2013, UTF-8 became the encoding.

Chunks can come in any order, so conventional patching tools cannot work without going through an "unpacked" intermediary stage.

MAPR chunks are nominally supposed to use the text on the PCB, such as "NES-SNROM". However, some games have no identifying text on the PCB at all. Other games have only symbols in Japanese or Chinese. Sometimes the same PCB can have different incompatible behavior, depending on how things are populated or what things are jumpered. The workaround has been to add extra text the MAPR chunk (in the Crazy Climber case, "HVC-UNROM+74HC08").

There is no ability to specify PRG RAM outside of the MAPR chunk. Two games using VRC4 (Gradius II and Bio Miracle Bokutte Upa) use the exact same PCB, but the former adds 2KiB PRG RAM and the latter adds none.

For greater emulator compatibility, people sometimes use already-known-supported MAPR chunks to get something that's "close enough", rather than specifying a new MAPR for not-necessarily-identical behavior.

BATR chunks do not disambiguate which RAM is battery-backed, if more than one is present.

It's not clear exactly what VROR is supposed to mean—"Do not throw an error if this MAPR normally has CHR ROM but there are no CHRn chunks, just give me 8KiB of CHR RAM"? "All the data I gave you for CHR-ROM, that was actually RAM, make it writeable"?

CTRL chunks do not specify which controller should be plugged into which port, nor Famicom-only controllers, nor Super NES controllers plugged into a Famiclone or through an adapter (such as the 12-key controller or the mouse). Then again, iNES and NES 2.0 don't even try to include controller metadata in the ROM file; instead, there is a proposal in the works for a separate metadata file.

No way to fully describe PlayChoice 10 or Vs. System games.

References

Last published version of the standard: http://libunif.googlecode.com/files/UNIF_current.txt