NES 2.0: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(Initial import of spec text, per kevtris' OK on efnet #nesdev today)
(Another Plug-and-Play thing)
 
(162 intermediate revisions by 18 users not shown)
Line 1: Line 1:
'''NES 2.0''' is an extension to the [[iNES]] executable format, [http://nesdev.parodius.com/bbs/viewtopic.php?p=17727#17727 proposed] by Kevin Horton on 2006-09-18.
'''NES 2.0''' extends the [[iNES]] single file cart format to better describe NES/Famicom-compatible cartridge hardware. Some of its purpose include:
He has implemented it in his FPGA NES.
* Removing the need to use ROM checksums, or other information outside the header, to disambiguate emulation behavior not encoded by iNES.
* Making room for new mapper allocation.
* Allowing for larger ROM sizes.
* Supporting other than standard NES/Famicom console types such as the Nintendo Vs. System and enhanced Famiclones.
* Providing additional information such as the region-specific CPU/PPU type and default expansion port devices.
* Replaces the deprecated [[UNIF]] format.


== Unwikified portion ==
The format is [[#Backwards Compatibility to iNES|backwards-compatible]] to iNES, so that ROM images with a NES 2.0 header run in non-NES-2.0-compliant emulators as long as they do not require NES-2.0-exclusive features.
<pre>
                    NES 2.0 File Addition Specification
                    -----------------------------------


=Identification=
A file is a NES 2.0 ROM image file if it begins with "NES<EOF>" (same as iNES) and, additionally, the byte at offset 7 has bit 2 clear and bit 3 set:
bool iNESFormat=false;
if (header[0]=='N' && header[1]=='E' && header[2]=='S' && header[3]==0x1A)
        iNESFormat=true;
bool NES20Format=false;
if (iNESFormat==true && (header[7]&0x0C)==0x08)
        NES20Format=true;
=File Structure=
A NES 2.0 file contains a sixteen-byte header, followed by Trainer, PRG-ROM, CHR-ROM and Miscellaneous ROM data.


Version 1.00
==Header==
09/18/06
Offset Meaning
Written by K.Horton
--------------
Thanks to Quietust for ideas and proofing and help
0-3    Identification String. Must be "NES<EOF>".
----
4      [[#PRG-ROM Area|PRG-ROM]] size LSB
5      [[#CHR-ROM Area|CHR-ROM]] size LSB
6      Flags 6
        D~7654 3210
          ---------
          NNNN FTBM
          |||| |||+-- [[#Nametable layout|Hard-wired nametable layout]]
          |||| |||    0: Vertical arrangement ("mirrored horizontally") or mapper-controlled
          |||| |||    1: Horizontal arrangement ("mirrored vertically")
          |||| ||+--- "Battery" and other non-volatile memory
          |||| ||      0: Not present
          |||| ||      1: Present
          |||| |+--- 512-byte [[#Trainer Area|Trainer]]
          |||| |      0: Not present
          |||| |      1: Present between Header and PRG-ROM data
          |||| +---- [[#Nametable layout|Alternative nametables]]
          ||||        0: No
          ||||        1: Yes
          ++++------ Mapper Number D3..D0
7      Flags 7
        D~7654 3210
          ---------
          NNNN 10TT
          |||| ||++- Console type
          |||| ||    0: Nintendo Entertainment System/Family Computer
          |||| ||    1: Nintendo [[Vs. System]]
          |||| ||    2: Nintendo [[PC10 ROM-Images|Playchoice 10]]
          |||| ||    3: [[#Extended Console Type|Extended Console Type]]
          |||| ++--- NES 2.0 identifier
          ++++------ Mapper Number D7..D4
8      [[Mapper]] MSB/[[Submapper]]
        D~7654 3210
          ---------
          SSSS NNNN
          |||| ++++- Mapper number D11..D8
          ++++------ Submapper number
9      [[#PRG-ROM Area|PRG-ROM]]/[[#CHR-ROM Area|CHR-ROM]] size MSB
        D~7654 3210
          ---------
          CCCC PPPP
          |||| ++++- PRG-ROM size MSB
          ++++------ CHR-ROM size MSB
10    [[#PRG-(NV)RAM/EEPROM|PRG-RAM/EEPROM]] size
        D~7654 3210
          ---------
          pppp PPPP
          |||| ++++- PRG-RAM (volatile) shift count
          ++++------ PRG-NVRAM/EEPROM (non-volatile) shift count
        If the shift count is zero, there is no PRG-(NV)RAM.
        If the shift count is non-zero, the actual size is
        "64 << shift count" bytes, i.e. 8192 bytes for a shift count of 7.
11    [[#CHR-(NV)RAM|CHR-RAM]] size
        D~7654 3210
          ---------
          cccc CCCC
          |||| ++++- CHR-RAM size (volatile) shift count
          ++++------ [[:Category:Mappers with battery-backed CHR-RAM|CHR-NVRAM]] size (non-volatile) shift count
        If the shift count is zero, there is no CHR-(NV)RAM.
        If the shift count is non-zero, the actual size is
        "64 << shift count" bytes, i.e. 8192 bytes for a shift count of 7.
12    [[#CPU/PPU Timing|CPU/PPU Timing]]
        D~7654 3210
          ---------
          .... ..VV
                ++- CPU/PPU timing mode
                      0: RP2C02 ("NTSC NES")
                      1: RP2C07 ("Licensed PAL NES")
                      2: Multiple-region
                      3: UA6538 ("Dendy")
13    When Byte 7 AND 3 =1: [[#Vs. System Type|Vs. System Type]]
        D~7654 3210
          ---------
          MMMM PPPP
          |||| ++++- Vs. PPU Type
          ++++------ Vs. Hardware Type
        When Byte 7 AND 3 =3: [[#Extended Console Type|Extended Console Type]]
        D~7654 3210
          ---------
          .... CCCC
              ++++- Extended Console Type
14    [[#Miscellaneous ROM Area|Miscellaneous ROMs]]
        D~7654 3210
          ---------
          .... ..RR
                ++- Number of miscellaneous ROMs present
15    [[#Default Expansion Device|Default Expansion Device]]
        D~7654 3210
          ---------
          ..DD DDDD
            ++-++++- Default Expansion Device


==Trainer Area==
The Trainer Area follows the 16-byte Header and precedes the PRG-ROM area if bit 2 of Header byte 6 is set. It is always 512 bytes in size if present,
and contains data to be loaded into CPU memory at $7000. It is only used by some games that were modified to run on different hardware from the original cartridges,
such as early RAM cartridges and emulators, and which put some additional compatibility code into those address ranges.
==PRG-ROM Area==
The PRG-ROM Area follows the 16-byte Header and the Trainer Area and precedes the CHR-ROM Area. Header byte 4 (LSB) and bits 0-3 of Header byte 9 (MSB) together specify its size.
If the MSB nibble is $0-E, LSB and MSB together simply specify the PRG-ROM size in 16 KiB units:
  ++++----------- Header byte 9 D3..D0
  |||| ++++-++++- Header byte 4
D~BA98 7654 3210
  --------------
  BBBB BBBB BBBB
  ++++-++++-++++- PRG-ROM size in 16 KiB units,
                  values $000-$EFF for 0..62,898,176 bytes
If the MSB nibble is $F, an exponent-multiplier notation is used:
  ++++----------- Header byte 9 D3..D0
  |||| ++++-++++- Header byte 4
D~BA98 7654 3210
  --------------
  1111 EEEE EEMM
        |||| ||++- Multiplier, actual value is MM*2+1 (1,3,5,7)
        ++++-++--- Exponent (2^E), 0-63
The actual PRG-ROM size is 2^E *(MM*2+1) bytes.
The exponent-multiplier form may only be used if the PRG-ROM size cannot be specified correctly using the simpler notation. If the PRG-ROM data has an odd size that cannot
be represented in either notation, the data must be padded to a size that can be represented.


This is the tentative addition to the standard .NES file format that
In Vs. Dual System ROM images, the first half block of the specified PRG-ROM size belongs to the first unit, and the second half block of PRG-ROM belongs to the the second unit.
most emulators use. This addition is designed to disambiguate certain
24 KiB (half-)blocks are mapped to $A000-$FFFF both in Vs. Unisystem and Vs. Dual System.
ROMs that currently can only be discerned via a CRC-32 or similar hash
An exception is granted for two oddly-sized Vs. System ROM images with a total of 40 KiB PRG-ROM, which are defined to represent 32 KiB +8 KiB instead:
check. Naturally, this causes problems for new ROMs that are not in the
* ''Vs. Gumshoe'', [[#Vs. System Type|Vs. Hardware type]] #0:
database, but need special handling.
** First 32 KiB represent the entire CPU $8000-$FFFF area, including the CPU $8000-$9FFF area with $4016 D2=0;
** Second 8 KiB represent the CPU $8000-$9FFF area with $4016 D2=1.
* ''Vs. Raid on Bungeling Bay'', [[#Vs. System Type|Vs. Hardware type]] #6:
** First 32 KiB represent the first unit's PRG-ROM at CPU $8000-$FFFF;
** Second 8 KiB represent the second unit's PRG-ROM at CPU $E000-$FFFF.
** The second unit only executes a dummy program that does nothing except set a flag in the shared WRAM at $6000-$67FF.


There are four goals for this specification.
==CHR-ROM Area==
The CHR-ROM Area, if present, follows the Trainer and PRG-ROM Areas and precedes the Miscellaneous ROM Area. Header byte 5 (LSB) and bits 4-7 of Header byte 9 (MSB)
specify its size. If the MSB nibble is $0-E, LSB and MSB together simply specify the CHR-ROM size in 8 KiB units:
  ++++----------- Header byte 9 D7..D4
  |||| ++++-++++- Header byte 5
D~BA98 7654 3210
  --------------
  BBBB BBBB BBBB
  ++++-++++-++++- CHR-ROM size in 8 KiB units,
                  values $000-$EFF for 0..31,449,088 bytes
If the MSB nibble is $F, an exponent-multiplier notation is used:
  ++++----------- Header byte 9 D7..D4
  |||| ++++-++++- Header byte 5
D~BA98 7654 3210
  --------------
  1111 EEEE EEMM
        |||| ||++- Multiplier, actual value is MM*2+1 (1,3,5,7)
        ++++-++--- Exponent (2^E), 0-63
The actual CHR-ROM size therefore becomes 2^E * (MM*2+1).
The exponent-multiplier form may only be used if the CHR-ROM size cannot be specified correctly using the simpler notation. If the CHR-ROM data has an odd size that cannot
be represented by either notation, the data must be padded to a size that can be represented.


1) Retain 100% backwards compatibility with existing emulators/ROMs/etc.
For Vs. Dual System ROM images, if the CHR-ROM size is 32 KiB, the first 16 KiB belong to the first unit, and the second 16 KiB of CHR-ROM belong to the second unit.
  (*this includes "dirty ROMs" with crap such as "DiskDude!" in the header
If the CHR-ROM size is 16 KiB, the both units use the same bank-switched 16 KiB CHR-ROM data.
  and other atrocities*)


2) The format must be "future proof".
==Miscellaneous ROM Area==
The Miscellaneous ROM Area, if present, follows the CHR-ROM area and occupies the remainder of the file. Its size is not explicitly denoted in the header, and can be deduced
by subtracting the 16-byte Header, Trainer, PRG-ROM and CHR-ROM Area sizes from the total file size. The meaning of this data depends on the console type and mapper type; Header
byte 14 is used to denote the presence of the Miscellaneous ROM Area and the number of ROM chips in case any disambiguation is needed. Currently, miscellaneous ROMs are defined
for the following situations:
* on console type [[PC10 ROM-Images|Playchoice 10]], an 8 KiB INST ROM, 16 bytes of PROM Data, 16 bytes of PROM Counter Out data, for a total of "3" miscellaneous ROMs;
* on console type [[VT369]], 4 KiB of ROM that is embedded into the NES-on-a-chip itself;
* on [[INES Mapper 086]] submapper 1, a single miscellaneous ROM containing speech data;
* on [[NES 2.0 Mapper 355]], the embedded ROM of the PIC16C54 microcontroller that the games use for protection purposes.
* on [[NES 2.0 Mapper 561]] and [[NES 2.0 Mapper 562]] to deliver trainers that do not match the iNES trainer conventions in size (512 byte) or location ($7000).


3) The changes made must be VERY CAREFULLY documented and make sense.
=Notes=
==Backwards Compatibility to iNES==
* Bytes 0-7 have the same meaning as in [[iNES]], so that NES-2.0-headered games will still run in emulators that do not support NES 2.0 unless the header specifies features that those older emulators did not support anyway.
* The NES 2.0 identifier (Byte 7 D3..D2) has been chosen so that it does not collide with any valid iNES header nor with any known ROM image that has garbage in bytes 7-15 such as "DiskDude!".
==Nametable layout==
Byte 6 (Flags 6) contains two bits to describe the [[Mirroring#Nametable Mirroring|nametable layout]] of the cartridge.


4) Said changes must make sense from both a hardware and software
  D~7654 3210
  standpoint.
    ---------
    .... F..M
        |  +-- Horizontal/vertical hard-wired mirroring.
        +----- All other nametable layout variations


* * *
* Bit 0 is normally relevant only if the mapper does not allow the mirroring type to be switched. It should be set to zero otherwise.
* For some mappers, bit 3 means that 4 KiB of RAM are present at PPU $2000-2FFF, exclusive to that region, and cannot be banked, replaced, or rearranged. This applies to:
** [[INES Mapper 004|Mapper 4]] (MMC3)
** [[INES Mapper 206|Mapper 206]] (DxROM, etc. MMC3-like subset)
** [[NES 2.0 Mapper 262|Mapper 262]] (Street Heroes)
* Several mappers use bit 3 to mean something different:
** [[INES Mapper 030#Nametable Configuration|Mapper 30]] (UNROM 512) - This board can be wired for H/V fixed, 1-screen, or 4-screen.
** [[INES Mapper 218|Mapper 218]] (Magic Floor) - This experimental board has 4 configurations that allow the internal 2k CIRAM to be used for both CHR and nametables at once.


The standard iNES specification is presented below:
==PRG-(NV)RAM/EEPROM==
The PRG-(NV)RAM/EEPROM fields specify the sizes of...
* Memory that is mapped into CPU address space, regardless of whether that memory is internal to a mapper chip or in a separate RAM chip;
* EEPROM even if it is not mapped into CPU address space.
They do not specify the sizes of...
* Mapper-chip-internal memory that is not mapped into CPU address space, even if battery-backed, such as the [[Namco 163]]'s wavetable RAM which some games use to store saved game data. The size of such memory is part of the Mapper definition instead. The Battery bit (Header byte 6 bit 1) denotes whether such memory is battery-backed. The [[MMC5]]'s EXRAM is not included in the PRG-RAM size, as it can be mapped by software to CPU, PPU, or no address space at all;
* self-flashable PRG-ROM;
* external storage such as cassette tape or the ASCII Turbo File.
When the upper nibble (PRG-NVRAM/EEPROM) has a non-zero value, the Battery bit (Header byte 6 bit 1) must always be set for compatibility with [[iNES]]. Conversely, if the Battery bit is set, the upper nibble must have a non-zero value, unless the only battery-backed memory is either mapper-chip-internal memory that is not mapped into CPU address space, such as the [[Namco 163]]'s wavetable RAM, or the PRG-ROM is self-flashable.


0-3: string    "NES"<EOF>
==CHR-(NV)RAM==
  4: byte      Number of 16K byte program ROM pages
* In the presence of a NES 2.0 Header, an emulator must not assume that if a ROM image specifies no CHR-ROM, the game will automatically have 8 KiB of CHR-RAM; all CHR-RAM must instead be explicitly specified in Header byte 11.
  5: byte      Number of 8K character ROM pages (0 indicates CHR RAM)
* Memory that is permanently mapped into the nametable address space (PPU $2000-$2FFF) is not included in the CHR-RAM size. Setting the hard-wired four-screen mode bit in Header byte 6 bit 3 therefore does not entail a 4 KiB increase of the CHR-RAM size.
  6: bitfield  flags byte 0
* The [[MMC5]]'s EXRAM is not included in the CHR-RAM size, as it can be mapped by software to CPU, PPU, or no address space at all.
  7: bitfield  flags byte 1
8-15: byte      These bytes are not used, and should be 00h.


Flags byte 0:
==CPU/PPU Timing==
For non-homebrew NES/Famicom games, this field's value is always a function of the region in which a game was released:
Value  Meaning  Regions
0     RP2C02    North America, Japan, South Korea, Taiwan
1      RP2C07    Western Europe, Australia
2      Multiple  Multiple
3      UA6538    Eastern Europe, Russia, Mainland China, India, Africa
Value 2 ("multiple-region") is used either if a game was released with identical ROM content in both NTSC and PAL countries, such as Nintendo's early games, or if the game detects the console's timing and adjusts itself. Emulators should implement this value by either switching to a user-specified "Default Region" or by keeping the previously-set region.


7      0
[[VTxx|V.R. Technology Famiclones]] only come with RP2C02 or UA6538 timing, so games with such a console type can only bear values 0 or 3.
---------
NNNN FTBM


N: Lower 4 bits of the mapper number
==Vs. System Type==
F: Four screen mode. 0 = no, 1 = yes. (When set, the M bit has no effect)
When the console type in Header byte 7 D1..D0 is 1 (Vs. System), the lower nibble of Header byte 13 specifies the Vs. PPU type, and the upper nibble the non-PPU-based protection
T: Trainer. 0 = no trainer present, 1 = 512 byte trainer at 7000-71FFh
type and whether the ROM is for the Vs. Unisystem or the Vs. Dual System.
B: SRAM at 6000-7FFFh battery backed.  0= no, 1 = yes
Vs. PPU types (Header byte 13 D3..D0):
M: Mirroring.  0 = horizontal, 1 = vertical.
$0: RP2C03B
$1: RP2C03G
$2: RP2C04-0001
$3: RP2C04-0002
$4: RP2C04-0003
$5: RP2C04-0004
$6: RC2C03B
$7: RC2C03C
  $8: RC2C05-01 ($2002 AND $?? =$1B)
$9: RC2C05-02 ($2002 AND $3F =$3D)
$A: RC2C05-03 ($2002 AND $1F =$1C)
$B: RC2C05-04 ($2002 AND $1F =$1B)
$C: RC2C05-05 ($2002 AND $1F =unknown)
$D-F: reserved
For copy protection purposes, these PPU types have different [[PPU palettes|palettes]]; the RC2C05 PPUs furthermore swap [[PPU registers]] $2000 and $2001 and return a signature in the lower bits of $2002. If a game uses the DIP switches to select different PPU models, this field represents the correct PPU model when those DIP switches are all set to zero.
Vs. Hardware type (Header byte 13 D7..D4):
  $0: Vs. Unisystem (normal)
$1: Vs. Unisystem (RBI Baseball protection)
$2: Vs. Unisystem (TKO Boxing protection)
$3: Vs. Unisystem (Super Xevious protection)
$4: Vs. Unisystem (Vs. Ice Climber Japan protection)
$5: Vs. Dual System (normal)
$6: Vs. Dual System (Raid on Bungeling Bay protection)
Refer to the [[Vs. System]] entry for more information.
==Extended Console Type==
When the console type in Header byte 7 D1..D0 is 3 (Extended), the lower nibble of Header byte 13 specifies the type of console on which the ROM image is supposed to be run.
$0      [Regular NES/Famicom/Dendy]
$1     [Nintendo Vs. System]
$2      [Playchoice 10]
$3      Regular Famiclone, but with CPU that supports Decimal Mode
$4      Regular NES/Famicom with [[EPSM]] module or plug-through cartridge
$5      [[VT01 STN_Palette|V.R. Technology VT01 with red/cyan STN palette]]
$6      [[VTxx|V.R. Technology VT02]]
$7      [[VTxx|V.R. Technology VT03]]
$8      [[VTxx|V.R. Technology VT09]]
$9      V.R. Technology VT32
  $A      V.R. Technology VT369
$B      UMC UM6578
$C      [[Famicom Network System]]
$D-$F  reserved
Values $0-$2 are not used for the extended console type, as they can be expressed by only using Header byte 7 D1..D0. They are reserved here so that emulators
can fold the information in Header Byte 7 D1..D0 and Header byte 13 into one "console type" variable without recoding the values.


Flags byte 1:
==Default Expansion Device==
Header byte 15 indicates that the ROM expects a specific set of devices accessible at CPU $4016/$4017. For an emulator that wishes to automatically provide selection of needed peripherals, this gives the required information directly within the header.


7      0
Value $00 is reserved for compatibility with older versions of this specification and indicates no information on the default input device.
---------
NNNN xxPV


N: Upper 4 bits of the mapper number
In almost all cases, this byte will specify ''the'' device without which the game cannot be played at all, such as the NES Zapper or Power Pad. If a game supports an ''optional'' expansion port device, and having that device connected does not preclude using the normal controllers with that game, this byte will specify that device, such as the ASCII Turbo File or the Arkanoid Vaus Controller. For games that support multiple combinations of expansion devices, this byte will denote the game's default selection.
P: Playchoice 10. When set, this is a PC-10 game
V: Vs. Unisystem.  When set, this is a Vs. game
x: these bits are not used.


* * *
This byte does not denote devices that connect to a cartridge; such devices are part of the respective Mapper's definition.
$00    Unspecified
$01    [[Standard controller|Standard NES/Famicom controllers]]
$02    NES [[Four Score]]/Satellite with two additional standard controllers
$03    Famicom Four Players Adapter with two additional standard controllers using the [[Four player adapters#"Simple" Famicom adapters|"simple"]] protocol
$04    [[Vs. System]] (1P via $4016)
$05    Vs. System (1P via $4017)
$06    Reserved
$07    Vs. [[Zapper]]
$08    [[Zapper]] ($4017)
$09    Two Zappers
$0A    Bandai Hyper Shot Lightgun
$0B    [[Power Pad]] Side A
$0C    [[Power Pad]] Side B
$0D    [[Power Pad#Family Trainer Mat|Family Trainer]] Side A
$0E    [[Power Pad#Family Trainer Mat|Family Trainer]] Side B
$0F    [[Arkanoid controller|Arkanoid Vaus Controller (NES)]]
$10    [[Arkanoid controller|Arkanoid Vaus Controller (Famicom)]]
$11    Two Vaus Controllers plus [[Family BASIC Data Recorder|Famicom Data Recorder]]
$12    [[Konami Hyper Shot]] Controller
$13    [[Coconuts Pachinko]] Controller
$14    [[Exciting Boxing Punching Bag]] (Blowup Doll)
$15    [[Jissen Mahjong controller|Jissen Mahjong Controller]]
$16    [[Partytap|Party Tap]]
$17    [[Oeka Kids tablet|Oeka Kids Tablet]]
$18    Sunsoft Barcode Battler
$19    [[Miracle_Piano|Miracle Piano Keyboard]]
$1A    Pokkun Moguraa (Whack-a-Mole Mat and Mallet)
$1B    Top Rider (Inflatable Bicycle)
$1C    Double-Fisted (Requires or allows use of two controllers by one player)
$1D    [[Famicom 3D glasses|Famicom 3D System]]
$1E    Doremikko Keyboard
$1F    R.O.B. Gyro Set
$20    [[Family BASIC Data Recorder|Famicom Data Recorder]] ("silent" keyboard)
$21    ASCII Turbo File
$22    IGS Storage Battle Box
$23    [[Family BASIC Keyboard]] plus Famicom Data Recorder
$24    Dongda PEC-586 Keyboard
$25    Bit Corp. Bit-79 Keyboard
$26    Subor Keyboard
$27    Subor Keyboard plus [[Mouse#Subor Mouse|mouse]] (3x8-bit protocol)
$28    Subor Keyboard plus mouse (24-bit protocol via $4016)
$29    [[Super NES Mouse|SNES Mouse]] ($4017.d0)
$2A    Multicart
$2B    Two [[SNES_controller|SNES controllers]] replacing the two standard NES controllers
$2C    RacerMate Bicycle
$2D    U-Force
$2E    R.O.B. Stack-Up
$2F    City Patrolman Lightgun
$30    Sharp C1 Cassette Interface
$31    Standard Controller with swapped Left-Right/Up-Down/B-A
$32    Excalibur Sudoku Pad
$33    ABL Pinball
$34    Golden Nugget Casino extra buttons
$35    Unknown famiclone keyboard used by the "Golden Key" educational cartridge
$36    Subor Keyboard plus mouse (24-bit protocol via $4017)
$37    [[Port test controller]]
$38    Bandai Multi Game Player Gamepad buttons
$39    Venom TV Dance Mat
$3A    LG TV Remote Control
$3B    [[Famicom Network Controller]]
$3C    King Fishing Controller
$3D    Croaky Karaoke Controller
Notes:
* The Famicom Four Players Adapter ($03) is denoted only if the additional controllers provide ''independent'' 3P/4P input, not if they just alias the built-in 1P/2P controllers.
* So far, there have been no games that provide independent 3P/4P input solely through the [[Four player adapters#Hori 4 Players Adapter|"Hori"]] protocol, which is why there has been no value assigned for it yet.
* For Vs. System games that do not care which stick is used and therefore could be denoted either with value $04 or $05, use value $04.
* Value $06 originally denoted "Pinball (Japan)" and was thought to represent a unique wiring variant, but was since found to represent a peculiar MAME behavior that MAME has since removed.
* "Two Vaus Controllers plus Famicom Data Recorder" ($11) can be trivially emulated as just connecting a Famicom Vaus controller, or sophisticatedly emulated as "Connect two daisy-chained Vaus controllers on startup, disconnect them and connect Family BASIC keyboard with Data Recorder when the user selects Tape Playback or Tape Record from the emulator's user interface; detach these and re-connect the two Vaus controllers when the user selects Tape Stop".
* "Double-Fisted" ($1C) assumes a Four Score is connected, which allows two players to use two controllers at once (Smash T.V.) if the game supports two players.
* The difference between "Famicom Data Recorder" ($20) and "Family BASIC Keyboard" ($23) is that although $20 emulates the Family BASIC keyboard's response to strobe, no actual emulated keyboard input is registered ("silent" keyboard), allowing desktop emulators to keep allowing the use of the host's keyboard for other purposes (such as D-Pad input), and not necessitating the display of an on-screen keyboard on mobile emulators.
* "Multicart" ($2A) is only used if any game on that multicart actually uses expansion port devices. As these will be mostly Zapper games, emulating an expansion port Zapper together with two standard controllers is the simplest way of implementing this value.
* The [[PowerPak]] official loader considers any .NES with a non-zero byte 15 to be invalid, and will fail to load the ROM. A [https://forums.nesdev.org/viewtopic.php?p=283943#p283943 patched N.MAP loader] is available.


For NES 2.0, none of the above will be changing, except for the two unused
==Version History==
bits on flags byte 1.
* 2006-09-18 - Original version of specification by kevtris.
** [https://forums.nesdev.org/viewtopic.php?p=17727#p17727 NES 2.0 "Official" Specification]
* 2019-01-02 - Additions by NewRisingSun.
** [https://forums.nesdev.org/viewtopic.php?f=3&t=17213&start=45#p220624 Additions proposal by NewRisingSun]
** Flags 7: adds [[#Extended Console Type|Extended Console Type]] value
** Flags 12: adds [[#CPU/PPU Timing|Dendy]] value
** Flags 13: adds [[#Extended Console Type|Extended Console Type]] field
** Flags 14: adds [[#Miscellaneous ROM Area|miscellaneous ROM]] specifier
** Flags 15: adds [[#Default Expansion Device|Default Expansion Device]]


To indicate that this is a NES 2.0 file, bit 2 will be clear, and bit 3 will
==See Also==
be set.  i.e.
* [[NES 2.0 submappers]] - disambiguation for mappers that were under-specified in iNES 1
* [[NES 2.0 header for ca65]] - macro header generator for ca65 assembly
* [[NES 2.0 header for cc65]] - macro header generator for cc65 C code


7      0
==References==
---------
* [https://forums.nesdev.org/viewtopic.php?p=17727#p17727 Original proposal by kevtris]
NNNN 10PV
* [https://forums.nesdev.org/viewtopic.php?f=3&t=17213&start=45#p220624 Additions proposal by NewRisingSun]
 
* [https://forums.nesdev.org/viewtopic.php?t=19940 NES 2.0 XML Database, with link to Python script for applying it to a ROM files collection]
Same as above, but the 1 and 0 pattern will denote an NES 2.0 file.  This
<references/>
neatly gets around the "diskdude!!!" problem, because those headers do not
[[Category:File formats]]
have the correct bits set on this byte, and will thus be treated as a
regular iNES file.
 
That is the "how" of determining whether we are dealing with a valid NES 2.0
file.  Now that that is done, the desired aspects of such a thing need to
be considered.  I have tested over 4000 ROMs and have dumped at least a
thousand more, and reverse engineered probably 60-70 different mappers.
This has given me a front row seat into the shortcomings of the original,
and a good idea of where additional information is needed.
 
* * *
 
The new things we need to know are thusly:
 
1) Vs. Unisystem
 
The Vs. Unisystem is one of the two Nintendo arcade machine series produced
which use "mostly NES/famicom" hardware.  These games will run fine on
emulators if a little extra things are stored in the header.
 
Nintendo wanted to make life difficult for arcade operators when it came to
copy protection.  Three main schemes were devised. (See the "Vs. system byte"
description below for a detailed analysis)
 
2) PRG ROM in excess of 2Mbytes, CHR ROM in excess of 1Mbyte
 
This has already occured, and has been causing trouble for some ROMs. So
far, the hack has been to set PRG ROM to 00h to indicate 4Mbytes of ROM
(since FFh is 16K short of 4Mbytes), and in the case of exceeding the
2Mbyte-8K CHR barrier, ROMs have been allocating the CHR in the PRG space,
and the emulator has to sort this out. Very messy.
 
3) "Sub-mappers"
 
Some of the allocated mappers are actually multiple mappers with 1 number.
Examples include mapper 34 (Nina/BNROM), mapper 83 (two styles of CHR ROM
banking), mapper 1 (various ROM/RAM hacks), mapper 16 (EEPROM/WRAM/light pen/
etc).
 
Currently, the only fix for this is to CRC the games and then hack the mapper
if the CRC or other hash matches.  This of course fails if the game is not
in the database.
 
4) Mapper numbers
 
Face it, we're running out of mapper numbers.  16 seemed like it would be
enough, but they were quickly exhausted. Then 256 mappers seemed like a
vast space to work on.  But now, we are getting near the end of the line,
and running out of mapper numbers. I have personally assigned at least 50
or 60 of them, which is almost 1/4th of the total mapper space.
 
5) WRAM
 
Not all carts that support WRAM support 8K of it. Some support less,
some support more, and some even have EEPROM!  Heck, some carts even
battery backed the stupid CHR RAM.  This last one was a very recent
find and goes to show that a workable extention needs to reasonably
cover all possible bases.
 
* * *
 
The proposed solution:
 
Byte 8:
 
7      0
---------
SSSS xxxM
 
S: Sub-mapper number.
 
This specifies the submapper for this ROM. If no submapper mode is
needed, set this nybble to 0000b.
 
M: Mapper number extension.
 
CAUTION: DO NOT USE THIS BIT YET.  There are still some existing
numbers left in the current iNES mapper space. (Around 30-40 or so by
my last count).  The other three bits marked with "x" are also slated
to be used if more than 512 mappers are required.  This would allow
support for 4096 mappers all together.  This should hold us until the
next iceage.  I repeat: do not designate mappers above 256 yet.
 
--
 
Byte 9:
 
7      0
---------
CCCC PPPP
 
C: 4 more CHR ROM size bits
P: 4 more PRG ROM size bits
 
These combine with the existing 8 bits of each to form 12 bits total
for the number of PRG and CHR banks... this is enough for 64Mbytes-16K
of PRG data and 32Mbytes-8K of CHR data.
 
--
 
For the following two bytes, this table defines the size of the RAM
segments:
 
Each Nybble:
------------
0 - no RAM of this type is present.
1 - 128 bytes of RAM
2 - 256 bytes of RAM
3 - 512 bytes of RAM
4 - 1K of RAM
5 - 2K of RAM
6 - 4K of RAM
7 - 8K of RAM
8 - 16K of RAM
9 - 32K of RAM
10 - 64K of RAM
11 - 128K of RAM
12 - 256K of RAM
13 - 512K of RAM
14 - 1M of RAM
15 - reserved, do not use
 
 
Byte 10:
7      0
---------
pppp PPPP
 
p: Quantity of PRG RAM which is battery backed (or serial EEPROM, see below)
P: Quantity of PRG RAM which is NOT battery backed
 
--
 
Byte 11:
7      0
---------
cccc CCCC
 
c: Quantity of CHR RAM which is battery backed (yes it exists! see below)
C: Quantity of CHR RAM which is NOT battery backed
 
--
 
A note about serial EEPROMs and battery backed CHR RAM...
Some mapper 16 (Bandai) games use serial EEPROMs to store the game data,
rather than a battery backed SRAM.  These can be as small as 128 bytes or
as large as 512 bytes.  They tended to use 24C01 (128 bytes) 24C02 (256
bytes) or another semicustom chip I cannot find a workalike for.  The
interface for the 24Cxx parts is I^2E which is a Philips specification.
The workalike chip is very similar, but the address and data are clocked
in backwards from the I^2C parts.
 
As for battery backed CHR RAM, the Racermate cartridge has 64K of CHR RAM
total:  32K is battery backed, and 32K of it is not.  They store all the
stats and such in it.  Why you would do such a thing, I do not have a
clue... but they did!  I traced out the circuit myself and couldn't
believe it.
 
--
 
Byte 12:
7      0
---------
xxxx xxBP
 
P: This is a PAL ROM.  When set, indicates PAL mode.
B: When set, indicates this ROM works on both PAL and NTSC machines.
Some of the Codemasters games actually will adjust the game depending
on if it detects you running on a PAL or NTSC machine - it adjusts the
timing of the game, and fixes the music.
 
Not many games would have this B flag set.
 
x: These bits are not used yet.  They shall be maintained clear.
 
 
byte 13:
7      0
---------
MMMM PPPP
 
This byte is reserved for the Vs. Unisystem only.  If this is not a Vs.
Unisystem ROM, then this byte shall be all 0's.
 
P: PPU.  There are 13 Vs. PPUs that can be found on the games:
 
0 - RP2C03B    (bog standard RGB palette)
1 - RP2C03G    (similar pallete to above, might have 1 changed colour)
2 - PR2C04-0001 (scrambled palette + new colours)
3 - RP2C04-0002 (same as above, different scrambling, diff new colours)
4 - RP2C04-0003 (similar to above)
5 - RP2C04-0004 (similar to above)
6 - RC2C03B    (bog standard palette, seems identical to RP2C03B)
7 - RC2C03C    (similar to above, but with 1 changed colour or so)
8 - RC2C05-01  (all five of these have the normal palette...
9 - RC2C05-02  (...but with different bits returned on 2002)
10 - RC2C05-03
11 - RC2C05-04
12 - RC2C05-05
13 - not defined (do not use these)
14 - not defined
15 - not defined
 
 
I have dumped the palettes from ALL of these PPUs, and have exact bit for
bit copies of them.  The last 5 PPUs (RC2C05) have the standard NES
palette in them, however they return a specific word in the lower 5 bits
of 2002h, and registers 2000h and 2001h are flipped around.  I'm fairly
certain that these are all the PPU's that exist.  I have a good cross
section of games now.
 
 
M: Vs. mode:
 
0 - Normal- no special mode(s)
1 - RBI Baseball
2 - TKO Boxing
3 - Super Xevious
4 - ...
 
 
This section is a tad bare right now... I'm still trying to figure out
exactly how to flesh this out.  This should be a good start, however.
 
If anyone is interested in the things nintendo did to make your life
difficult as an arcade operator, here it is:
 
a) Different PPUs.  There are 13 different PPU chips made that you
    can find on Vs. arcade boards.
 
b) Different controller pinouts.  Some games came with new control panels
    you had to install with the game.  This was pretty basic stuff and just
    remapped a few of the buttons.
 
c) Atari/Namco/Tengen came up with at least three different protection chips
    which map in the 5000-5FFFh area that the game checks. If the chip
    does not return the correct data, the game hangs or fails to start.
</pre>

Latest revision as of 08:31, 23 March 2024

NES 2.0 extends the iNES single file cart format to better describe NES/Famicom-compatible cartridge hardware. Some of its purpose include:

  • Removing the need to use ROM checksums, or other information outside the header, to disambiguate emulation behavior not encoded by iNES.
  • Making room for new mapper allocation.
  • Allowing for larger ROM sizes.
  • Supporting other than standard NES/Famicom console types such as the Nintendo Vs. System and enhanced Famiclones.
  • Providing additional information such as the region-specific CPU/PPU type and default expansion port devices.
  • Replaces the deprecated UNIF format.

The format is backwards-compatible to iNES, so that ROM images with a NES 2.0 header run in non-NES-2.0-compliant emulators as long as they do not require NES-2.0-exclusive features.

Identification

A file is a NES 2.0 ROM image file if it begins with "NES<EOF>" (same as iNES) and, additionally, the byte at offset 7 has bit 2 clear and bit 3 set:

bool iNESFormat=false;
if (header[0]=='N' && header[1]=='E' && header[2]=='S' && header[3]==0x1A)
        iNESFormat=true;

bool NES20Format=false;
if (iNESFormat==true && (header[7]&0x0C)==0x08)
        NES20Format=true;

File Structure

A NES 2.0 file contains a sixteen-byte header, followed by Trainer, PRG-ROM, CHR-ROM and Miscellaneous ROM data.

Header

Offset Meaning
--------------
0-3    Identification String. Must be "NES<EOF>".

4      PRG-ROM size LSB
5      CHR-ROM size LSB

6      Flags 6
       D~7654 3210
         ---------
         NNNN FTBM
         |||| |||+-- Hard-wired nametable layout
         |||| |||     0: Vertical arrangement ("mirrored horizontally") or mapper-controlled
         |||| |||     1: Horizontal arrangement ("mirrored vertically")
         |||| ||+--- "Battery" and other non-volatile memory
         |||| ||      0: Not present
         |||| ||      1: Present
         |||| |+--- 512-byte Trainer
         |||| |      0: Not present
         |||| |      1: Present between Header and PRG-ROM data
         |||| +---- Alternative nametables
         ||||        0: No
         ||||        1: Yes
         ++++------ Mapper Number D3..D0

7      Flags 7
       D~7654 3210
         ---------
         NNNN 10TT
         |||| ||++- Console type
         |||| ||     0: Nintendo Entertainment System/Family Computer
         |||| ||     1: Nintendo Vs. System
         |||| ||     2: Nintendo Playchoice 10
         |||| ||     3: Extended Console Type
         |||| ++--- NES 2.0 identifier
         ++++------ Mapper Number D7..D4

8      Mapper MSB/Submapper
       D~7654 3210
         ---------
         SSSS NNNN
         |||| ++++- Mapper number D11..D8
         ++++------ Submapper number

9      PRG-ROM/CHR-ROM size MSB
       D~7654 3210
         ---------
         CCCC PPPP
         |||| ++++- PRG-ROM size MSB
         ++++------ CHR-ROM size MSB

10     PRG-RAM/EEPROM size
       D~7654 3210
         ---------
         pppp PPPP
         |||| ++++- PRG-RAM (volatile) shift count
         ++++------ PRG-NVRAM/EEPROM (non-volatile) shift count
       If the shift count is zero, there is no PRG-(NV)RAM.
       If the shift count is non-zero, the actual size is
       "64 << shift count" bytes, i.e. 8192 bytes for a shift count of 7.

11     CHR-RAM size
       D~7654 3210
         ---------
         cccc CCCC
         |||| ++++- CHR-RAM size (volatile) shift count
         ++++------ CHR-NVRAM size (non-volatile) shift count
       If the shift count is zero, there is no CHR-(NV)RAM.
       If the shift count is non-zero, the actual size is
       "64 << shift count" bytes, i.e. 8192 bytes for a shift count of 7.

12     CPU/PPU Timing
       D~7654 3210
         ---------
         .... ..VV
                ++- CPU/PPU timing mode
                     0: RP2C02 ("NTSC NES")
                     1: RP2C07 ("Licensed PAL NES")
                     2: Multiple-region
                     3: UA6538 ("Dendy")

13     When Byte 7 AND 3 =1: Vs. System Type
       D~7654 3210
         ---------
         MMMM PPPP
         |||| ++++- Vs. PPU Type
         ++++------ Vs. Hardware Type

       When Byte 7 AND 3 =3: Extended Console Type
       D~7654 3210
         ---------
         .... CCCC
              ++++- Extended Console Type

14     Miscellaneous ROMs
       D~7654 3210
         ---------
         .... ..RR
                ++- Number of miscellaneous ROMs present

15     Default Expansion Device
       D~7654 3210
         ---------
         ..DD DDDD
           ++-++++- Default Expansion Device

Trainer Area

The Trainer Area follows the 16-byte Header and precedes the PRG-ROM area if bit 2 of Header byte 6 is set. It is always 512 bytes in size if present, and contains data to be loaded into CPU memory at $7000. It is only used by some games that were modified to run on different hardware from the original cartridges, such as early RAM cartridges and emulators, and which put some additional compatibility code into those address ranges.

PRG-ROM Area

The PRG-ROM Area follows the 16-byte Header and the Trainer Area and precedes the CHR-ROM Area. Header byte 4 (LSB) and bits 0-3 of Header byte 9 (MSB) together specify its size. If the MSB nibble is $0-E, LSB and MSB together simply specify the PRG-ROM size in 16 KiB units:

  ++++----------- Header byte 9 D3..D0
  |||| ++++-++++- Header byte 4
D~BA98 7654 3210
  --------------
  BBBB BBBB BBBB
  ++++-++++-++++- PRG-ROM size in 16 KiB units,
                  values $000-$EFF for 0..62,898,176 bytes

If the MSB nibble is $F, an exponent-multiplier notation is used:

  ++++----------- Header byte 9 D3..D0
  |||| ++++-++++- Header byte 4
D~BA98 7654 3210
  --------------
  1111 EEEE EEMM
       |||| ||++- Multiplier, actual value is MM*2+1 (1,3,5,7)
       ++++-++--- Exponent (2^E), 0-63

The actual PRG-ROM size is 2^E *(MM*2+1) bytes.

The exponent-multiplier form may only be used if the PRG-ROM size cannot be specified correctly using the simpler notation. If the PRG-ROM data has an odd size that cannot be represented in either notation, the data must be padded to a size that can be represented.

In Vs. Dual System ROM images, the first half block of the specified PRG-ROM size belongs to the first unit, and the second half block of PRG-ROM belongs to the the second unit. 24 KiB (half-)blocks are mapped to $A000-$FFFF both in Vs. Unisystem and Vs. Dual System. An exception is granted for two oddly-sized Vs. System ROM images with a total of 40 KiB PRG-ROM, which are defined to represent 32 KiB +8 KiB instead:

  • Vs. Gumshoe, Vs. Hardware type #0:
    • First 32 KiB represent the entire CPU $8000-$FFFF area, including the CPU $8000-$9FFF area with $4016 D2=0;
    • Second 8 KiB represent the CPU $8000-$9FFF area with $4016 D2=1.
  • Vs. Raid on Bungeling Bay, Vs. Hardware type #6:
    • First 32 KiB represent the first unit's PRG-ROM at CPU $8000-$FFFF;
    • Second 8 KiB represent the second unit's PRG-ROM at CPU $E000-$FFFF.
    • The second unit only executes a dummy program that does nothing except set a flag in the shared WRAM at $6000-$67FF.

CHR-ROM Area

The CHR-ROM Area, if present, follows the Trainer and PRG-ROM Areas and precedes the Miscellaneous ROM Area. Header byte 5 (LSB) and bits 4-7 of Header byte 9 (MSB) specify its size. If the MSB nibble is $0-E, LSB and MSB together simply specify the CHR-ROM size in 8 KiB units:

  ++++----------- Header byte 9 D7..D4
  |||| ++++-++++- Header byte 5
D~BA98 7654 3210
  --------------
  BBBB BBBB BBBB
  ++++-++++-++++- CHR-ROM size in 8 KiB units,
                  values $000-$EFF for 0..31,449,088 bytes

If the MSB nibble is $F, an exponent-multiplier notation is used:

  ++++----------- Header byte 9 D7..D4
  |||| ++++-++++- Header byte 5
D~BA98 7654 3210
  --------------
  1111 EEEE EEMM
       |||| ||++- Multiplier, actual value is MM*2+1 (1,3,5,7)
       ++++-++--- Exponent (2^E), 0-63

The actual CHR-ROM size therefore becomes 2^E * (MM*2+1).

The exponent-multiplier form may only be used if the CHR-ROM size cannot be specified correctly using the simpler notation. If the CHR-ROM data has an odd size that cannot be represented by either notation, the data must be padded to a size that can be represented.

For Vs. Dual System ROM images, if the CHR-ROM size is 32 KiB, the first 16 KiB belong to the first unit, and the second 16 KiB of CHR-ROM belong to the second unit. If the CHR-ROM size is 16 KiB, the both units use the same bank-switched 16 KiB CHR-ROM data.

Miscellaneous ROM Area

The Miscellaneous ROM Area, if present, follows the CHR-ROM area and occupies the remainder of the file. Its size is not explicitly denoted in the header, and can be deduced by subtracting the 16-byte Header, Trainer, PRG-ROM and CHR-ROM Area sizes from the total file size. The meaning of this data depends on the console type and mapper type; Header byte 14 is used to denote the presence of the Miscellaneous ROM Area and the number of ROM chips in case any disambiguation is needed. Currently, miscellaneous ROMs are defined for the following situations:

  • on console type Playchoice 10, an 8 KiB INST ROM, 16 bytes of PROM Data, 16 bytes of PROM Counter Out data, for a total of "3" miscellaneous ROMs;
  • on console type VT369, 4 KiB of ROM that is embedded into the NES-on-a-chip itself;
  • on INES Mapper 086 submapper 1, a single miscellaneous ROM containing speech data;
  • on NES 2.0 Mapper 355, the embedded ROM of the PIC16C54 microcontroller that the games use for protection purposes.
  • on NES 2.0 Mapper 561 and NES 2.0 Mapper 562 to deliver trainers that do not match the iNES trainer conventions in size (512 byte) or location ($7000).

Notes

Backwards Compatibility to iNES

  • Bytes 0-7 have the same meaning as in iNES, so that NES-2.0-headered games will still run in emulators that do not support NES 2.0 unless the header specifies features that those older emulators did not support anyway.
  • The NES 2.0 identifier (Byte 7 D3..D2) has been chosen so that it does not collide with any valid iNES header nor with any known ROM image that has garbage in bytes 7-15 such as "DiskDude!".

Nametable layout

Byte 6 (Flags 6) contains two bits to describe the nametable layout of the cartridge.

 D~7654 3210
   ---------
   .... F..M
        |  +-- Horizontal/vertical hard-wired mirroring.
        +----- All other nametable layout variations
  • Bit 0 is normally relevant only if the mapper does not allow the mirroring type to be switched. It should be set to zero otherwise.
  • For some mappers, bit 3 means that 4 KiB of RAM are present at PPU $2000-2FFF, exclusive to that region, and cannot be banked, replaced, or rearranged. This applies to:
  • Several mappers use bit 3 to mean something different:
    • Mapper 30 (UNROM 512) - This board can be wired for H/V fixed, 1-screen, or 4-screen.
    • Mapper 218 (Magic Floor) - This experimental board has 4 configurations that allow the internal 2k CIRAM to be used for both CHR and nametables at once.

PRG-(NV)RAM/EEPROM

The PRG-(NV)RAM/EEPROM fields specify the sizes of...

  • Memory that is mapped into CPU address space, regardless of whether that memory is internal to a mapper chip or in a separate RAM chip;
  • EEPROM even if it is not mapped into CPU address space.

They do not specify the sizes of...

  • Mapper-chip-internal memory that is not mapped into CPU address space, even if battery-backed, such as the Namco 163's wavetable RAM which some games use to store saved game data. The size of such memory is part of the Mapper definition instead. The Battery bit (Header byte 6 bit 1) denotes whether such memory is battery-backed. The MMC5's EXRAM is not included in the PRG-RAM size, as it can be mapped by software to CPU, PPU, or no address space at all;
  • self-flashable PRG-ROM;
  • external storage such as cassette tape or the ASCII Turbo File.

When the upper nibble (PRG-NVRAM/EEPROM) has a non-zero value, the Battery bit (Header byte 6 bit 1) must always be set for compatibility with iNES. Conversely, if the Battery bit is set, the upper nibble must have a non-zero value, unless the only battery-backed memory is either mapper-chip-internal memory that is not mapped into CPU address space, such as the Namco 163's wavetable RAM, or the PRG-ROM is self-flashable.

CHR-(NV)RAM

  • In the presence of a NES 2.0 Header, an emulator must not assume that if a ROM image specifies no CHR-ROM, the game will automatically have 8 KiB of CHR-RAM; all CHR-RAM must instead be explicitly specified in Header byte 11.
  • Memory that is permanently mapped into the nametable address space (PPU $2000-$2FFF) is not included in the CHR-RAM size. Setting the hard-wired four-screen mode bit in Header byte 6 bit 3 therefore does not entail a 4 KiB increase of the CHR-RAM size.
  • The MMC5's EXRAM is not included in the CHR-RAM size, as it can be mapped by software to CPU, PPU, or no address space at all.

CPU/PPU Timing

For non-homebrew NES/Famicom games, this field's value is always a function of the region in which a game was released:

Value  Meaning   Regions
0      RP2C02    North America, Japan, South Korea, Taiwan
1      RP2C07    Western Europe, Australia
2      Multiple  Multiple
3      UA6538    Eastern Europe, Russia, Mainland China, India, Africa

Value 2 ("multiple-region") is used either if a game was released with identical ROM content in both NTSC and PAL countries, such as Nintendo's early games, or if the game detects the console's timing and adjusts itself. Emulators should implement this value by either switching to a user-specified "Default Region" or by keeping the previously-set region.

V.R. Technology Famiclones only come with RP2C02 or UA6538 timing, so games with such a console type can only bear values 0 or 3.

Vs. System Type

When the console type in Header byte 7 D1..D0 is 1 (Vs. System), the lower nibble of Header byte 13 specifies the Vs. PPU type, and the upper nibble the non-PPU-based protection type and whether the ROM is for the Vs. Unisystem or the Vs. Dual System.

Vs. PPU types (Header byte 13 D3..D0):
$0: RP2C03B
$1: RP2C03G
$2: RP2C04-0001
$3: RP2C04-0002
$4: RP2C04-0003
$5: RP2C04-0004
$6: RC2C03B
$7: RC2C03C
$8: RC2C05-01 ($2002 AND $?? =$1B)
$9: RC2C05-02 ($2002 AND $3F =$3D)
$A: RC2C05-03 ($2002 AND $1F =$1C)
$B: RC2C05-04 ($2002 AND $1F =$1B)
$C: RC2C05-05 ($2002 AND $1F =unknown)
$D-F: reserved

For copy protection purposes, these PPU types have different palettes; the RC2C05 PPUs furthermore swap PPU registers $2000 and $2001 and return a signature in the lower bits of $2002. If a game uses the DIP switches to select different PPU models, this field represents the correct PPU model when those DIP switches are all set to zero.

Vs. Hardware type (Header byte 13 D7..D4):
$0: Vs. Unisystem (normal)
$1: Vs. Unisystem (RBI Baseball protection)
$2: Vs. Unisystem (TKO Boxing protection)
$3: Vs. Unisystem (Super Xevious protection)
$4: Vs. Unisystem (Vs. Ice Climber Japan protection)
$5: Vs. Dual System (normal)
$6: Vs. Dual System (Raid on Bungeling Bay protection)

Refer to the Vs. System entry for more information.

Extended Console Type

When the console type in Header byte 7 D1..D0 is 3 (Extended), the lower nibble of Header byte 13 specifies the type of console on which the ROM image is supposed to be run.

$0      [Regular NES/Famicom/Dendy]
$1      [Nintendo Vs. System]
$2      [Playchoice 10]
$3      Regular Famiclone, but with CPU that supports Decimal Mode
$4      Regular NES/Famicom with EPSM module or plug-through cartridge
$5      V.R. Technology VT01 with red/cyan STN palette
$6      V.R. Technology VT02
$7      V.R. Technology VT03
$8      V.R. Technology VT09
$9      V.R. Technology VT32
$A      V.R. Technology VT369
$B      UMC UM6578
$C      Famicom Network System
$D-$F   reserved

Values $0-$2 are not used for the extended console type, as they can be expressed by only using Header byte 7 D1..D0. They are reserved here so that emulators can fold the information in Header Byte 7 D1..D0 and Header byte 13 into one "console type" variable without recoding the values.

Default Expansion Device

Header byte 15 indicates that the ROM expects a specific set of devices accessible at CPU $4016/$4017. For an emulator that wishes to automatically provide selection of needed peripherals, this gives the required information directly within the header.

Value $00 is reserved for compatibility with older versions of this specification and indicates no information on the default input device.

In almost all cases, this byte will specify the device without which the game cannot be played at all, such as the NES Zapper or Power Pad. If a game supports an optional expansion port device, and having that device connected does not preclude using the normal controllers with that game, this byte will specify that device, such as the ASCII Turbo File or the Arkanoid Vaus Controller. For games that support multiple combinations of expansion devices, this byte will denote the game's default selection.

This byte does not denote devices that connect to a cartridge; such devices are part of the respective Mapper's definition.

$00     Unspecified
$01     Standard NES/Famicom controllers
$02     NES Four Score/Satellite with two additional standard controllers
$03     Famicom Four Players Adapter with two additional standard controllers using the "simple" protocol
$04     Vs. System (1P via $4016)
$05     Vs. System (1P via $4017)
$06     Reserved
$07     Vs. Zapper
$08     Zapper ($4017)
$09     Two Zappers
$0A     Bandai Hyper Shot Lightgun
$0B     Power Pad Side A
$0C     Power Pad Side B
$0D     Family Trainer Side A
$0E     Family Trainer Side B
$0F     Arkanoid Vaus Controller (NES)
$10     Arkanoid Vaus Controller (Famicom)
$11     Two Vaus Controllers plus Famicom Data Recorder
$12     Konami Hyper Shot Controller
$13     Coconuts Pachinko Controller
$14     Exciting Boxing Punching Bag (Blowup Doll)
$15     Jissen Mahjong Controller
$16     Party Tap 
$17     Oeka Kids Tablet
$18     Sunsoft Barcode Battler
$19     Miracle Piano Keyboard
$1A     Pokkun Moguraa (Whack-a-Mole Mat and Mallet)
$1B     Top Rider (Inflatable Bicycle)
$1C     Double-Fisted (Requires or allows use of two controllers by one player)
$1D     Famicom 3D System
$1E     Doremikko Keyboard
$1F     R.O.B. Gyro Set
$20     Famicom Data Recorder ("silent" keyboard)
$21     ASCII Turbo File
$22     IGS Storage Battle Box
$23     Family BASIC Keyboard plus Famicom Data Recorder
$24     Dongda PEC-586 Keyboard
$25     Bit Corp. Bit-79 Keyboard
$26     Subor Keyboard
$27     Subor Keyboard plus mouse (3x8-bit protocol)
$28     Subor Keyboard plus mouse (24-bit protocol via $4016)
$29     SNES Mouse ($4017.d0)
$2A     Multicart
$2B     Two SNES controllers replacing the two standard NES controllers
$2C     RacerMate Bicycle
$2D     U-Force
$2E     R.O.B. Stack-Up
$2F     City Patrolman Lightgun
$30     Sharp C1 Cassette Interface
$31     Standard Controller with swapped Left-Right/Up-Down/B-A
$32     Excalibur Sudoku Pad
$33     ABL Pinball
$34     Golden Nugget Casino extra buttons
$35     Unknown famiclone keyboard used by the "Golden Key" educational cartridge
$36     Subor Keyboard plus mouse (24-bit protocol via $4017)
$37     Port test controller
$38     Bandai Multi Game Player Gamepad buttons
$39     Venom TV Dance Mat
$3A     LG TV Remote Control
$3B     Famicom Network Controller
$3C     King Fishing Controller
$3D     Croaky Karaoke Controller

Notes:

  • The Famicom Four Players Adapter ($03) is denoted only if the additional controllers provide independent 3P/4P input, not if they just alias the built-in 1P/2P controllers.
  • So far, there have been no games that provide independent 3P/4P input solely through the "Hori" protocol, which is why there has been no value assigned for it yet.
  • For Vs. System games that do not care which stick is used and therefore could be denoted either with value $04 or $05, use value $04.
  • Value $06 originally denoted "Pinball (Japan)" and was thought to represent a unique wiring variant, but was since found to represent a peculiar MAME behavior that MAME has since removed.
  • "Two Vaus Controllers plus Famicom Data Recorder" ($11) can be trivially emulated as just connecting a Famicom Vaus controller, or sophisticatedly emulated as "Connect two daisy-chained Vaus controllers on startup, disconnect them and connect Family BASIC keyboard with Data Recorder when the user selects Tape Playback or Tape Record from the emulator's user interface; detach these and re-connect the two Vaus controllers when the user selects Tape Stop".
  • "Double-Fisted" ($1C) assumes a Four Score is connected, which allows two players to use two controllers at once (Smash T.V.) if the game supports two players.
  • The difference between "Famicom Data Recorder" ($20) and "Family BASIC Keyboard" ($23) is that although $20 emulates the Family BASIC keyboard's response to strobe, no actual emulated keyboard input is registered ("silent" keyboard), allowing desktop emulators to keep allowing the use of the host's keyboard for other purposes (such as D-Pad input), and not necessitating the display of an on-screen keyboard on mobile emulators.
  • "Multicart" ($2A) is only used if any game on that multicart actually uses expansion port devices. As these will be mostly Zapper games, emulating an expansion port Zapper together with two standard controllers is the simplest way of implementing this value.
  • The PowerPak official loader considers any .NES with a non-zero byte 15 to be invalid, and will fail to load the ROM. A patched N.MAP loader is available.

Version History

See Also

References