UNIF: Difference between revisions
m (I really need pie menus) |
(if it's officially utf-8, we should stop asserting that it's not. reorder PRGRAM comment for greater clarity. Snark about CTRL.) |
||
| Line 9: | Line 9: | ||
0 4 "UNIF" | 0 4 "UNIF" | ||
4 4 le32, minimum version number required to parse all chunks in file | 4 4 le32, minimum version number required to parse all chunks in file | ||
8 28 all | 8 28 all nulls | ||
Followed by any number of Type+Length+Value blocks: | Followed by any number of Type+Length+Value blocks: | ||
| Line 24: | Line 24: | ||
! Type !! Length !! Minimum version required !! encoding !! content meaning | ! Type !! Length !! Minimum version required !! encoding !! content meaning | ||
|- | |- | ||
| MAPR || variable || 1 || null-terminated | | 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 | ||
|- | |- | ||
| PRG''n'' || variable, should be power of two || 4 || raw || the contents of the ''n''th PRG ROM; at least PRG0 is required; ''n'' is in hexadecimal | | PRG''n'' || variable, should be power of two || 4 || raw || the contents of the ''n''th PRG ROM; at least PRG0 is required; ''n'' is in hexadecimal | ||
| Line 34: | Line 34: | ||
| CCK''n'' || 4 || 5 || le32 || the CRC-32 of the ''n''th CHR ROM | | CCK''n'' || 4 || 5 || le32 || the CRC-32 of the ''n''th CHR ROM | ||
|- | |- | ||
| NAME || variable || 1 || null-terminated | | NAME || variable || 1 || null-terminated UTF-8 || the name of the game | ||
|- | |- | ||
| WRTR || variable || unknown || null-terminated | | WRTR || variable || unknown || null-terminated UTF-8 || unofficial? the name of the dumping software. Should be in the DINF Type instead | ||
|- | |- | ||
| READ || variable || 1 || null-terminated | | READ || variable || 1 || null-terminated UTF-8 || comments about the game, especially licensing information for homebrew | ||
|- | |- | ||
| DINF || 204 || 2 || special || Dumping information- | | DINF || 204 || 2 || special || Dumping information- | ||
offset length(bytes) value | offset length(bytes) value | ||
0 100 | 0 100 null-terminated UTF-8 dumper name | ||
100 1 day-of-month of dump | 100 1 day-of-month of dump | ||
101 1 month-of-year of dump | 101 1 month-of-year of dump | ||
102 2 year of dump | 102 2 year of dump | ||
104 100 | 104 100 null-terminated UTF-8 the name of the dumping software or mechanism | ||
|- | |- | ||
| TVCI || 1 || 6 || byte || TV standard compatibility information- | | TVCI || 1 || 6 || byte || TV standard compatibility information- | ||
| Line 101: | Line 101: | ||
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. | 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 [[Standard controller|12-key controller]] or the [[mouse]]). | 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 [[Standard controller|12-key controller]] or the [[mouse]]). (Then again, [[iNES]] doesn't even try) | ||
BATR chunks do not disambiguate which RAM is battery-backed, if more than one is present. | 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 ([http://bootgod.dyndns.org:7777/profile.php?id= | There is no ability to specify PRG RAM outside of the MAPR chunk. Two games using VRC4 ([http://bootgod.dyndns.org:7777/profile.php?id=1565 Gradius II] and [http://bootgod.dyndns.org:7777/profile.php?id=3988 Bio Miracle Bokutte Upa]) use the exact same PCB, but the former adds 2KiB PRG RAM and the latter adds none. | ||
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"? | ||
Revision as of 17:17, 7 September 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 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, 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 UTF-8 | the name of the game | ||||||||||||||||
| WRTR | variable | unknown | null-terminated UTF-8 | unofficial? the name of the dumping software. Should be in the DINF Type 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 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-
| ||||||||||||||||
| CTRL | 1 | 7 | byte | Controllers usable by this game (bitmask)
| ||||||||||||||||
| 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:
|
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). (Then again, iNES doesn't even try)
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 (Gradius II and Bio Miracle Bokutte Upa) use the exact same PCB, but the former adds 2KiB PRG RAM and the latter adds none.
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
