NES 2.0

From NESdev Wiki
Revision as of 06:06, 8 August 2018 by Rainwarrior (talk | contribs) (→‎Byte 10 (RAM size): 157 is different, not sure exactly what to say about it here)
Jump to navigationJump to search

NES 2.0 is an extension to the iNES ROM format, originally proposed by Kevin Horton on 2006-09-18.

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.

This extension is backwards compatible with the original format, identified by two bits in byte 7 of the header.

Overview

NES 2.0 is an addition to the standard .NES file format that most emulators use. It is designed to disambiguate certain ROMs that formerly could have been only be discerned via a CRC-32 or similar hash check. 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.

There are four goals for this specification:

  1. Retain 100% backwards compatibility with existing emulators/ROMs/etc. (*this includes "dirty ROMs" with crap such as "DiskDude!" in the header and other atrocities*)
  2. The format must be "future proof".
  3. The changes made must be very carefully documented and make sense.
  4. Said changes must make sense from both a hardware and software standpoint.

The name of this specification is "NES 2.0". Do not confuse with "iNES 2.0" which is an emulator that does not support extended features of NES 2.0 headers.

Existing header

The standard specification as popularized by the iNES emulator is presented below: 

 0-3: string    "NES"<EOF>
   4: byte      Number of 16384 byte program ROM pages
   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.

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)

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.

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. 

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.

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: 

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

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 "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[1] dumped by TeamEurope, which is 32 MB.[2].

Submappers

See: NES 2.0 submappers

Occasionally, two mappers get one number. Sometimes, an emulator can distinguish them easily: 34 covers both NINA-001 and BNROM, but NINA-001 has CHR ROM, and BNROM has CHR RAM. But other mappers are messier: 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, 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 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)

7       0
---------
SSSS MMMM

S: Submapper number.  Mappers not using submappers set this to zero.
M: Bits 11-8 of mapper number.

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 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 proposal on the BBS to break up the expanded mapper space into "planes", much like those of 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
  • Plane 1 (256-511): Mostly for new homebrew mappers.
  • 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)

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.

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)

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

Bytes 10 and 11 of the header define the size of the RAM segments exponentially using 4-bit values:

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.[3]

  • 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 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
  • Separate PRG-RAM chips at $6000, only one battery backed:
  • 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.
    • 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 submapper 004:1 but may additionally be specified in this field.
    • Taito X1-005 has 128 bytes of internal RAM.
    • Taito X1-017 has 5k of internal RAM. It may be specified in this field (but would have to be rounded up to 8k).
    • Bandai FCG boards (16, 159) have a mapper-implied internal RAM of fixed size.
    • 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)

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

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 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 clock rates, and a game's raster effects and difficulty tuning might expect one or the other. 

7       0
---------
xxxx xxBP

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

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

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)

7       0
---------
xxxx xxRR

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

See also

References

  1. ↑ SomeRussianMarioDude's review
  2. ↑ CaH4e3's Dumping 2015
  3. ↑ possibly a dumb iNES 2.0 header question :-): http://forums.nesdev.org/viewtopic.php?p=77288#p77288
Retrieved from "https://www.nesdev.org/w/index.php?title=NES_2.0&oldid=7558"