VRC2/VRC4 submapper hell

Is this the right board for iNES 2.0 submapper proposal discussion? If it isn't, please move this topic to a more suitable board.

The consensus (?) proposal for submappers for iNES mappers 21/23/25 is as follows:



However, this encoding (specifically, the use of the high bit) is redundant with the existing mapper numbers. All games that have the two register-selecting address lines in natural order (i.e. the registers that set the low and high nybble of the same CHR bank are adjacent to each other) use mapper 21 or 23, and all games with the lines in reversed order use mapper 25. Since the mapper number consistently indicates what order the lines are in, there's no need to use a bit in the submapper field to specify it again.

According to the wiki page for iNES 2.0 submappers, "test ROMs" are needed before a proposal can be accepted. How exactly are these test ROMs supposed to work? I can hack up a VRC2/VRC4 test program that'll test a cartridge (or an emulator implementation) and report which address bits are connected to which lines on the mapper (including multiple bits ORed together), whether 1-screen mirroring is supported (VRC2/VRC4 difference), and whether IRQs are supported (another VRC2/VRC4 difference) if that's what the community is looking for.

As an aside, can someone explain exactly what this sentence (from the wiki VRC2 article) is supposed to mean?



Seriously, what the hell is it supposed to mean that a game is "canonically emulated" using a chip that's different from the one on the cartridge? This kind of nonsense makes me want to run screaming from the NESdev community.

ETA: Also, the fact that the ending in Ganbare Goemon Gaiden sets the CHR banks wrong on a real cartridge should probably be referenced somewhere on the wiki so emulator developers don't chase spurious bugs.

I kind of messed that one up. I made it so general (effectively a barrel shifter) because I wasn't quite confident that the community had discovered and dumped the entire library of VRC-using games. And I made it before the "'test ROMs' are needed before a proposal can be accepted" era, instead in the "run it past kevtris in #nesdev on EFnet and see what he calls plausible" era.

Things that don't work in actual NES and Famicom games go in Game bugs.

For reasons of modern sloppiness and historical something, Ganbare Goemon Gaiden has a VRC2, doesn't set the mirroring control register to a value other than 0 or 1, and has extra hardware to keep the VRC2's microwire port from conflicting with the RAM that's on board.

Because the combination of both our documentation and time spent looking closely at the boards is very slow, the specific instance of "Wait a moment, that board doesn't use the VRC4 despite having RAM" has produced the above text.

Remember that every single VRC2 game is "canonically emulated" as running on a VRC4 with RAM by 99% of emulators. This is only something we've even begun to try to set right in recent memory.

I don't think there's consensus behind that assignment. I proposed this one instead, but nobody has commented:
https://wiki.nesdev.com/w/index.php/NES_2.0_submappers/Proposals#Alternative_Submapper_Assignment

I do not like the mapping tepples proposed because it:

• Allocates all 16 submappers for no reason. Each of these mappers only has 2 address variations.
• Aside from the 2 current known variants, the rest of the submapper allocations are meaningless because they're already assigned to other mappers anyway.
• Does not encode VRC2 vs VRC4.
• If any unknown variants exist we've shot ourselves in the foot by using up all the allocations.
• Etc.

The only reason I didn't outright delete that proposal was that nobody else seemed to care, so there was no comment for consensus.

My proposal instead was organized with only known variations:

• 021: 1 VRC4a (A2, A1)
• 021: 2 VRC4c (A7, A6)
• 021: 3 unseen VRC2 (A2, A1)
• 021: 4 unseen VRC2 (A7, A6)
• 023: 1 VRC4f (A1, A0)
• 023: 2 VRC4e (A3, A2)
• 023: 3 VRC2b (A1, A0)
• 023: 4 unseen VRC2 (A3, A2)
• 025: 1 VRC4b (A0, A1)
• 025: 2 VRC4d (A2, A3)
• 025: 3 VRC2c (A0, A1)
• 025: 4 unseen VRC2 (A2, A3)

The ones marked "unseen" can be omitted, as there's no known cases. They're just to show there's actually a convenient symmetry to them (not necessary to preserve, IMO). The symmetry is:

• 0. iNES 1 behavior (VRC4 + both addressings)
• 1. Lower address VRC4
• 2. Higher address VRC4
• 3. Lower address VRC2
• 4. Higher address VRC2

If there's yet another variation that's not covered I think just add it to the end of the list.

"Canonically" is a weird word to use but the meaning is that most emulators treat everything as VRC4.


I put the "test ROM" requirement in because the submappers page was full of half baked crap that was either untestable or otherwise unimplementable. A test ROM for this should:

• Determine which of the 2 (or 6, or 16) address line mappings the cartridge it is using has. Since emulators generally support two addressings at once it should report both if true.
• Determine whether VRC2 or VRC4 is present.
• Optionally: test each of the VRC2/4 features to make sure they're emulated correctly.

Once you've created the ROM, just make one copy for each submapper and change the header for each.

Anyhow, that's it, basically. Once you have a test ROM it's very easy for someone to implement the submappers in an emualtor and test them. It becomes clear that you've implemented it correctly only with such a ROM. You can't just run, some VRC2 game and see if implementing the submapper makes a difference because there isn't one. It really does need its own test ROM.

A VRC2/4 test ROM has been on my to do list for a long time, but given the lack of general interest in it, I've put it off. If you want to write one that's great.



kevtris never seemed to care if the VRC2/4 mappers got submappers. I don't think there's any known compatibility issues, this is an accuaracy issue only.

There's some pedantry about whether these two count as compatibility:
* The workaround for the bug exposed by emulating Wai Wai World as VRC4, and
* The bug in the credits of Ganbare Goemon Gaiden would produce a different set of wrong tiles if restricted to just the actual VRC2 board it's on instead of the combined VRC2/4 mapper that it's emulated as.

The point I was making was that test ROMs will test your implementation a lot better/faster.

...but yes, I'd expect there to be some obscure differences in existing games. I was just unaware of any known ones, so thanks for finding some.

As to whether to classify something as compatibility or accuracy, I don't think these are binary terms. There is a grey area poorly defined between them.

By the way, the wiki's current organization of stuff on these mappers is horrible. Here's the relevant pages in case someone wants to go on an expedition:

• VRC2
• VRC4
• iNES mapper 021
• iNES mapper 022
• iNES mapper 023
• iNES mapper 025
• iNES mapper 027

(These should probably be merged into one page. I was planning to, but lack of interest made it not a priority.)

Edit: Never mind, I've now merged them into: VRC2 and VRC4

For what it's worth, Mesen uses its internal game DB to assign submapper numbers when needed (based on board name, etc.) and currently assigns the VRC2/4 submappers based on rainwarrior's proposal, since they made more sense to me (and no test roms existed for VRC2/4 submappers)

There are a handful of Japanese MMC3 Konami games (e.g. F-1 Sensation and the Japanese versions of a bunch of US games) without bootgod-verified dumps. How confident are we that those games really are MMC3 and the dumps floating around aren't mapper hacks?

I can't comment on whether those games might be secretly VRC2/4 games, but the original submapper proposal doesn't help even if they are. Mappers 21/23/25 support exactly TWO address schemes each-- if there is an undiscovered addressing scheme it will go in a new mapper, not a submapper.

Well, I'd prefer putting them in the same, but I suppose if we're going to keep supporting iNES over NES2.0 for some reason, it'd be necessary…

The situation can become even worse if the emulator tries to support the many VRCx hacks that are floating around, like this, this, and this!

If the pirate clone is "compatible" with existing mapper 21, 22, 23, 25 it's fine to put them there, and also fine to propose a submapper to account for its minute/accuracy-oriented differences. That's what submappers are for: to add refined disambiguation to mappers that were otherwise "mostly fine" combined into one iNES mapper before.

This is also why I thought it was a terrible idea to pre-emptively allocate all 16 submappers-- there is potentially other stuff still in these categories, besides the 2 or 3 already known cases. It was allocating every single combination of addressings even though the underlying iNES mapper could only support at most four, and very much should not be trying to support more than the two they already have, which was too many to begin with (but we're stuck with).

What I am opposed to is adding additional incompatible addressings to 21, 22, 23, 25, making them even more muddled than they already are. The iNES implementation of 21 is a "two-in-one"... don't modify the iNES mapper to make a "four-in-one". If you find a new VRC2/4 addressing, create a new mapper: it doesn't fit into any existing ones.

(Though, this is all moot until someone finds and adequately describes something new in this category anyway.)

Just saying I'd've allocated VRC2 to one and its addressings to subs, but…well, backwards compatibility hobble.

Besides, if a new dump requires submapper support, then wouldn't that pressure emulator authors to implement it?

Those bootlegs are all using a VRC2 clone with one-screen mirroring and/or IRQ functionality (different from and incompatible with VRC4 IRQs) added via additional hardware. I thought that bootleg mappers with similar but incompatible behaviour to a licensed publisher's mapper get their own full mapper number, not a submapper (e.g. the countless multicart-MMC3 variants)

If a submapper is required for it to function then it's already iNES 2, so... if you're allocating a new mapper at 256+ I see nothing wrong with using "submappers" to cram 16 mappers into one mapper, if you really want to do that... though again, quite moot at this point.

For the iNES 1 mapper plane of 0-255, though, I don't think it's a good idea. Preserve their existing function, and use submappers to refine it. If you're going to add new mappers to 0-255 we should try to make sure they're at least compatibly implementable as a single mapper without submappers. I.e. if the mapper can't be implemented in iNES 1, don't stick it in the iNES 1 plane.


If it's incompatible: yes, it needs a new mapper.

Looking at the user's perspective, with exception of the unique games that works only with hacked mappers, to add these hacks don't seem a big deal, specially if the original game is already working fine.

On the developer's side, I think it's a different history.
I think making pirate games' mapper to work on your own emulator is kind of solving a riddle.
The satisfaction of the accomplishment is probably great.

What's the opinion of you guys about this?

You can't implement two different incompatible IRQ systems in the same mapper, though. How do you determine which one to use for a particular ROM? You need either a ROM hash list, which completely defeats the ability to run modified, newly discovered or newly developed software, or you need some kind of runtime heuristic, which still plays havoc with new software and particularly with test ROMs (which not only have to conform to the hardware but to the emulator's heuristics)