The .NES file format (file name suffix .nes) is the de facto standard for distribution of NES binary programs, with use even in licensed emulators such as commercialized PocketNES and Wii Virtual Console. It is often called the iNES format, as it was created by Marat Fayzullin for an emulator called iNES. A "rebooted" version of this file format, NES 2.0, was created to fix many shortcomings and support in emulators is being added.
.NESファイル形式（ファイル名接尾辞.nes）は、NESバイナリプログラムを配布するための事実上の標準です, 市販のPocketNESやWii Virtual Consoleなどのライセンスを取得したエミュレータでも使用できます。 これは、Marat Fayzullinによって iNES と呼ばれるエミュレータ用に作成されたので、しばしばiNES形式と呼ばれます。 このファイル形式の「再起動」バージョンである、 NES 2.0は、多くの欠点を修正し、エミュレータのサポートを追加するために作成されました。
iNES エミュレータ―
iNES は Marat Fayzullin 氏が作成しているNESエミュレータです。 Its most lasting contribution to the NES scene was its popularization of the iNES ROM file format and mapper numbering system.
ファイル形式の名称について
このファイル形式は、一般にiNESファイル形式/ iNESヘッダー形式と呼ばれます。ファイル拡張子は.nesであるため、.nesファイル形式と呼ばれることがあります。似た仕様やフォーマットをサポートする、NES 2.0ファイル形式が同じ.nes拡張子を使用しているので、.nesファイル/ .nesファイル形式は、iNESファイル形式またはNES 2.0形式のいずれかである可能性があります, したがって、形式の違いが関係する場合は、完全な形式名を使用する必要があります。
iNESファイル形式
An iNES file consists of the following sections, in order:
ヘッダー (16 バイト) トレーナー ( 未使用 0 バイト、使用 512 バイト) PRG ROM データ (16384 * x バイト) CHR ROM データ 存在する場合 (8192 * y バイト) PlayChoice INST-ROM, 存在する場合 (0 or 8192 バイト) PlayChoice PROM, 存在する場合 (16 バイト Data, 16 バイト CounterOut) (this is often missing, see PC10 ROM-Images for details)
Some ROM-Images additionally contain a 128-byte (or sometimes 127-byte) title at the end of the file.
ヘッダーのフォーマット
0-3 : 固定値 $4E $45 $53 $1A ("NES" + MS-DOS の 終端記号)
4 : PRG ROM のサイズ ( × 16 KB )
5 : CHR ROM のサイズ ( × 8 KB ) ( 0: CHR RAMが搭載されている)
6 : Flags 6
7 : Flags 7
8 : PRG RAM のサイズ ( × 8 KB ) ( 0: 互換性の為 8 KB と推定します。PRG RAM 回路を参照)
9 : Flags 9
10 : Flags 10 (unofficial)
11-15 : Zero filled
Flags 6
7654 3 2 1 0 ---------------- MapL 4S Tr BB Mr
Mr 0: vertical arrangement/horizontal mirroring (CIRAM A10 = PPU A11)
1: horizontal arrangement/vertical mirroring (CIRAM A10 = PPU A10)
BB 1: バッテリーバックアップ PRG RAM ($6000-7FFF)か、その他のメモリがカートリッジに載っている
Tr 1: 512バイト トレーナーあり $7000-$71FF (PRG dataの前に配置される)
4S 0: V/H arrangementビット有効
1: 4画面 VRAM
MapL マッパー番号の下位4ビット
In the iNES format, cartridge boards are divided into classes called "mappers" based on similar board hardware and behavior, and each mapper has a number from 0 to 255.
iNESフォーマットでは、カートリッジボードは、同様のボードハードウェアと動作に基づいて「マッパー」と呼ばれるクラスに分割され、各マッパーは0〜255の番号を持ちます。
Some mappers, such as MMC1, MMC3, and AxROM, can control nametable mirroring. They ignore bit 0. On the other hand, if bit 3 is true, the cart has 4 KiB of RAM at PPU $2000-$2FFF, and it ignores the mapper's CIRAM A10 output (as in Rad Racer 2). One exception is #218, which uses the four-screen bit to switch between one-screen and V/H mirroring.
MMC1、MMC3、AxROMなどの一部のマッパーでは、ネームテーブルのミラーリングを制御できます。 一方、ビット3が真の場合、カートにはPPU $ 2000- $ 2FFFに4 KiBのRAMがあり、 マッパーのCIRAM A10出力を無視します（Rad Racer 2のように）。 1つの例外は＃218です。これは4画面ビットを使用して1画面とV / Hミラーリングを切り替えます。
Unlike the PowerPak, Famicom copiers did not implement even the most popular Famicom mappers. Instead, games for the copiers were patched to use the mappers that the copier supported, and some of these patches relied on extra code called a "trainer" that the copier loaded into PRG RAM before starting the game. One of these copiers was made by Front Fareast Industrial; hence the nickname "FFE" for these mapper hacks. It is probably not worth the effort to support FFE hacks in future emulators or copiers because substantially all games available with an FFE hack also have a good dump without a trainer.
PowerPakとは異なり、Famicomコピー機は最も人気のあるFamicomマッパーを実装していませんでした。 その代わりに、コピー機のゲームは、コピー機がサポートしているマッパーを使用するようにパッチが当てられました。 これらのパッチの一部では、ゲームを開始する前にコピー機がPRG RAMにロードした「トレーナー」と呼ばれる余分なコードに依存していました。 これらのコピー機の1つはフロントファレストインダストリーによって製造されたものだったので、これらのマッパーハックに「FFE」というニックネームがついています。 将来のエミュレータやコピー機でFFEのハックをサポートする努力をする価値はないでしょう。 実質的にFFEのハックで利用できるすべてのゲームには、トレーナーがいなくても良いダンプを持っているからです。
しかし、一部の改造ROMにおいてもトレーナーを使用している場合があるようです。 トレーナーは$7000〜のプログラムを破壊してしまうため、このアドレスを使用するマッパーでは正常に動作しないでしょう。
Flags 7
7654 32 1 0 ------------- MAPH V2 PC VS
VS 1: VS Unisystem PC 1: PlayChoice-10 (8KB の ヒント画面データが CHR dataの後に載っている) V2 10: フラグ 8-15 は NES 2.0 形式で使用される MapH xxxx: マッパー番号の上位4ビット
The PlayChoice-10 bit is not part of the official specification, and most emulators simply ignore the extra 8KB of data. PlayChoice games are designed to look good with the 2C03 RGB PPU, which handles color emphasis differently from a standard NES PPU.
PlayChoice-10ビットは公式仕様の一部ではなく、ほとんどのエミュレータは余分な8KBのデータを無視します。 PlayChoice-10のゲームは、2C03 RGB PPUでよく見えるように設計されています。これは標準のNES PPUとは異なる色の強調を扱います。
Vs. games have a coin slot and different palettes. The detection of which palette a particular game uses is left unspecified.
VS Unisystemではコインスロットと異なるパレットがあります。 特定のゲームがどのパレットを使用するかの検出は不特定のままである。
NES 2.0 is a more recent extension to the format that allows more flexibility in ROM and RAM size, among other things.
NES 2.0形式は、とりわけROMやRAMサイズの柔軟に指定すること可能にするフォーマットへの新しい拡張です。（といっても、2005年だけど）
Flags 9
7654321 0 ---------- RV TV
TV 0: TV system NTSC
1: TV system PAL
RV 未使用 0をセット
Though in the official specification, very few emulators honor this bit as virtually no ROM images in circulation make use of it.
公式の仕様で、ほとんどのエミュレータはこのビットを賞賛していますが、流通しているROMイメージではそれを使用していません。
Flags 10
76543210
|| ||
|| ++- TV system (0: NTSC; 2: PAL; 1/3: dual compatible)
|+----- PRG RAM ($6000-$7FFF) (0: present; 1: not present)
+------ 0: Board has no bus conflicts
1: Board has bus conflicts
This byte is not part of the official specification, and relatively few emulators honor it.
このバイトは公式仕様の一部ではなく、比較的少数のエミュレータがそれを尊重しています。
The PRG RAM Size value (stored in byte 8) was recently added to the official specification; as such, virtually no ROM images in circulation make use of it.
PRG RAM Size値（バイト8に格納されています）は、最近公式仕様に追加されました。したがって、流通しているROMイメージは事実上使用されません。
Older versions of the iNES emulator ignored バイト 7-15, and several ROM management tools wrote messages in there. Commonly, these will be filled with "DiskDude!", which results in 64 being added to the mapper number.
古いバージョンのiNESエミュレータは、バイト7-15を無視しました。 いくつかのROM管理ツールがそこにメッセージを書きました。 一般的に、これらは「DiskDude！」で埋められますが、 その結果64がマッパー番号に追加されます。
A general rule of thumb: if the last 4 バイト are not all zero, and the header is not marked for NES 2.0 format, an emulator should either mask off the upper 4 bits of the mapper number or simply refuse to load the ROM.
一般的な経験則：最後の4バイトがすべてゼロでない場合、 ヘッダーにNES 2.0形式のマークが付いていない場合は、 エミュレータはマッパー番号の上位4ビットをマスクするか、単にROMのロードを拒否する必要があります。
Variant comparison
バリアントの比較
Over the years, the header of the .NES file format has changed as new features became needed. There are three discernable generations:
長年にわたり、.NESファイル形式のヘッダーは、新しい機能が必要になったときに変更されました。識別可能な世代は3つあります。
Archaic iNES
Created by Marat and used in very old versions of iNES and in NESticle. ROM image conversion and auditing tools tended to store signature strings at offsets 7-15.
Maratによって作成され、非常に古いバージョンのiNESおよびNESticleで使用されています。 ROMイメージ変換ツールと監査ツールは、オフセット7〜15で署名文字列を格納する傾向がありました。
iNES 0.7
Created by Marat when the scene discovered the diversity of NES cartridge hardware. Mapper high nibble is supported in emulators since roughly 2000.
シーンがNESカートリッジハードウェアの多様性を発見したときにMaratによって作成されました。 Mapperの上位ニブルは、2000年頃からエミュレータでサポートされています。
iNES
Later revisions added byte 8 (PRG RAM size) and byte 9 (TV system), though few other emulators supported these fields.
後のリビジョンでは、バイト8（PRG RAMサイズ）とバイト9（TVシステム）が追加されましたが、他のエミュレータではほとんどサポートされませんでした。
NES 2.0
Created by kevtris for the FPGA Kevtendo and maintained by the NESdev community to clarify ambiguous cases that previous headers did not clarify. Became widely adopted starting in the 2010s.
FPGA Kevtendoのkevtrisによって作成され、NESdevコミュニティによって以前のヘッダーが明らかにされていないあいまいなケースを明らかにするために維持されています。 2010年代から広く採用されました。
| Thing | Archaic iNES | iNES | NES 2.0 | |
|---|---|---|---|---|
| Byte 7 | Unused | Mapper high nibble, Vs. | Mapper high nibble, NES 2.0 signature, PlayChoice, Vs. | |
| Byte 8 | Unused | Total PRG RAM size (linear) | Mapper highest nibble, mapper variant | |
| Byte 9 | Unused | TV system | Upper bits of ROM size | |
| Byte 10 | Unused | Unused | PRG RAM size (logarithmic; battery and non-battery) | |
| Byte 11 | Unused | Unused | VRAM size (logarithmic; battery and non-battery) | |
| Byte 12 | Unused | Unused | TV system | |
| Byte 13 | Unused | Unused | Vs. PPU variant | |
| マッパサポート | 0-15 | 0-255 | 0-4095 |
推奨される検出手順
If byte 7 AND $0C = $08, and the size taking into account byte 9 does not exceed the actual size of the ROM image, then NES 2.0. If byte 7 AND $0C = $00, and バイト 12-15 are all 0, then iNES. Otherwise, archaic iNES.
参照
INES 1.0 Mapper Grid List of INES mappers
参考文献
Official iNES specs iNES format by rvu iNES header/format by VmprHntrD iNES emulator
NES 2.0
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.
Contents
1 Overview
2 Existing header
2.1 Byte 6 (Flags 6)
2.2 Byte 7 (Flags 7)
3 The problem cases
3.1 Vs. Unisystem
3.2 Big ROMs
3.3 Submappers
3.4 Mapper number exhaustion
3.5 WRAM
4 The proposed solution
4.1 Byte 8 (Mapper variant)
4.2 Byte 9 (Upper bits of ROM size)
4.3 Byte 10 (RAM size)
4.4 Byte 11 (Video RAM Size)
4.5 Byte 12 (TV system)
4.6 Byte 13 (Vs. hardware)
4.7 Byte 14 and 15 (Reserved)
5 Emulator support
6 See also
7 References
Overview
Written by K.Horton Thanks to Quietust for ideas and proofing and help
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:
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.
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. 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.
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
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, 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 serial EEPROM, see below)
P: Quantity of PRG RAM which is NOT battery backed
The PRG RAM need not be actual RAM; it may also be EEPROM. 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. They most often used the 24C01 (with 128 bytes) or 24C02 (with 256 bytes), but there's no practical limitation on total size. Both ICs use the I²C bus.
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 byte CHR RAM, 8192+8192 byte PRG RAM) puts the battery-backed chip at bank 2 and the other chip at bank 0.
Most discrete logic mappers lacked specific support for PRG RAM. For these mappers, emulators should continue the iNES tradition of extending the stock mappers' functionality in the same way that Family BASIC extended that of mapper 0. A cartridge can have up to 8192 bytes of either battery-backed or non-battery-backed RAM at $6000-$7FFF,[3] decoded with an 74HC20 or 74LS139. But some mappers have registers in $6000-$7FFF and do not define a mapping for PRG RAM or serial EEPROM, such as Jaleco's JF-13. Headers for ROMs using these mappers MUST specify 0 for both PRG RAM sizes.
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
Sizes that are not a power of two, such as the 5120 byte battery-backed RAM of Taito's X1-017, are rounded up.
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. 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.
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
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), 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 and 15 (Reserved)
Reserved, these two bytes must be zero.
Emulator support
BizHawk as of r6313 FCEUX as of r3071 Nintendulator 0.975 Beta MESS (per BBS post 62428) no$nes v1.1 PowerMappers v23 for PowerPak puNES v.0.90
See also
NES 2.0 header for ca65
References
↑ SomeRussianMarioDude's review ↑ CaH4e3's Dumping 2015 ↑ possibly a dumb iNES 2.0 header question :-): http://forums.nesdev.com/viewtopic.php?p=77288#p77288