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