NES 2.0: Difference between revisions
NewRisingSun (talk | contribs) (Majesco (MSI)'s licensed plug-and-play release of Mega Man II uses a protection in the form of swapped controller input.) |
LightStruk (talk | contribs) m (Link to Miracle Piano page from Expansion Device section) |
||
| Line 312: | Line 312: | ||
$17 [[Oeka Kids tablet|Oeka Kids Tablet]] | $17 [[Oeka Kids tablet|Oeka Kids Tablet]] | ||
$18 Sunsoft Barcode Battler | $18 Sunsoft Barcode Battler | ||
$19 Miracle Piano Keyboard | $19 [[Miracle_Piano|Miracle Piano Keyboard]] | ||
$1A Pokkun Moguraa (Whack-a-Mole Mat and Mallet) | $1A Pokkun Moguraa (Whack-a-Mole Mat and Mallet) | ||
$1B Top Rider (Inflatable Bicycle) | $1B Top Rider (Inflatable Bicycle) | ||
Revision as of 19:40, 23 October 2020
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 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 |||| +---- Hard-wired four-screen mode |||| 0: No |||| 1: Yes ++++------ Mapper Number D0..D3 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 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 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: UMC 6527P ("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 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 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 D4..D7
|||| ++++-++++- 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 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-15 such as "DiskDude!".
Hard-Wired Mirroring
- Header Byte 6 bit 0 is relevant only if the mapper does not allow the mirroring type to be switched. Otherwise, it must be ignored and should be set to zero.
- Bit 3 is set only if 4 KiB of RAM are present at PPU $2000-2FFF, exclusive to that region, and cannot be banked, replaced, or rearranged. Currently, only the four-screen variants of mappers 4 and 206 as well as 77, 262 and the Nintendo Vs. System meet that definition. However, as the original iNES format (incorrectly) assumed that the availability of four-screen mirroring is independent of the mapper, perfect iNES compatibility would require that bit 3=1 overrides the hard-wired/software-controlled mirroring of any mapper unless it can remap CHR-RAM/ROM into the nametable address space.
- Mappers 30 and 218 are exceptions and interpret these two bits in idiosyncratic ways.
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 3 UMC 6527P 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 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 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 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 13 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 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 (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 UMC UM6578 $C-$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 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 $04 Vs. System $05 Vs. System with reversed inputs $06 Vs. Pinball (Japan) $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 (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 ($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
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.
- Double-Fisted 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.
- "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.
