Submappers for VRC7, Bandai FCG, GNROM?

If the goal for the VRC2 and VRC4 submappers was that emulators should not respond to address lines to which the original hardware did not respond, then there need to be at least two more submappers for consistency:

Mapper 85.0: Konami VRC7a/b: ASIC An pin connected to both CPU A3 and CPU A4 (0x18), in other words, "unknown", the default behavior
Mapper 85.1: Konami VRC7b: ASIC An connected to CPU A3 (0x08)
Mapper 85.2: Konami VRC7a: ASIC An connected to CPU A4 (0x10)

Mapper 16.0: Bandai FCG-1/2 or LZ93D50: Mapper responds in the $6000-$FFFF range, may or may not support 256 byte EPROM (denoted by NES 2.0 PRG-NVRAM field), IRQ counter may or may not be latched.
Mapper 16.4: Bandai FCG-1/2: Mapper responds only in the $6000-$7FFF range, no EPROM support, IRQ counter is not latched.
Mapper 16.5: Bandai LZ93D50: Mapper responds only in the $8000-$FFFF range, support for 256 byte EPROM (denoted by NES 2.0 PRG-NVRAM field), IRQ counter is latched.
Note that these are different from kevtris' old proposal that merely disambiguated the save data size and is rightfully deprecated, but did not distinguish the ASIC type.

Also, I noticed that among the discrete mappers, ANROM, UxROM and CNROM have bus-conflict-disambiguating submappers, but not MHROM/GNROM. Was this an oversight, or on purpose because there are supposed to have been bus-conflict-avoiding UxROM and CNROM boards (though I don't know any) but no bus-conflict-avoiding MHROM/GNROM board?

Edit: Mapper 16 proposal modified to not collide with previous deprecated proposal.

Yes, discrete logic mappers were only allocated variations as we found they existed.

Submappers were allocated for VRC2/4 because the conflation actually exposed bugs in the lumped emulation (such as Wai Wai World relying on not have 1-screen mirroring, or ... whatever the game is that incorrectly starts writing to the wrong register set during the credits).

But as far as we know, there's no emulation failures due to lumping the two PCB layouts for VRC7.

On the other hand, the difference in IRQ behavior on the Bandai FCG series definitely does warrant something. Unfortunately, kevtris already allocated some redundancy here and has separately made it clear that he's not interested in being told his allocations were redundant.

I wonder which games used UxROM/CNROM without bus conflicts. The wiki previously mentioned Colorful Dragon as CNROM without bus conflicts, but that one turned out to be a mapper hack, as confirmed by redumps of the original Sachen cartridge and of a Game Doctor FDS disk that matched the Mapper 3 ROM in its PRG/overdumped CHR data. Camerica games are basically UNROM without bus conflicts, but those go as Mapper 71 anyway.I'd still like to allocate it for consistency as well as neatness and exactness of emulation.Do we need to take that older proposal into account? Has any emulator implemented it? I suppose I could change the new submapper numbers to ones not used by that older proposal.

The only games we have confirmed that have issues with bus conflict are Cybernoid and Donkey Kong Official Edition. The former requires bitwise AND of CPU value and ROM value to function properly after changing from music to sound effects or vice versa, the latter requires the absence of bus conflicts to work without graphics glitches. Both ROMs can be patched to avoid these issues. Officially both games use Mapper 3/CNROM, which canonically does not have bus conflict prevention hardware. Other games either account for bus conflicts or use hardware which accounts for them.

Here are test ROMs for the proposed submappers to mappers 16 and 85. The mapper 16 test ROM only tests the address range of the CHR register; it does not test whether the IRQ counter is latched or not, and does not test the EPROM size (i.e. not the deprecated submappers).

As I am preparing my edits for the Bandai FCG submappers, I noticed that the submapper proposal page lists:

• 0: iNES Mapper 153 (SRAM)
• 1: iNES Mapper 157 (Datach)
• 2: iNES Mapper 159 (128B EEPROM)
• 3: "Normal" iNES Mapper 016 behavior. (256B or no EEPROM)

while the linked submapper.txt file lists:If the submapper table is to include the deprecated submappers, I need to know which version of the deprecated submapper proposal to use. The one on the submapper proposal page seems to get it backwards by putting the default behavior not on submapper #0, but on #3. Which means that deprecating the proposed submapper #0 becomes a bit awkward, because I will of course put the default behavior (combined FCG-1/2 and LZ93D50) at submapper #0.

The version that had submappers for mappers 153/157/159 is also from kevtris. I assume he deprecated and replaced the duplicate assignments.

I meant the reverse order on the wiki. What is listed as submapper #3 should be #0, #2 should be #1, #1 should be #2, and #0 should be #3, for it to make sense.

I swear that when I edited that onto the wiki, the copy of kevtris's submapper definitions defined submapper 0 as equivalent mapper 153, unlike what it says now.

Since I foolishly didn't record at the time whatever reference I was using... <shrug of defeat>

Nevermind that his comment about "512 bytes" is nonsense :/

Still makes no sense, because submapper 0 is supposed to denote standard mapper 016 behavior.

I have implemented my changes in the wiki, both for mapper 16/153/157/159 and 085. I duplicated the register information that is common among16/153/157/159, because having to mentally disambiguate four mappers and two submappers in a single entry would make the article unreadable.

Separating the two VRC7 configurations is still the right thing to do, to be congruent with the other VRCs, to describe the hardware more accurately, to provide a valid homebrew testing environment, and to not assume that one of the games might not, as one of the Goemon games does, set the other address line at some late point in the game.

Oh, and in my emulation of mapper 157, I have to OR the outputs of both EEPROMs, not AND, for Battle Rush to successfully read the external EEPROM's data.

The game has active I²C communication going on between both EEPROMs at the same time?

No, the I²C EEPROM implementation from stock Nintendulator just doesn't implement the open drain characteristic right, setting the line to 0 instead of 1 outside of transfer. That should be easy enough to modify.

Ah! Well, that would do it.

I was going to ask why the Datach would implement two EEPROM I²C communication with two clock lines instead of setting up each EEPROM with different A0-A2 pin settings, until I saw that the 24C01 has no A0-A2 pins.

All right, that did it. It took me a few minutes figure out why simply returning 1 instead of 0 outside the transfer would freeze the games, until I noticed that the original emulation did not return 0 during the ACK phase either. This did not matter before when 0 was always returned outside the transfer phase, but now it does.