nesdev.org

I've always wondered why m185 games, which are also CNROM, are able to disable VROM, and even more so, the fact they all use different values to do it. So I broke down and bought a few of them to see if I could figure anything out.

As I expected, the HVC-CNROM boards are the same as the NES-CNROM boards, except they don't have the CIC stuff of course. Any CNROM game could have made use of this "feature" if they wanted too. The LS161 uses not only D0 and D1, but also D4 and D5. Which, if used, connect to CHR A12 and CHR A10 respectively.

Here's a pic of a NES-CNROM board. As you can see, the traces for the 2 lines are not connected.



Anyways, mapper 185 games actually do use this, and the values they use are different because they use different diode configurations as a "key" so to speak.

Here are the carts I have:

Mighty Bomb Jack


B-Wings


Sansuu 2 Nen


Bird Week


Notice that Bird Week does not have diodes installed, so it technically can't do this technique, but it still checks to make sure it's not mirrored into bank 0, and thus locks if it is.

Personally, I think m185 should be done away with, it's basically a hack anyways. There are 2 ways I can think of to do so.

First way would require no changes in emulation, but IMO it's still a hack way to do it. Basically these games fail normally because they check a cetrain bank, usually 0, to make sure data isn't mirrored there. So to avoid this, the CHR ROM of the dump could simply be padded with dummy data and only have the real data in the bank it expects.

The second, better way, would be to have emulators not mirror the CHR data for CNROM carts, but fill unused banks with either typical open bus noise: 01,02,03...FF repeated thoughout like you'd get on the real thing, or you could just fill them with FF. It really doesn't matter what is in the unused banks as long as it's not a mirror of the real data. This way however would require that the emulator know which bank it needs to load into. Since the NES 2.0 spec is still on the table, I think a couple of bits should be added for this purpose.

Actually, it'd be nice if the NES 2.0 spec had some space allocated to context sensitive info like this rather than having the bits taken up no matter what.

Back to the diode thing, emulators really don't need to know the config of these as long as they map the memory out like above. You do need to set D4 and D5 properly when dumping them though.

Probably simpler yet would be to have NES 2.0 indicate the setup of the diodes (having 5 possibilities in all), then emulate the mapper accordingly.

One thing you should also note is that the solder pad in the upper-right corner is filled on Bird Week (pulling some signal to GND) but unconnected on the others - this is probably why it can disable the ROM even without the diodes.

I think these games should still use mapper 185, as that's what they've been using all along AFAIK. An emulator would see mapper 3 as "no CHR disable" and mapper 185 as "CHR disable." As I recall, NES 2.0 has a sub-mapper field that can be used to select which banks should be deemed invalid.

Quietust wrote:One thing you should also note is that the solder pad in the upper-right corner is filled on Bird Week (pulling some signal to GND) but unconnected on the others - this is probably why it can disable the ROM even without the diodes.

I noticed that too when I was looking at it, but actually, that only has to do with PRG A14, when the solder pads are in the config bird week is, A14 is tied to +5V. Bird Week is not able to disable CHR ROM like the others, when it writes F0h to disable it, it does nothing.

Quietust wrote:Probably simpler yet would be to have NES 2.0 indicate the setup of the diodes (having 5 possibilities in all), then emulate the mapper accordingly.

You could get away with 4 possibilities I think, if the diodes were in the opposite config of B-Wings, which is what Bird Week would have used according to the values it uses, it is the same as them not being present at all, because the 161 couldn't affect the state of A10 and A12. They really could have gotten away with using 1 diode in the cases where it's 2 opposites as well.

dvdmth wrote:I think these games should still use mapper 185, as that's what they've been using all along AFAIK. An emulator would see mapper 3 as "no CHR disable" and mapper 185 as "CHR disable."

185 is written to work specifically for a few games, if a new one were to come along, it probably wouldn't work. Emulators I've looked at generally just go by this table:

Off On Title
F0h 0Fh Bird Week
00h 33h B-Wings
00h 11h Mighty Bomb Jack
20h 22h Sansuu 1 Nen - Keisan Game
20h 22h Sansuu 2 Nen - Keisan Game
00h FFh Sansuu 3 Nen - Keisan Game
13h 21h Spy vs Spy

Would you mind drawing a schematic of the relevant parts of the board as a reference?

Heh, not exactly sure what your asking for Just drawings of each possible diode setup and what value would be have to be used to enable the CHR ROM? I don't have a schematic drawing program, but I could handle the above in mspaint I suppose, if thats what your looking for

Something to make clear the path of the latched D4 and D5, such as how they connect to the diode pads and how the CHR ROM addresses connect to the pads. I don't understand why diodes are even being used. Why is Sansuu 2 Nen's diode on the right reverse biased?

I'm guessing that biased one way means that 1 disables the ROM, while biased the other way means that 0 disables the ROM.

I think that more or less answers to my question.
I'm still not understanding anything to the behaviour of this. Recent CNROM boards seems to have no slot for diodes, and the only other solder pad aside of mirroring forces A14 of the ROM to GND for games using 16kb PRG I assume. It's marked 'CL1' as MMC5 games, hehe.

Yep that pad is for 16K PRG, it's used to select where it's mapped in, either $8000 (default) or $C000, like Bird Week uses.

I really don't understand how this works from a technical standpoint either. Maybe kevtris could explain it better? I'll try to draw something about how the diodes are used though.

BootGod wrote:Yep that pad is for 16K PRG, it's used to select where it's mapped in, either $8000 (default) or $C000, like Bird Week uses.

16K ROMs aren't mapped, they will appear in BOTH $8000 and $C000 because they are only partially decoded (toggling A14 has no effect on a ROM without A14) so that couldn't be it.

That's true, not sure what the point of that pad is then. In it's default state, it simply connects the PRG ROMs A14 to the cart edge. When it's in the other state, it's not connected to the cart edge, but just tied to +5V. Wouldn't that have the effect of only being able to access $C000 - $FFFF?

What is A14 defined as on a 16K chip anyways?

BootGod wrote:That's true, not sure what the point of that pad is then. In it's default state, it simply connects the PRG ROMs A14 to the cart edge. When it's in the other state, it's not connected to the cart edge, but just tied to +5V. Wouldn't that have the effect of only being able to access $C000 - $FFFF?

What is A14 defined as on a 16K chip anyways?

It looks like the actual intent is for handling 16K games stored in 32K ROMs (so they wouldn't have to make a CNROM-128 board as well as CNROM-256).

I know that the issue of emulating mapper 185 was discussed a while back on the Nestopia part of R. Bannister's Emuversal Bulletin Board (and somebody came up with some logic that is cleaner than that table), but I'm too lazy to search for it since something screwed up with my account when they changed the forum software. Any ideas?

BootGod wrote: What is A14 defined as on a 16K chip anyways?

N/A? Pin 27 which is A14 on a 27256 is /PGM on a 27128 which should be held high...