Does anybody have or know of a comprehensive summary of every iNES mapper assignment? The lists I've found are all 5-10 years old.
Probably look in the source code of a recent emulator, like FCEUX or Nestopia.
I don't know of any full list, but there are a few good almost complete lists. They are Comprehensive NES Mapper Document v0.80 by \Firebug\, Disch's mapper docs, and a section of Martin Korth's everynes. I would suggest reading all of these and looking at the sources of current emulators as mentioned already to create your own comprehensive list.
I have actually been wishing there was a list like this (and more complete and reliable documentation about other aspects of the NES), as I am currently developing an NES emulator. Because of this, I will be writing a new completely comprehensive NES document as I work on the emulator. But until that's done, I have a little bit more info about mappers. The following mapper numbers are those that I am NOT familiar with any game using; I have some information about all the others from 0-255: 28, 29, 30, 31, 35, 39, 54, 55, 59, 63, 81, 98, 102, 104, 109, 110, 123, 124, 125, 126, 127, 128, 129, 130, 131, 135, 144, 153, 154, 155, 157, 158, 162, 166, 170, 174, 179, 181, 190, 192, 194, 195, 199, 207, 208, 218, 223, 224, 236, 237, 247.
I hope this helps you. If anyone has information on the above listed mappers, please let me know. One last question I have for everyone that's related to this post: where did emulator authors (like those of Nestopia and FCEUX) get their information about uncommon mappers? There are many mappers that some emulators support that I have found no documentation about other than the source codes of those emulators, and I was just wondering how they got their information.
To the best of my knowledge, roughly half of the alphabet has been covered with mapper family(?) names. The ones remaining are: IxROM, JxROM, KxROM, LxROM, MxROM, OxROM, QxROM, RxROM, VxROM, WxROM, XxROM, YxROM and ZxROM.
Any idea why the others were selected as they were? I presume the MMC5 family was dubbed "ExROM" due to the ExRAM functionality...
JSROM and JLROM exists (FME-7), and so does MHROM (SMB + Duck Hunt).
Also RROM (variant of NROM) exists I don't know if it counts as a RxROM board or not.
I think there is no particular meaning in those letters, exept the "ROM" part which means the boards were means to be used by mask ROMs, while prototypes ends in "EPROM" which means they were meant to be used by EPROMs....
However, in cases where the pinout is the same for both (for ROMs smaller than 128k) they used just "ROM" boards for prototypes.
About the information, you should check Dish's excellent doccumentation on RHDN
here.
if it's still not there then I guess emulators got this by dark magic. It's exactly how are SNES emulators able to emulate the Super FX and SA-1 when the only doccumentation about those is the emulators source code... argh.
Just wanted to add that not all boards are named in the XxROM format. However, all those that are I think were originally made by Nintendo.
I'll go ahead and cross JxROM and MxROM off my list (and bestow provisional legitimacy upon NxROM and RxROM).
I'm still a bit miffed that MMC3 was assigned to Mapper #4. It always causes grief when explaining the whole "NES couldn't run most of its own games" saga to casual retro gamers. I illustrate the Big Three by relating them to automotive parallels (MMC1 = Chevy Cavalier; MMC3 = Acura TL; MMC5 = Cadillac). But because "emm-emm-cee" is rhetorically clunky, I default to just saying "mapper", which then forces me to choose between:
1) Saying "Mapper 1/4/5", thus interjecting confusion over where the 4 came from?
2) Saying "Mapper 1/3/5", which flows better but is technically inaccurate.
And what's the matter? Casual users don't care what mapper a ROM is anyway!
3gengames wrote:
And what's the matter? Casual users don't care what mapper a ROM is anyway!
One would certainly think so... But then they go and ask about all that "stuff" on my kitchen counter and I feel obliged to tell them!
Dr. Floppy wrote:
But because "emm-emm-cee" is rhetorically clunky
Nintendo Power magazine didn't think so in the classic article
Why Game Paks Never Forget. It described the progression from NROM to UNROM to the MMCs.
tepples wrote:
Dr. Floppy wrote:
But because "emm-emm-cee" is rhetorically clunky
Nintendo Power magazine didn't think so in the classic article
Why Game Paks Never Forget. It described the progression from NROM to UNROM to the MMCs.
Far be it from me to find fault with my first issue! To the contrary, I was referring strictly to the spoken word. Perhaps "audibly clunky" would've been a better parsing of the vernacular?
Bregalad wrote:
It's exactly how are SNES emulators able to emulate the Super FX and SA-1 when the only doccumentation about those is the emulators source code... argh.
http://en.wikibooks.org/wiki/Super_NES_ ... X_tutorial
Back in the day, it was a lot of guessing and reverse engineering work. IIRC there was some information on the processor at the time - although I can't find it anymore. For the longest time, it didn't work at all.
6T4 wrote:
The following mapper numbers are those that I am NOT familiar with any game using; I have some information about all the others from 0-255: 28, 29, 30, 31, 35, 39, 54, 55, 59, 63, 81, 98, 102, 104, 109, 110, 123, 124, 125, 126, 127, 128, 129, 130, 131, 135, 144, 153, 154, 155, 157, 158, 162, 166, 170, 174, 179, 181, 190, 192, 194, 195, 199, 207, 208, 218, 223, 224, 236, 237, 247.
I overlooked a few that I do have information for. I have information for mappers 81, 154, 192, 194, and 207. So that's 210 in total out of the possible 256 that I have at least some information about (although in a few cases, this may only be what game uses the mapper). If anybody knows anything about any of the other 46 that I listed, let me know.
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
Raiden the Quick wrote:
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.
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.
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.
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.
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.
MottZilla wrote:
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.