NES 2.0: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
No edit summary
(rewrite and additions)
Line 1: Line 1:
'''NES 2.0''' is an extension to the [[iNES]] ROM format, originally [http://forums.nesdev.org/viewtopic.php?p=17727#p17727 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 for emulation purposes, by ...
* ... resolving emulation-relevant hardware differences that are ambiguous in [[iNES]];
* ... allowing for larger ROM sizes;
* ... supporting other than standard NES/Famicom console types such as the Nintendo Vs. System and enhanced Famiclones;
* ... providing additional emulation-relevant information such as the region-specific CPU/PPU timing and default expansion port devices.
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 use NES-2.0-exclusive features.
It is furthermore intended to replace the deprecated [[UNIF]] format.


It adds extra header information to disambiguate ROMs that incompatibly require the same iNES [[mapper]], or supplemental information for ROMs that are otherwise inadequately described by the original format.
=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.


This extension is backwards compatible with the original format, identified by two bits in [[#Byte 7 (Flags 7)|byte 7]] of the header.
==Header==
Offset Meaning
--------------
$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 #1
        D~7654 3210
          ---------
          NNNN FTBM
          |||| ||+-- Hard-wired nametable [[Mirroring#Nametable Mirroring|mirroring]] type
          |||| ||    0: Horizontal or mapper-controlled
          |||| ||    1: Vertical
          |||| |+--- "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
          |||| +---- Additional memory for four nametables
          ||||        0: Not present
          ||||        1: Present ("four-screen mode")
          ++++------ Mapper Number D0..D3
$7    Flags #2
        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 D4..D7
$8    [[Mapper]] MSB/[[Submapper]]
        D~7654 3210
          ---------
          SSSS NNNN
          |||| ++++- Mapper number D8..D11
          ++++------ 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
$A    [[#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 SHL shift count" bytes, i.e. 8192 bytes for a shift count of 7.
$B    [[#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 SHL shift count" bytes, i.e. 8192 bytes for a shift count of 7.
$C    [[#CPU/PPU Timing|CPU/PPU Timing]]
        D~7654 3210
          ---------
          .... ..VV
                ++- CPU/PPU timing mode
                      0: RP2C02 ("NTSC NES")
                      1: RP2C07 ("Licensed PAL NES")
                      2: Game detects console timing and adjusts itself
                      3: UMC 6527P ("Dendy")
$D    When Byte $07 AND $03 =1: [[#Vs. System Type|Vs. System Type]]
        D~7654 3210
          ---------
          MMMM PPPP
          |||| ++++- Vs. PPU Type
          ++++------ Vs. Hardware Type
        When Byte $07 AND $03 =3: [[#Extended Console Type|Extended Console Type]]
        D~7654 3210
          ---------
          .... CCCC
              ++++- Extended Console Type
$E    [[#Miscellaneous ROM Area|Miscellaneous ROMs]]
        D~7654 3210
          ---------
          .... ..RR
                ++- Number of miscellaneous ROMs present
$F    [[#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 D0..D3
  |||| ++++-++++- 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 D0..D3
  |||| ++++-++++- 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.


== Overview ==
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 blocks 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. System Type|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. 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.
==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 PRG-ROM size in 8 KiB units:
  ++++----------- Header byte 9 D4..D7
  |||| ++++-++++- Header byte 5
D~BA98 7654 3210
  --------------
  BBBB BBBB BBBB
  ++++-++++-++++- PRG-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 D4..D7
  |||| ++++-++++- 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.


NES 2.0 is an addition to the standard .NES file format that most emulators use.
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.
It is designed to disambiguate certain ROMs that formerly could have been only be discerned via a CRC-32 or similar hash check.
If the CHR-ROM size is 16 KiB, the both units use the same bank-switched 16 KiB CHR-ROM data.
Naturally, this caused problems for new ROMs that are not in the database but need special handling, such as fan translations, other ROM hacks, and new homebrew on compatible boards.
==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
only for three 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 [[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.
=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 D2..D3) 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-$F such as "DiskDude!".
==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;
* 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 mapper-chip-internal memory that is not mapped into CPU address space, such as the [[Namco 163]]'s wavetable RAM.
==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 $B.


There are four goals for this specification:
The CHR-RAM size does not include the additional memory for four nametables denoted in Header byte $6 D3.
#Retain 100% backwards compatibility with existing emulators/ROMs/etc. (*this includes "dirty ROMs" with crap such as "DiskDude!" in the header and other atrocities*)
==CPU/PPU Timing==
#The format must be "future proof".
For non-homebrew NES/Famicom games, this field's value is always a function of the region in which a game was released:
#The changes made must be very carefully documented and make sense.
Value  Meaning    Regions
#Said changes must make sense from both a hardware and software standpoint.
0      RP2C02    North America, Japan, South Korea, Taiwan
1      RP2C07    Western Europe, Australia
3      UMC 6527P  Eastern Europe, Russia, Mainland China, India, Africa
Emulators should implement value 2 ("self-adjusting") by either switching to a user-specified "Default Region" or by keeping the previously-set region.


The name of this specification is "NES 2.0".
[[VTxx|V.R. Technology Famiclones]] only come with RP2C02 or UMC 6527P timing, so games with such a console type can only bear values 0 or 3.
Do not confuse with "iNES 2.0" which is an emulator that does not support extended features of NES 2.0 headers.
==Vs. System Type==
When the console type in Header byte 7 D0..D1 is 1 (Vs. System), the lower nibble of Header byte $D 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 $D D0..D3):
$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 $D D4..D7):
$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 D0..D1 is 3 (Extended), the lower nibble of Header byte $D 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 (e.g. Bit Corporation Creator)
$4      V.R. Technology VT01 with monochrome palette
$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-$F  reserved
Values $0-$2 are not used for the extended console type, as they can be expressed by only using Header byte 7 D0..D1. They are reserved here so that emulators
can fold the information in Header Byte $7 D0..D1 and Header byte $D into one "console type" variable without recoding the values.
==Default Expansion Device==
Header byte $F indicates that an emulator should automatically "plug in" an expansion port device that is accessible at CPU $4016/$4017.


== Existing header ==
In almost cases, this byte will specify ''the'' device without which the game cannot be played at all, such as the NES Zapper or Power Pad.
The standard specification as popularized by the iNES emulator is presented below:
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 the
<pre>
(mostly homebrew) games that support different player-selectable expansion devices, this byte will denote the default selection,
0-3: string    "NES"<EOF>
which in most cases will be the standard controllers ($00). In any case, emulator users should always be free to select a different expansion device
  4: byte      Number of 16384 byte program ROM pages
themselves afterwards.
  5: byte      Number of 8192 byte character ROM pages (0 indicates CHR RAM)
  6: bitfield  Flags 6
  7: bitfield  Flags 7
8-15: byte      These bytes are not used, and should be 00h.
</pre>
 
The PRG ROM size is in 16384 byte units, and the CHR ROM size is in 8192 byte units.
If the actual game's data is smaller, such as 8192-byte PRG for Galaxian or 4096-byte CHR for Slappin', double it up and call it a day.
For example, if the PRG ROM data is 16384 bytes long, and the first 8192 bytes of the PRG ROM data match the second 8192 bytes, the PRG ROM is an 8Kx8 chip.
 
=== Byte 6 (Flags 6) ===
<pre>
7      0
---------
NNNN FTBM
 
N: Lower 4 bits of the mapper number
F: Four screen mode. 0 = no, 1 = yes. (When set, the M bit has no effect)
T: Trainer.  0 = no trainer present, 1 = 512 byte trainer at 7000-71FFh
B: SRAM at 6000-7FFFh battery backed.  0= no, 1 = yes
M: Mirroring.  0 = horizontal, 1 = vertical.
</pre>
None of this changes in NES 2.0.
Very few existing ROMs have a trainer, and most of these aren't real trainers at all but subroutines used by a mapper hack.
 
=== Byte 7 (Flags 7) ===
Later versions of the iNES emulator introduced a second byte of flags.
<pre>
7      0
---------
NNNN xxPV
 
N: Upper 4 bits of the mapper number
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 in iNES.
</pre>
Early ROM processing tools were not aware of Flags 7 because the earliest emulators ignored it.
For example, one tool put 0x44 (ASCII for 'D', the first character of "DiskDude!") here.
This confuses newer emulators, which combine the nibbles from Flags 6 and Flags 7 to form an incorrect mapper number.
NES 2.0 redefines the unused bits to always equal binary 10, which happens not to match any of the patterns used by these ROM processing tools:
<pre>
7      0
---------
NNNN SSPV
 
N: Upper 4 bits of the mapper number
S: When equal to binary 10, use NES 2.0 rules; otherwise, use other rules.
P: Playchoice 10.  When set, this is a PC-10 game
V: Vs. Unisystem.  When set, this is a Vs. game
</pre>
 
== The problem cases ==
The new specification needs to clarify five areas:
 
=== 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 "[[#Byte 13 .28Vs. hardware.29|Vs. system byte]]"
description below for a detailed analysis)
 
=== Big ROMs ===
 
PRG ROM has already surpassed 2 MiB, and CHR ROM has already surpassed 1 MiB, especially on pirate multicarts.
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.
This can get very messy for an emulator to sort out, especially by 2015 now that pirates are making monstrosities like the CoolBoy ''400 in 1 Real Game'' multicart<ref>SomeRussianMarioDude's [http://somerussianmariodude.blogspot.ru/2014/02/400-in-1-real-game-famicom-review.html review]</ref> dumped by TeamEurope, which is 32 MB.<ref>CaH4e3's [http://cah4e3.shedevr.org.ru/dumping_2015.php Dumping 2015]</ref>.
 
=== Submappers ===
See: [[NES 2.0 submappers]]
 
Occasionally, two mappers get one number.
Sometimes, an emulator can distinguish them easily: [[iNES Mapper 034|34]] covers both [[NINA-001]] and [[BNROM]], but NINA-001 has CHR ROM, and BNROM has CHR RAM.
But other mappers are messier: [[iNES Mapper 083|mapper 83]] (two styles of CHR ROM banking), [[SxROM|mapper 1]] (various ROM/RAM hacks), [[Bandai FCG board|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, especially newly developed homebrew games.
 
=== Mapper number exhaustion ===
 
Face it: we're running out.
In the early days of iNES, 16 mappers 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.
Mr. Horton alone has assigned at least 50 or 60 of them, which is almost a quarter of the total mapper space.
 
=== WRAM ===
 
Not all carts that support PRG RAM support 8K of it.
Some support less, some support more, and [[Bandai FCG board|some by Bandai]] even have EEPROM!
Heck, some carts even battery backed the stupid CHR RAM.
This last one was a very recent find at the time NES 2.0 was first written and goes to show that a workable extension needs to reasonably cover all possible bases.
 
== The proposed solution ==
 
=== Byte 8 (Mapper variant) ===
<pre>
7      0
---------
SSSS MMMM
 
S: Submapper number.  Mappers not using submappers set this to zero.
M: Bits 11-8 of mapper number.
</pre>
[[NES 2.0 submappers|Submappers]] are used to disambiguate iNES 1 mappers that require multiple incompatible implementations.
Most mappers will not use submappers; they set S to 0.
 
It's not recommended yet as of 2015 to assign mapper numbers greater than 255.
There were still a couple dozen existing numbers left in [[mapper|the current iNES mapper space]] as of 2013.
Mapper numbers up to 511 should hold us until they stop making ''Ice Age'' films;
mapper numbers up to 4095 should hold us until the next ''literal'' ice age.
 
In 2013, there was a [http://forums.nesdev.org/viewtopic.php?f=3&t=9854 proposal on the BBS] to break up the expanded mapper space into "planes", much like those of [[wikipedia:Plane (Unicode)|Unicode when it expanded past UCS-2]].
Each M value would thus correspond to one plane:
* Plane 0 (0-255): Basic Multilingual Plane, the current mess
* [[Mapper#Plane 1|Plane 1]] (256-511): Mostly for new homebrew mappers.
* [[Mapper#Plane 2|Plane 2]] (512-767): For new dumps of East Asian games.
* Plane 15: Private use area (not for publicly distributed dumps)
 
=== Byte 9 (Upper bits of ROM size) ===
<pre>
7      0
---------
CCCC PPPP
 
C: 4 more CHR ROM size bits
P: 4 more PRG ROM size bits
</pre>
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.
 
Only a few mappers, mostly multicart mappers, support non-power-of-two sizes for PRG and CHR.
The behavior of a ROM with a Nintendo MMC and a non-power-of-two ROM size is undefined.
 
=== Byte 10 (RAM size) ===
<pre>
7      0
---------
pppp PPPP
 
p: Quantity of PRG RAM which is battery backed (or EEPROM)
P: Quantity of PRG RAM which is NOT battery backed
</pre>
 
Bytes 10 and 11 of the header define the size of the RAM segments exponentially using 4-bit values:
{| class="tabular"
|-
! value || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! power
| 0 || 2^7 || 2^8 || 2^9 || 2^10 || 2^11 || 2^12 || 2^13 || 2^14 || 2^15 || 2^16 || 2^17 || 2^18 || 2^19 || 2^20 || reserved
|-
! bytes
| 0 || 128 || 256 || 512 || 1024 || 2048 || 4096 || 8192 || 16384 || 32768 || 65536 || 131072 || 262144 || 524288 || 1048576 || reserved
|}
 
This field mainly applies to PRG-RAM in the standard location of $6000-7FFF.<ref>possibly a dumb iNES 2.0 header question :-): http://forums.nesdev.org/viewtopic.php?p=77288#p77288</ref>
* Specifying no PRG-RAM at $6000 for mappers where it is assumed by default, allowing [[open bus behavior]].
* Specifying PRG-RAM at $6000 for mappers where it was never used traditionally, but otherwise has no conflicts and [[PRG RAM circuit|could be supported]].
 
The vast majority of mappers fall into one of the first two categories above. A small number of mappers have other conflicts in the $6000-7FFF region preventing this standard location for PRG-RAM, or may have other special RAM or save requirements that can interact with this field.
 
Special cases, see individual mapper pages for details:
* Bankable PRG-RAM at $6000
** [[MMC1]] ([[SXROM]] 32k, [[SOROM]] 16k)
** [[MMC5]] ([[EWROM]] 32k, [[ETROM]] 16k)
** [[FME-7]] 512k
** [[INES Mapper 083|Mapper 083]] 32k
** [[INES Mapper 176|Mapper 176]] 32k
** [[INES Mapper 178|Mapper 178]] 32k
** [[INES Mapper 186|Study Box]] 35k?
** [[NES 2.0 Mapper 342|COOLGIRL Multicart]] ?
* Separate PRG-RAM chips at $6000, only one battery backed:
** [[SOROM]] 8k + 8k
** [[ETROM]] 8k + 8k
* Self flashable [[EEPROM]] does not count as PRG-RAM (specify 0 in this field), but setting the battery backed bit specifies that the entire flash ROM should be saved.
** [[UNROM 512]] could support additional PRG-RAM at $6000 with a non-zero value in this field.
** [[Cheapocabra]] has a register overlap in the PRG-RAM region but could still potentially support it.
* Internal RAM, separate from PRG-RAM: the internal RAM should not be included in this field, but additional PRG-RAM at $6000 can be specified here.
** [[iNES Mapper 019|Namco 163]] has 128 bytes of internal RAM which may be battery backed. The internal RAM is always implied and not included in this field, but the presence or absence of 8k PRG-RAM can be specified here.
* Internal RAM, replacing standard PRG-RAM: this is a fixed sized already designated by the mapper, so a value in this field that does not match the mapper size has no meaningful interpretation.
** [[MMC6]] has 1k internal PRG-RAM at $6000. This is implied by [[NES 2.0 submappers#004: 1 MMC6|submapper 004:1]].
** [[INES Mapper 080|Taito X1-005]] has 128 bytes of internal RAM.
** [[iNES Mapper 082|Taito X1-017]] has 5k of internal RAM. To specify in this field it must be rounded up to 8k.
** Bandai FCG boards ([[iNES Mapper 016|16]], [[iNES Mapper 159|159]]) have a mapper-implied internal RAM of fixed size.
** [[iNES Mapper 157|Datach Joint ROM System]] adds an additional EEPROM to the Bangai FCG board.
 
In most cases, the battery backed PRG-RAM field can be used as a guide for how much information an emulator must save, but many of the special cases have other requirements that conflict with this, so this field is not universally reliable for that purpose.
 
=== Byte 11 (Video RAM Size) ===
<pre>
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
</pre>
 
The majority of games with no CHR ROM will have $07 (8192 bytes, not battery backed) in this byte.
Use of $00 with no CHR ROM implies that the game is wired to map nametable memory in CHR space. The value $00 MUST NOT be used if a mapper isn't defined to allow this.
 
Battery-backed CHR RAM exists. The [http://www.nesmuseum.com/racermate.html RacerMate Challenge II] cartridge has 64K of CHR RAM total:
32K is battery backed, and 32K of it is not.
 
For backward compatibility, the battery bit in the original [[iNES]] header (byte 6, bit 1) MUST be true if the upper nibble of byte 10 or 11 is nonzero or false otherwise.
 
=== Byte 12 (TV system) ===
Different TV systems have different [[Cycle_reference_chart#Clock_rates|clock rates]], and a game's raster effects and difficulty tuning might expect one or the other.
<pre>
7      0
---------
xxxx xxBP
</pre>
P: 0 indicates NTSC mode; 1 is for PAL mode.
;NTSC mode
:262 lines, NMI on line 241, 3 dots per CPU clock
;PAL mode
:312 lines, NMI on line 241, 3.2 dots per CPU clock
;Dendy PAL mode
:312 lines, NMI on line 291, 3 dots per CPU clock, designed for maximum compatibility with NTSC ROMs, but NES 2.0 does not yet indicate that a game is designed for this 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 [[Detect TV system|detects you running on a PAL or NTSC machine]] - it adjusts the timing of the game and transposes the music.
Not many games would have this B flag set; those that do would be labeled (UE) or the like in GoodNES.
 
=== Byte 13 (Vs. hardware) ===
<pre>
7      0
---------
MMMM PPPP
 
This byte is reserved for the Vs. system only.  If this is not
a Vs. system ROM, the value of this byte must be $00, which
signifies RP2C03B (used in PlayChoice, Famicom Titler, and a
few TVs with built-in Famicom) and no Vs.-specific submapper.
 
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 - RP2C04-0001 (scrambled palette + new colours)
3 - RP2C04-0002 (same as above, different scrambling)
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
 
All thirteen palettes have been dumped. The last 5 PPUs (RC2C05)
have the standard NES palette in them, however they return a specific
word in the lower 5 bits of PPUSTATUS ($2002), and the PPUCTRL ($2000)
and PPUMASK ($2001) ports are flipped around (PPUMASK at $2000 and
PPUCTRL at $2001).
 
Nocash and MESS report:
RC2C05-01 (with ID ([2002h] AND ??h)=1Bh)
RC2C05-02 (with ID ([2002h] AND 3Fh)=3Dh)
RC2C05-03 (with ID ([2002h] AND 1Fh)=1Ch)
RC2C05-04 (with ID ([2002h] AND 1Fh)=1Bh)
and cannot find the 2C05-05
 
 
M: Vs. mode:
 
0 - Normal- no special mode(s)
1 - RBI Baseball  (protection hardware at port 5E0xh)
2 - TKO Boxing    (other protection hardware at port 5E0xh)
3 - Super Xevious (protection hardware at port 5xxxh)
4 - ...
</pre>
 
Nintendo did a few things to make piracy difficult for arcade operators:
;Different PPUs: There are 13 different PPU chips found on Vs. arcade boards.
;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. (FIXME: which games do use what special control panels?)
 
=== Byte 14 (Misc. ROMs) ===
<pre>
7      0
---------
xxxx xxRR
</pre>
 
Supply the amount of extra non-PRG/CHR ROMs; (max of 3 at the moment).  The mapper or sub-mapper will indicate the sizes of these ROM(s) and their function(s).  An example of extra ROMs would be a Mask ROM with audio; such as the M50805 in Family Trainer 3.
 
=== Byte 15 (Reserved) ===
Reserved, this byte must be zero.
 
== Emulator support ==
*BizHawk as of r6313
*FCEUX as of r3071
*[[Nintendulator]] 0.975 Beta
*MESS (per [http://forums.nesdev.org/viewtopic.php?p=62428#p62428 BBS post 62428])
*no$nes v1.1
*[https://kkfos.aspekt.fi/ PowerMappers] v23 for PowerPak
*puNES v.0.90
 
== See also ==
*[[NES 2.0 header for ca65]]
 
== References ==
<references/>


This byte does not denote devices that connect to a cartridge; such devices are part of the respective Mapper's definition.
$00    [[Standard controller|Standard NES/Famicom controllers]]
$01    Famicom controllers with Microphone
$02    NES [[Four Score]]/Satellite with two additional standard controllers
$03    Famicom Four Players Adapter with two additional standard controllers
$04    [[Vs. System]]
$05    Vs. System with reversed inputs
$06    Vs. Pinball (Japan)
$07    Vs. [[Zapper]]
$08    [[Zapper]]
$09    Two Zappers
$0A    Bandai Hyper Shot
$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]]
$13    [[Coconuts Pachinko]] Controller
$14    [[Exciting Boxing Punching Bag]]
$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 Keyboard
$1A    Pokkun Moguraa
$1B    Top Rider
$1C    Double-Fisted
$1D    [[Famicom 3D glasses|Famicom 3D System]]
$1E    Doremikko Keyboard
$1F    R.O.B. Gyro Set
$20    [[Family BASIC Data Recorder|Famicom Data Recorder]] (don't emulate 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)
$29    [[Mouse#SNES Mouse|SNES Mouse]]
$2A    Multicart
$2B    Two SNES controllers replacing the two standard NES controllers
$2C    RacerMate Bicycle
Notes:
* The microphone ($01) is denoted only if it is triggers a game-specific function.
* 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.
* Outside of netplay and situations where the user has configured two mice or one mouse and a touchscreen, "Two Zappers" ($09) will be treated identically to one "Zapper" ($08), i.e. with the first standard controller plugged-in.
* "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.
=References=
* [http://forums.nesdev.org/viewtopic.php?p=17727#p17727 Original proposal by kevtris]
* [http://forums.nesdev.org/viewtopic.php?f=3&t=17213&start=45#p220624 Additions proposal by NewRisingSun]
[[Category:File formats]]
[[Category:File formats]]

Revision as of 17:56, 2 January 2019

NES 2.0 extends the iNES single file cart format to better describe NES/Famicom-compatible cartridge hardware for emulation purposes, by ...

  • ... resolving emulation-relevant hardware differences that are ambiguous in iNES;
  • ... allowing for larger ROM sizes;
  • ... supporting other than standard NES/Famicom console types such as the Nintendo Vs. System and enhanced Famiclones;
  • ... providing additional emulation-relevant information such as the region-specific CPU/PPU timing and default expansion port devices.

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 use NES-2.0-exclusive features. It is furthermore intended to replace the deprecated UNIF format.

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 #1
       D~7654 3210
         ---------
         NNNN FTBM
         |||| ||+-- Hard-wired nametable mirroring type
         |||| ||     0: Horizontal or mapper-controlled
         |||| ||     1: Vertical
         |||| |+--- "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
         |||| +---- Additional memory for four nametables
         ||||        0: Not present
         ||||        1: Present ("four-screen mode")
         ++++------ Mapper Number D0..D3

$7     Flags #2
       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 D4..D7

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

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

$A     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 SHL shift count" bytes, i.e. 8192 bytes for a shift count of 7.

$B     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 SHL shift count" bytes, i.e. 8192 bytes for a shift count of 7.

$C     CPU/PPU Timing
       D~7654 3210
         ---------
         .... ..VV
                ++- CPU/PPU timing mode
                     0: RP2C02 ("NTSC NES")
                     1: RP2C07 ("Licensed PAL NES")
                     2: Game detects console timing and adjusts itself
                     3: UMC 6527P ("Dendy")

$D     When Byte $07 AND $03 =1: Vs. System Type
       D~7654 3210
         ---------
         MMMM PPPP
         |||| ++++- Vs. PPU Type
         ++++------ Vs. Hardware Type

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

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

$F     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 D0..D3
  |||| ++++-++++- 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 D0..D3
  |||| ++++-++++- 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 blocks 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 PRG-ROM size in 8 KiB units: 

  ++++----------- Header byte 9 D4..D7
  |||| ++++-++++- Header byte 5
D~BA98 7654 3210
  --------------
  BBBB BBBB BBBB
  ++++-++++-++++- PRG-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 D4..D7
  |||| ++++-++++- 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 only for three 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 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.

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 D2..D3) 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-$F such as "DiskDude!".

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;
  • 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 mapper-chip-internal memory that is not mapped into CPU address space, such as the Namco 163's wavetable RAM.

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 $B.

The CHR-RAM size does not include the additional memory for four nametables denoted in Header byte $6 D3.

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
3      UMC 6527P  Eastern Europe, Russia, Mainland China, India, Africa

Emulators should implement value 2 ("self-adjusting") 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 UMC 6527P 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 D0..D1 is 1 (Vs. System), the lower nibble of Header byte $D 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 $D D0..D3):
$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 $D D4..D7):
$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 D0..D1 is 3 (Extended), the lower nibble of Header byte $D 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 (e.g. Bit Corporation Creator)
$4      V.R. Technology VT01 with monochrome palette
$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-$F   reserved

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

Default Expansion Device

Header byte $F indicates that an emulator should automatically "plug in" an expansion port device that is accessible at CPU $4016/$4017.

In almost 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 the (mostly homebrew) games that support different player-selectable expansion devices, this byte will denote the default selection, which in most cases will be the standard controllers ($00). In any case, emulator users should always be free to select a different expansion device themselves afterwards.

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

$00     Standard NES/Famicom controllers
$01     Famicom controllers with Microphone
$02     NES Four Score/Satellite with two additional standard controllers
$03     Famicom Four Players Adapter with two additional standard controllers
$04     Vs. System
$05     Vs. System with reversed inputs
$06     Vs. Pinball (Japan)
$07     Vs. Zapper
$08     Zapper
$09     Two Zappers
$0A     Bandai Hyper Shot
$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
$13     Coconuts Pachinko Controller
$14     Exciting Boxing Punching Bag
$15     Jissen Mahjong Controller
$16     Party Tap
$17     Oeka Kids Tablet
$18     Sunsoft Barcode Battler
$19     Miracle Piano Keyboard
$1A     Pokkun Moguraa
$1B     Top Rider
$1C     Double-Fisted
$1D     Famicom 3D System
$1E     Doremikko Keyboard
$1F     R.O.B. Gyro Set
$20     Famicom Data Recorder (don't emulate 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)
$29     SNES Mouse
$2A     Multicart
$2B     Two SNES controllers replacing the two standard NES controllers
$2C     RacerMate Bicycle

Notes:

  • The microphone ($01) is denoted only if it is triggers a game-specific function.
  • 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.
  • Outside of netplay and situations where the user has configured two mice or one mouse and a touchscreen, "Two Zappers" ($09) will be treated identically to one "Zapper" ($08), i.e. with the first standard controller plugged-in.
  • "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.

References

Retrieved from "https://www.nesdev.org/w/index.php?title=NES_2.0&oldid=7561"