NES 2.0
NES 2.0 is an extension to the iNES ROM format, proposed by Kevin Horton on 2006-09-18. He has implemented it in his FPGA NES.
- Written by K.Horton
- Thanks to Quietust for ideas and proofing and help
This is the tentative addition to the standard .NES file format that most emulators use. This addition is designed to disambiguate certain ROMs that currently can only be discerned via a CRC-32 or similar hash check. Naturally, this causes problems for new ROMs that are not in the database, but need special handling.
There are four goals for this specification:
- Retain 100% backwards compatibility with existing emulators/ROMs/etc. (*this includes "dirty ROMs" with crap such as "DiskDude!" in the header and other atrocities*)
- The format must be "future proof".
- The changes made must be VERY CAREFULLY documented and make sense.
- Said changes must make sense from both a hardware and software standpoint.
Existing header
The standard iNES specification 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 LJ65, 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.
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. KH discovered that very few existing ROMs have a trainer, and most of these aren't real trainers at all but subroutines used by a mapper hack.
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
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. Kevin has tested over 4000 ROMs and have dumped at least a thousand more, and reverse engineered probably 60-70 different mappers. This has given him a front row seat into the shortcomings of the original, and a good idea of where additional information is needed.
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.
Submappers
Occasionally, two mappers get one number. Sometimes, an emulator can distinguish them easily: 34 covers both NINA-1 and BNROM, but NINA-1 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 1/4th 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
Mapper variant
Byte 8 is defined as follows:
7 0 --------- SSSS MMMM S: Submapper number. Mappers not using submappers set this to zero. M: Bits 11-8 of mapper number.
Submappers define mostly how CHR is wired up. Most mappers will not use submappers; they set S to 0.
Caution: Do not assign mapper numbers greater than 255 yet. There are still some existing numbers left in the current iNES mapper space. (Around 30-40 or so as of late 2006). Mapper numbers up to 511 should hold us until the next Ice Age film comes out; mapper numbers up to 4095 should hold us until the next literal ice age.
Upper bits of ROM size
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.
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.
RAM size
Bytes 10 and 11 of the header define the size of the RAM segments exponentially using 4-bit values:
| value | RAM size in bytes |
|---|---|
| 0 | 0 |
| 1 | 128 |
| 2 | 256 |
| 3 | 512 |
| 4 | 1024 |
| 5 | 2048 |
| 6 | 4096 |
| 7 | 8192 |
| 8 | 16384 |
| 9 | 32768 |
| 10 | 65536 |
| 11 | 131072 |
| 12 | 262144 |
| 13 | 524288 |
| 14 | 1048576 |
| 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
Serial EEPROMs are familiar to developers of Game Boy Advance and Nintendo DS emulators. But they're older than that: 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 semi-custom chip. The interface for the 24Cxx parts is similar to I²C, a computer bus invented by Philips, but the address and data are clocked in backwards from standard I²C.
Some games on SOROM or ETROM have two PRG RAM chips, one battery-backed and one not. Which chip appears earlier in PRG RAM address space depends on the mapper. For example, SOROM (mapper 1, no CHR ROM, 8192+8192 byte CHR RAM) puts the battery-backed chip at bank 2 and the other chip at bank 0.
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. KH traced out the circuit and couldn't believe it. It probably simplified the routing or power off protection.
TV system
Different TV systems have different clock rates, and a game's raster effects and difficulty tuning might expect one or the other.
Byte 12: 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.
Vs. hardware
Byte 13: 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, 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 KH has a good cross-section of Vs. games and has dumped bit-for-bit palettes from all thirteen of these PPUs. 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) (FIXME: what word?), and the PPUCTRL ($2000) and PPUMASK ($2001) ports are flipped around (PPUMASK at $2000 and PPUCTRL at $2001). M: Vs. mode: 0 - Normal- no special mode(s) 1 - RBI Baseball 2 - TKO Boxing 3 - Super Xevious 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.
- Protection
- 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. This sort of overlaps with submappers.
Emulator support
- Nintendulator 0.975 Beta
