Current Mapper List?

[Raiden the Quick]

If it helps, I went into FCEUX and printed the contents of the "bmap" array to a file. This array contains all mappers with numbers and, if included, names. Many of them have no names, but I assume they're included for some reason? Oh well...disclaimer: this is just data within FCEUX, no idea how valid or official or correct it is!

# Name
0 NROM
1 MMC1
2 UNROM
3 CNROM
4 MMC3
5 MMC5
7 ANROM
11 Color Dreams
12
13 CPROM
15 100-in1
16 Bandai
19 Namcot 106
23 Konami VRC2 type B
35 Wario Land 2
36 TXC Policeman
37
38 Bit Corp. Crime Busters
43
44
45
47
49
52
57
58
60
66 MHROM
68 Sunsoft Mapper #4
70
74
78 Irem 74HC161/32
87
88
90
93 Sunsoft UNROM
94
95
101
103
105
106
107
108
112
113
114
115
116
117
118 TSKROM
119
120
121
123 UNLH2288
132 UNL22211
133 SA72008
134
136 TCU02
137 S8259D
138 S8259B
139 S8259C
140
141 S8259A
142 UNLKS7032
143 TCA01
144
145 SA72007
146 SA0161M
147 TCU01
148 SA0037
149 SA0036
150 S74LS374N
152
153
154
155
160 SA009
163
164
165
171
172
173
175
176 BMCFK23C
177
178
180
181
182
183
184
185
186
187
188
189
191
192
194
195
196
197
198
199
200
205
206 DEIROM
208
209
210
211
215
216
217
219 UNLA9746
220 OneBus
221 UNLN625092
222
226
235
238 UNL6035052
240
243 S74LS374NA
245
249
250
253
254

[6T4]

disclaimer: this is just data within FCEUX, no idea how valid or official or correct it is!

This is another problem I have with the current mapper/board system. Some emulators read what mapper a game is directly from the iNES header, others look at the game code, others check hashes of roms and compare to a precompiled list, and others use some combination of these methods.

Each of these methods has advantages and disadvantages. The first makes it easy in many cases to tell if a rom is misnumbered in the header, but doesn't do much to put the correct value there and also doesn't specify the board in all cases which both of the other methods can do.

The second method is usually used in combination with the first, and checks for the amount of prg and chr rom to verify it matches the mapper number in the header and also that the actual amount of rom contained in the game is correct in the header. While this method can correct rom values in the header and narrow down the list of possible boards, it can't always verify the correct board.

The last method uses a list of hashes of all known roms and their corresponding boards and compares the hash of the rom being emulated with the list. If there's a match, great; the settings can be applied to the header if it's incorrect, and the emulator knows exactly which board to use. However, if there is no match, there is nothing else to do to determine the correct board. This system obviously doesn't allow the emulation of newly developed games until they are added to the list.

I believe the best way to handle this while we are still using the iNES format for roms is to use a combination of all three of these. Only the last one can determine exactly which board to use, only the first can determine if the mapper number in the header is labeled correctly, and only the other can determine whether the amount of rom labeled in the header is correct.

I can also give some info about what a few emulators do currently. I believe Jnes and UberNES use the first method of reading from the header, while VirtuaNES uses the last method of comparing hashes. Nestopia seems to sometimes not match what the header says about the mapper when you view info about a loaded rom, but it has a rom header editor which can read directly from the header. I am unfamiliar with what other emulators such as FCEUX and Nintendulator do regarding this, but those two and many others are open source so you should be able to find out. I hope all of this is of some use.

[Dwedit]

FCEUX and Nintendulator do not use any databases, and simply go by the NES header.
This used to be The Way to do things.

Since FCEUX was intended to be a NES hacker's emulator, rom databases seem very out of place.

VirtuaNES doesn't seem to correct mapper numbers. I think it's just Nestopia that does this.

[tepples]

And there were three reasons why it became no longer The Way.

First, once the number of mappers expanded past 16, new space was needed to hold the rest of the mapper number. The space was reserved in the iNES header for expansion, but some ROM management tools and pirate ROM sites were already using that space to advertise themselves. (This is referred to as the "DiskDude! problem".) Emulators conforming to the new standard would see wrong mapper numbers because they would misinterpret part of the signature as part of the mapper number.

Second, sometimes one mapper is broken into two due to new discoveries about its function. Games published by Camerica were thought to be compatible with mapper 2 (UNROM) until new information was discovered about the registers used by their lockout defeat. So a new mapper was forked off.

Third, a few mappers have variants that never resulted in a new mapper number. There are two main types of Camerica mapper: single-game and multiple-game. And there are two types of MMC1 mapper: those with up to 8 KiB PRG ROM. There are four types of MMC3/MMC6 mapper commonly called mapper 4: ordinary PRG RAM, MMC6 style PRG RAM (StarTropics and StarTropics 2), open bus on PRG RAM (required for Low G Man), no IRQ or mirroring control (MIMIC-1, the predecessor to MMC3). This situation is what led Kevin Horton to specify an extension to iNES called NES 2.0 that defines how these shall be distinguished.

[zzo38]

I propose two new mapper numbers: "internal extension", and "external extension". For "internal extension" there are a few extra bytes to program rules of the mapper in a simple code. For "external extension" it is assumed that whoever is using that .NES file already has some program/file for dealing with that particular game. If new mappers are needed, you can extend the codes used for the "internal extension" mapper.

[MottZilla]

Sorry, but a million people have a million different ideas. You can't get away from the iNES standard. iNES 2.0 introduced sub-mapper number which is more than enough. Just pick your method.

[Zepper]

Sorry, but a million people have a million different ideas. You can't get away from the iNES standard. iNES 2.0 introduced sub-mapper number which is more than enough. Just pick your method.

Indeed.