Mapper 4 as MMC3+MMC6

I can find documentation on the MMC3 or MMC6 separately, but I think the wiki could use a bit of information/recommendation on how to implement mapper 4.

I've noticed that FCEUX, and loopy's PowerPak mapper 4 both seem to support StarTropics just fine without a CRC. Does this mean there is a "safe" way to implement both MMC3 and MMC6 as mapper 4 without negative consequences from any of the old games? Are there drawbacks/incompatibilities to this approach that I haven't noticed? If there is no drawback, what justifies Nestopia's CRC requirement for MMC6?

Obviously, if you want to homebrew for MMC3 or MMC6 it's important to have an emulator that supports all relevant features of the chip, not just the stuff needed to play old games, but at least homebrewers have a lot of options available for this (e.g. iNES 2 headers).

Anyhow, what I'm suggesting is that if there's a "good practice" version of mapper 4 that covers normal use cases and doesn't seem to have drawbacks for non-developers, we should probably have a recommendation on how to do this on the wiki.

As I understand it, it was discovered that simply failing to implement the protection register doesn't seem to trip up any games, and because of how emulators and the powerpak handle saving the emulated NVRAM, they won't have any memory corruption (unlike on actual hardware, which has to deal with glitchy writes during brownout).

q.v. viewtopic.php?t=10535

There are four strategies to support both MMC3 and MMC6:

• NES 2.0-ignorant: Don't emulate the PRG RAM protect bits. This breaks Low G Man, which expects $6000-$7FFF to be open bus.
• Hash: Emulate the PRG RAM protect bits. Use a hash function to detect when a good dump of StarTropics or Zoda's Revenge: StarTropics 2 (a game-length Tetris commercial) is being played. Hacks of the StarTropics game will fail.
• Heuristic: Emulate the PRG RAM protect bits. Use heuristics to determine whether a StarTropics game or a hack thereof is being played.
• NES 2.0: Emulate the PRG RAM protect bits. If the size of battery-backed PRG RAM is 1024 bytes, emulate them for MMC6.

A combination of NES 2.0 and Hash is probably the best way forward for new implementations of iNES mapper 4.

So, from what I am hearing, the "solution" is to not implement write-protection and give the mapper 8k of RAM regardless. It sounds like the viability of this relies on two premises:

1. Extant MMC3 and MMC6 games do not use write protect to block writes from software, it was only used to prevent data corruption during power-off / reset etc.

2. Extant MMC6 only use their 1k of RAM as a strict subset of 8k of RAM, and don't rely on aliased read/write operations.


The next question is: are any games known to break these premises?

EDIT: Tepples has suggested Low-G Man. How does it rely on an open bus?

The music engine in Low G Man reads from $6000-$7FFF and expects the value to equal the previous byte on the data bus, which is the high byte of the address.* For example, lda $6543 will produce AD 43 65 on the data bus, after which $65 is held through bus capacitance. Google "low g man" open bus site:nesdev.com for more.

* For indexed modes that cross pages (a,X, a,Y, and (d),Y), the high byte of the base address is used, not the final address after X or Y is added.

Good lord, that's bizarre!

(obvious split point, if desired)
Do we know when/where Low G Man does this? Looking for '[\xAD\xBD\xA9\xB9].[\x41-\x7f]' only finds one thing when neither surrounded by invalid opcodes nor frameshifted...

PRG offset 0x17D31: lda $7FA5,x

Obviously it could be using indirect addressing, or something copied to RAM... but I briefly ran it in nintendulator and fceux with a breakpoint set to read/writes from $4020-$7fff and never got that to trip.

It's through an indirect, lidnariq, info here: http://forums.nesdev.com/viewtopic.php?p=4895#p4895

I created a note about this on the wiki. Please advise if I've missed something:
http://wiki.nesdev.com/w/index.php/INES_Mapper_004