How to tell diff between MMC1A, MMC1B, MMC1C, etc etc

How to tell diff between MMC1A, MMC1B, MMC1C, etc etc
by jwdonal on 2010-05-29 (#62058)

Got this from the NesDev wiki:

Quote:

At least 6 different versions of the MMC1 are known to exist: MMC1, MMC1A, MMC1B1, MMC1B2, MMC1B3, and MMC1C. The known differences are as follows:

MMC1A: PRG RAM is always enabled
MMC1B: PRG RAM is enabled by default.
MMC1C: PRG RAM is disabled by default.

My only real concern here is MMC1A in which the PRG RAM can _not_ be disabled. I can totally see some game writing a 1 to bit 4 of the PRG register because the programmer believes that the PRG RAM can never be disabled anyway.

Is there any way at all (outside of CRC/hash) that I can tell if the cart is a MMC1A cart, so that I know not to allow the user to ever disable the PRG RAM when they're not supposed to?

Thanks!

Jonathon

by Zepper on 2010-05-29 (#62062)

- I don't know any known games that would use a copy protection (example) about the PRG RAM state, of I/O. Well, for my best, basically:

a) always enabled: you catch reads/writes from/to $6000-$7FFF.
b) enabled or disabled by default: there's a write to a certain register $8xxx-$Fxxx that changes a certain bit that controls PRG RAM state.

by blargg on 2010-05-29 (#62063)

MMC1 boards can also wire the 8K SRAM's other chip enable to one of the CHR address lines, usually CHR A16. I don't think there's any way to determine which board wiring/MMC revision is used by the iNES header alone, one reason that iNES 2.0 was attempted. Emulators just try to choose a set of behaviors that work for most games they know of, or use a database of known games. Neither is a good solution.

how about this?
by jwdonal on 2010-05-29 (#62068)

What if I just leave the WRAM enabled permanently?? Is that a major "no-no"? Why did they even make this bit anyway?

by blargg on 2010-05-29 (#62070)

Enabled WRAM opens the possibility of corruption of saved games, due to powering on and off, errant writes by NES when powering up and down, or errant writes by the game program itself. Note how the MMC5 devotes two registers to WRAM enable, with different values that must be written to each, to lessen the chance of it getting enabled even if the CPU goes wild.

by jwdonal on 2010-05-29 (#62071)

blargg wrote:
Enabled WRAM opens the possibility of corruption of saved games, due to powering on and off, errant writes by NES when powering up and down, or errant writes by the game program itself.

Ah, gotchya. Thanks Blargg!

blargg wrote:
Note how the MMC5 devotes two registers to WRAM enable, with different values that must be written to each, to lessen the chance of it getting enabled even if the CPU goes wild.

I have not looked into Mapper 5 in any detail yet, but that is _really_ cool!!

Thanks!

Jonathon

by tepples on 2010-05-30 (#62100)

blargg wrote:
Enabled WRAM opens the possibility of corruption of saved games, due to [...] writes

Then why does it only read-enable WRAM while WRAM is write-enabled?

by blargg on 2010-05-30 (#62101)

Because the SRAM can corrupt bytes if it's put into low-power retention mode improperly (note that the MMC1's main SRAM enable line uses CE2, which is active-high, while that timing diagram shows /CE1, which is active low). It doesn't matter whether it's being read or written. Keeping it unselected except when saving/loading a game reduces chances of this. Some later MMCs do allow read-only access, presumably because they improved the controller or found that the benefits outweighed the drawbacks.

by Zepper on 2010-05-30 (#62141)

- Well, you could provide a manual switcher perhaps..?