Although Nintendo made many different cartridge circuit boards with different memory mappings, ROMs do not indicate which specific board they are intended to work with. Super Famicom emulators traditionally group mutually-compatible mappings together and use heuristics to guess which family of mappings the game expects.
There's one family of mappings that maps ROM data to the top half ($8000-$FFFF) of memory banks in the Super Famicom address space. For historical reasons, this family is called "LoROM" and has three main variants:
ROM only, mapped to the top half of every possible bank. The boards database calls this "LOROM".
ROM mapped to the top half of every possible bank, RAM mapped to the bottom half of banks 70-7d,f0-ff. The boards database calls this "LOROM-RAM"
ROM mapped to the top half of low-numbered banks, RAM mapped to both halves of banks 70-7d,f0-ff. The boards database calls this "LOROM-RAM#A"
The largest official game that used variant 3 was 1MiB, so a common heuristic is "if the ROM is 2MiB or less, use variant 3, otherwise use variant 2". 2MiB is used as the threshold instead of 1MiB, perhaps so somebody can expand a commercial ROM that uses variant 3 without having to rework it to suit a different mapping.
Since v107 or so, higan (and by extension, bsnes) has implemented variant 3 by mapping ROM to banks 00-3f,80-bf, which exactly fits a 2MiB ROM. However, other emulators like Mesen, snes9x and higan v106 implement it by mapping ROM to banks 00-6f,80-ef, all the space that is left after the RAM is mapped.
This doesn't affect any verified games in the Super Famicom.bml database, since those have specific, accurate memory maps. It also won't affect well-written games that only read from memory addresses they have populated. However, homebrew games and ROM hacks that have never existed on a real circuit board depend on these heuristics across all devices that read Super Famicom ROMs, including software emulators, flash-carts, and FPGA implementations, so bsnes should match what other emulators do.
Although Nintendo made many different cartridge circuit boards with different memory mappings, ROMs do not indicate which specific board they are intended to work with. Super Famicom emulators traditionally group mutually-compatible mappings together and use heuristics to guess which family of mappings the game expects.
There's one family of mappings that maps ROM data to the top half ($8000-$FFFF) of memory banks in the Super Famicom address space. For historical reasons, this family is called "LoROM" and has three main variants:
The largest official game that used variant 3 was 1MiB, so a common heuristic is "if the ROM is 2MiB or less, use variant 3, otherwise use variant 2". 2MiB is used as the threshold instead of 1MiB, perhaps so somebody can expand a commercial ROM that uses variant 3 without having to rework it to suit a different mapping.
Since v107 or so, higan (and by extension, bsnes) has implemented variant 3 by mapping ROM to banks 00-3f,80-bf, which exactly fits a 2MiB ROM. However, other emulators like Mesen, snes9x and higan v106 implement it by mapping ROM to banks 00-6f,80-ef, all the space that is left after the RAM is mapped.
This doesn't affect any verified games in the
Super Famicom.bmldatabase, since those have specific, accurate memory maps. It also won't affect well-written games that only read from memory addresses they have populated. However, homebrew games and ROM hacks that have never existed on a real circuit board depend on these heuristics across all devices that read Super Famicom ROMs, including software emulators, flash-carts, and FPGA implementations, so bsnes should match what other emulators do.Fixes #278.