ROM expansion annoyances and ROM type validation inflexibility

[PhoenixBound]

For 6 MB EarthBound ROMs, the authoritative header is the one at address 40FFB0, but CoilSnake currently checks the data at file address 00FFB0 to verify whether the ROM it's looking at is an EarthBound ROM. Moreover, it checks a field of the ROM header that some people would like to change (its ROM name, displayed in some emulators like snes9x), and only after compiling CCScript. This makes it difficult to change the ROM header or clean things up.

The 6 MB case is especially important to deal with, because we've had not one but two popular EarthBound romhacks cause problems for people using old versions of snes9x and even certain flashcarts. They were expanded to 6 MB (sometimes out to necessity, sometimes due to early development decisions that carried forward for years), and the exhirom expansion leaves the old unused header data in bank C0. Snes9x's heuristics for determining the ROM format and the correct location of the header used to get confused by this old data and misidentify the ROM format. Clearing out the header data there fixes the problem, but it also makes the ROM no longer be recognized as a valid EarthBound ROM by CoilSnake when compiling a project.

• Make it possible to change things like the name in the ROM header.
• When expanding the ROM, clear out the old unused header data at C0FFB0.

[ShadowOne333]

Which romhacks had issues?
And what issues did this wrong expansion caused on them?

[Supremekirb]

MOTHER 2 Deluxe and Bound to the Dark World (which prompted this discussion in the first place) have had them.

There are no issues on modern emulators unless you do something like turn on Mesen's "Use strict board mapping" setting (which has further complications beyond the ROM header - all saving, for instance).

As Phoenix said, old versions of Snes9x and some flashcarts can suffer from it. One of the issues that's possible to observe is graphical corruption on map tilesets.

[PhoenixBound]

Known issues caused:

• snes9x 1.60 and earlier: game doesn't boot at all (the heuristics were adjusted for 1.61). I can confirm that clearing out the old header data with 00s fixes things in 1.60 and earlier.
• emulators for some other non-mainstream platforms, like snesticle PS2 or the common 3DS SNES emulators: graphics of maps get messed up, presumably because they're what gets stored in the extra 2 megabytes of the ROM at the end or something

These are symptoms of the core issue: emulators guessing the wrong mapping of data in the file to the SNES's CPU memory.

The thing Kirb mentioned, with strict board mappings in Mesen, is a separate issue. Apparently all the ExHiROM PCB boards for commercial games don't map SRAM to banks 20-3F like HiROM boards do, only to banks 80-BF. This causes issues in Mesen with a certain setting labeled "Use strict board mappings (breaks some romhacks) (not recommended)" -- namely, with that setting on, it's impossible to load or copy or delete a save file, even if you manage to bypass the anti-piracy check (which also fails, because interacting with SRAM just doesn't work). Fixing this is probably a lower priority than most things, since emulators and flashcarts seem tolerant of this behavior, and the fix will require changing every SRAM memory address in the game's code to point somewhere else with a different bank.