StarTropics broken due to mapper issues

[emkultra64]

StarTropics uses MMC6; when the mapper is not detected correctly, music will not play, the name registration screen will not function and the file select will usually display garbage data (if any at all.) Currently the MiSTer NES core does not detect the mapper correctly, resulting in these issues.

The most effective workaround is to apply this patch to the ROM to change the header and force use of MMC6.

[SegaSnatcher]

This has been brought up before. Its advised to just use a 2.0 Header with sub mapper 1.

#33

[emkultra64]

This has been brought up before. Its advised to just use a 2.0 Header with sub mapper 1.

#33

It's easy enough to work around, yeah, but there are cycle-accurate emulators, FPGA implementations and flash carts that are able to use the older dump and still run the game correctly, even on real hardware, so it's a sign that something might be up with mapper detection and/or implementation.

[SegaSnatcher]

That is because MiSTer doesn't have a Mapper database like emulators.

Rysha who has helped with improving the NES core doesn't like the idea of a Mapper Database, she just advises people to change the headers.

Best advise is to find a rom pack with all correct 1.0 and 2.0 headers if you don't want to have to change the headers yourself.

[paulb-nl]

Those ROM databases are one of the reasons why there are still ROMs with incorrect mapper settings.

Flash carts use inaccurate emulation so that Startropics works on their MMC3 mapper.

[emkultra64]

Rysha who has helped with improving the NES core doesn't like the idea of a Mapper Database, she just advises people to change the headers.

Ahh, okay, so it's a design decision. Understandable.

Those ROM databases are one of the reasons why there are still ROMs with incorrect mapper settings.

Flash carts use inaccurate emulation so that Startropics works on their MMC3 mapper.

So if I'm understanding this correctly, the main reason we still have ROMs with mappers being incorrectly assigned is because most projects are keeping SHA1 or CRC32 sums in databases to detect those specific versions of the ROMs and ignore their headers, instead assigning the correct mappers? Have projects basically been enabling bad headers by working around them?

[emkultra64]

Closing this now, as the issue has been made clear to me and it has nothing to do with the core. It's incorrect ROM headers being worked around in emulators and flash carts rather than those systems reading the data as-is. This is including my copy of StarTropics, which was taken from my NES Classic Edition. The ROM file for StarTropics on the NES Classic is the same one most people find in ROM sets, and it has an incorrect header.

[paulb-nl]

Yeah for example Mesen uses its own internal database when loading roms. You can open the log window to see what mapper it chose. It is handy for easily checking which mapper it should be though.

[bbbradsmith]

If you want a solution that is both correct and easier for users than teaching them to update headers:

iNES 1 headers weren't incorrect, just underspecified. If you want a solution that works with both correct iNES 2 headers and old iNES 1 headers, you can do the following:

1. If iNES 2 use the submapper to select the specific behaviour.
2. If iNES 1 use MM3C implementation but without the PRG-RAM write protect.

This is the compatible solution that had been used by emulators and flash carts for years before we had an iNES 2 submapper for it (finally specified in late 2015). No games rely on the write protect feature being present, its only real application was for protecting battery saves on actual hardware carts (which isn't an issue for MiSTer). Mostly the reason emulators have it is for "just in case" levels of accuracy, or homebrew development verification.

That would make it easier for users with the commonly found Startropcs/Startropics 2 ROMS with iNES 1 headers.

Low-G-Man is a less popular MMC3 game that sometimes comes up as a related issue. It has a bug in the game that accidentally relies on a lack of WRAM. The symptoms of this could potentially interact with write protect, which can sometimes hide the problem. For that one the only "correct" way is the iNES 2 header which allows a WRAM size of 0 to be specified. (Alternatively, I made a patch for emulators/systems without iNES 2 capability at that time.)