UNIF: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(→‎Shortcomings: UTF-8 adoption)
m (I really need pie menus)
Line 109: Line 109:
It's not clear what VROR is supposed to mean—"Do not throw an error if this MAPR normally has CHR ROM, just give me 8KiB of CHR RAM"? "All the data I gave you for CHR-ROM, that was actually RAM, make it writeable"?
It's not clear what VROR is supposed to mean—"Do not throw an error if this MAPR normally has CHR ROM, just give me 8KiB of CHR RAM"? "All the data I gave you for CHR-ROM, that was actually RAM, make it writeable"?


Prior to 2013, no encoding is ever 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, [http://forums.nesdev.org/styles/subsilver2/imageset/icon_post_target.gif UTF-8 became the encoding].
Prior to 2013, no encoding is ever 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, [http://forums.nesdev.org/viewtopic.php?f=3&t=9883 UTF-8 became the encoding].


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

Revision as of 22:33, 4 March 2013

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.

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      28         all nuls

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 ASCII 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, should be power of two 4 raw the contents of the nth PRG ROM; at least PRG0 is required; n is in hexadecimal
CHRn variable, should be 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 ASCII the name of the game
WRTR variable unknown null-terminated ASCII unofficial? the name of the dumping software. Should be in the DINF Type instead
READ variable 1 null-terminated ASCII comments about the game, especially licensing information for homebrew
DINF 204 2 special Dumping information-
 offset  length(bytes)  value
      0            100  ASCIIZ dumper name
    100              1  day-of-month of dump
    101              1  month-of-year of dump
    102              2  year of dump
    104            100  ASCIIZ 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 Boolean specifying whether CHRn should be ignored and replaced with RAM
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

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").

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.

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).

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

There is no ability to specify PRG RAM outside of the MAPR chunk. Two games using VRC4 (Bio Miracle Bokutte Upa and Gradius II) use the exact same PCB, but one has 2KB PRG RAM and the other doesn't.

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

Prior to 2013, no encoding is ever 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.

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