Talk:MMC1

SOROM, SUROM, and SXROM

I'm a little fuzzy about why these are considered different NES 2.0 submappers. The functionality of all three of these looks the same to me if the extra banking bits become useless/mirror when the ROM/RAM addressed is a smaller size (just like in any other mapper supporting various sizes).

43210
+---+
PSSxC

4:P - A18 of 512k PRG ROM, disconnected if smaller
3:S - A13 of 16k PRG RAM, disconnected if smaller
2:S - A14 of 32k PRG RAM, disconnected if smaller
1:x - unused
0:C - 4k CHR banking control

What am I missing? I can't spot the incompatibility that necessitated three submappers. Isn't this just one mapper together? - Rainwarrior (talk) 00:58, 8 August 2015 (MDT)

Just my $2, but I fully agree with Rainwarrior.Bregalad (talk) 02:28, 9 August 2015 (MDT)

Yeah, tepples confirmed it in a discussion elsewhere (and lidnariq seemed to confirm it in an oblique way?). I've already put this information to use in the description at NES 2.0 submappers#001: MMC1 anyway. - Rainwarrior (talk) 11:58, 9 August 2015 (MDT)

The only issue I see is that people seem to like thinking of the two PRG-RAM banking bits in order, which would pose a problem if exchanging SXROM save RAM images is desired. On the other hand, this is a much more elegant way to handle it, so it sgtm. —Lidnariq (talk) 00:09, 10 August 2015 (MDT)

Actually, thinking about this for a moment, this is a far better explanation of why I think we don't need a submapper for SUROM/SXROM/SOROM, by parsing the bits as follows:

43210
+---+
EDCBA

4:E - CHR A16, if extant; PRG ROM A18, if extant
3:D - CHR A15, if extant; PRG RAM A13, if extant
2:C - CHR A14, if extant; PRG RAM A14, if extant
1:B - CHR A13, if extant
0:A - CHR A12

—Lidnariq (talk) 12:39, 11 August 2015 (MDT)

SXROM Heuristics

Should the section on SOROM/SUROM/SXROM be modified because the amount of PRG-ROM in SXROM need not be "large", as shown with Dezaemon (128K)? Great Hierophant (talk) 19:41, 1 Oct 2018 (MDT)

Yes, it should. Actually this entire paragraph is wrong, because determining SUROM from other MMC1-based configuration is not problematic; just using the good old iNES header marked with 32 "16kb PRG-ROM banks" is enough to detect SUROM; there is nothing problematic. The only problematic thing is accounting for larger RAM (16k or 32k; SOROM or SXROM) because in the original iNES header there's no way to indicate a larger RAM. NES 2.0 header solves this, therefore submapper is unnecessary but a NES 2.0 header is necessary. For games using the old iNES header, the only choice is to either detect games based on CRC (bad approach) or to assume there's always 32kb if no save file is already present; and write only the banks that were actually used to the save file.

Bregalad (talk) 00:42, 2 October 2018 (MDT)

The only place the distinction matters is the recommendation of emulating SNROM-style PRG RAM protection with small PRG and CHR. The only other place large PRG matters is for allowing the same bit to control selecting between 256 KiB outer banks, which is a no-op if there aren't multiple 256 KiB outer banks. —Lidnariq (talk) 00:54, 2 October 2018 (MDT)

I completely forgot about SNROM-style PRG RAM protection. I still think it should be handled individually, i.e. if PRG-ROM < 256k and CHR-RAM is used then this protection is activated, this does not require heuristics nor a NES 2.0 header.Bregalad (talk) 01:20, 2 October 2018 (MDT)