Comment by sopooneo

They do, absurdly enough. See for example BSNES, https://news.ycombinator.com/item?id=3675123 , "In order to extract these programs from most of the DSPs, we had to decap the chips, scan them in with an electron microscope, and 'tweak' the processors to allow us to dump their protected program ROMs."

It depends on the system.

If you're talking about an MSX game, then yes. Nothing about the carts are preserved in the ROM images, and you need a per-game database, or you'll need some kind of "cartridge type" list that the user has to choose from when booting the game.

If you're talking about the NES, sort of yes. People stick a fan-made "iNES" header at the top of the ROM data, but they made the format before all the details of the NES were known. So using that information is not enough for many titles, and so you need a database for those titles to work properly.

For the SNES and Genesis, the games have internal headers that tell you most of the details of the games, but not enough for complete emulation. SNES emulators in the past have been able to add bizarre tricks that just so happen to line up with the existing commercial games to not need a database, but it really turns out to be a mini database disguised by being obtuse. Example: "if the ROM is larger than 2MB, and has save RAM data, and has 32K bank granularity, then map the save RAM data to a smaller area of memory." Rather than "if the game is Fire Emblem, treat it differently than Ys 3."

For the Game Boy Advance, emulators and flash cart tools will scan the ROM looking for signatures from code libraries from Nintendo that handle save memory, like "FLASH512_V", "EEPROM_V", "SRAM_V", etc. Developers wised up and started including fake strings to fool them, so once again ... you end up needing a database.

There's very, very few cartridge-based systems where only the ROM dump is all you need. If I had to name one, I'd say the Neo Geo Pocket is one.

There are even cases like Mega Man X (Japan), where they made a mistake with the copy protection, and to fix it, resorted to wiring a resistor right onto the back of the PCB of every cartridge released to change the memory map.

And databases + heuristics fall apart when it comes to homebrew, fan translations, ROM hacks, etc.

True preservation requires games include a detailed description of the entire PCBs of these games, not just the ROM chips. But unfortunately, after trying for 15 years, I've not been able to come up with a stable, simple format for every system in the world that doesn't rely on emulator-specific design decisions.

I mean, how do you represent every possible circuit board configuration on the planet in a text file, that isn't going to make emulator authors for just the NES or just the Game Boy balk?

For example, The iNES format, for NES emulators, has a 16 byte header, not part of the original ROM, that identifies the mapper, screen mirroing if not controlled by the mapper, and whether or not battery backed RAM is included.

NES mapper numbers were standardized among emulator authors. Look for "NES mapper list". Some very early games didn't use a mapper (that's what mapper 0 is).

SNES games do have an intrinsic header that describes the cartridge content. What’s missing has to be guessed through heuristics. bsnes has a file format for describing this stuff in detail, but it’s so far not been very popular because users like things to be self-contained.

That brings up another interesting point. foone says the ROM data dumped would be identical, but that’s disingenuous. The DSP firmware is part of the cartridge, too, and it is clearly different. byuu has proposed catenating the DSP image to the base ROM for this reason. Of course, the Pilotwings case was unique, being the only game to ship with two different DSP firmwares.

Yep. Exactly.