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