MMC5 SRAM on PowerPak

w7n on the FamiTracker users' Discord server claims that an emulator has an undesirable design decision because it does not assume 64K SRAM for MMC5 ROMs with unknown CRC. I countered that this assumption would be incompatible with a PowerPak, which has 32K SRAM.

How do the available MMC5 mappers decide SRAM size? Would I need to port my FME-7 RAM size test to MMC5 to try it myself?


EDIT: Reporter was confused as to which emulator had the problem. Made generic.

Quoting my words to clear up some misunderstanding:

Rather than defective, I should say it's a relatively bad choice.
For a ROM author though, it can be worked around (with NES 2.0). The thing is some people would choose not to use NES 2.0 to make ROMs compatible with other old emulators that are still popular. In this particular case though, MMC5 SRAM size is not well-supported on them either, but some do.

Also, my point was not actually about 64K vs 32K, it's about 64K vs 8K. Emulators like puNES (and a lot others) would default to 8K for non-commercial ROMs, and some of them don't even support NES 2.0.

Since no commercial MMC5 game had more than 32 KiB total RAM, and no games use bank mirrors, calculating the address as [A14, A13 OR A15] is adequate.

edit: The entire point of NES2.0 is that it's upwards compatible from iNES1. There is literally no reason to avoid a NES2.0 header: if it could be emulated with a iNES1 header it will still work despite having a NES2.0 header.

I was going to say that some emulators respond to NES2.0 headers by saying "Oh, this looks like it was DiskDude-corrupted, I'd better discard everything in the 8th byte (the upper 4 bits of the mapper number)", but I just realized that those don't actually matter because the MMC5 uses mapper 5 and would thus be unaffected (and said emulators are unlikely to have proper MMC5 support anyways).

If there are MMC5-supporting emulators that are outright intolerant of NES2.0 headers, you should probably contact their authors and get them to fix it.

Just being pedantic, the PowerPak will refuse to load any ROM with a nonzero last header byte... which happens to be where we seem to have put the preferred controller value. But even in cases like that, there's nothing preventing anyone from just hex editing a file to take the 2.0 parts off of the header.

Implemented (https://github.com/punesemu/puNES/commit/ac0ea4891ee7013d5135a8ebbd4c103cb6b3df04), thanks for making pointed.