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:

Code:

3210|||||+++- Which address line corresponds is wired to the A1 in the VRC4a+---- 0: Use next lower address line for VRC4a A2; 1: use next higher line

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?

Quote:

A third variant (similar to VRC2a but with full-width CHR registers and PRG-RAM) is canonically emulated as using the VRC4, and it's assigned to mapper 25.

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.

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.

A third variant (similar to VRC2a but with full-width CHR registers and PRG-RAM) is canonically emulated as using the VRC4, and it's assigned to mapper 25.

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.

Quote:

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.

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.

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.

tepples wrote:

"run it past kevtris in #nesdev on EFnet and see what he calls plausible" era.

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.

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)

I wasn't quite confident that the community had discovered and dumped the entire library of VRC-using games

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 wasn't quite confident that the community had discovered and dumped the entire library of VRC-using games

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.

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.)

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!

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)

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum