User talk:Zzo38/Submappers

There's a bunch here that seem unnecessary to me. For example:

• Mapper 1, all of these boards are disambiguated just with the PRG-RAM size register, so why allocate submappers?
  • That said, SEROM and SHROM are not describable using other details, so there's an argument for why they should.
• Mappers 2,3 submappers should probably also apply to 7 and 34
• Mapper 4 MMC3 vs MMC6 can also be disambiguated using the PRG-RAM size register
• I'm not clear why any of the VRC2x/VRC4x/VRC7x layouts need to be disambiguated.
  • That said, using submappers to disambiguate VRC2 from VRC4 is a great idea.
• Mappers 38,79: I think enshrining either behavior as official is a bad idea, especially since Nestopia's implementation is a superset of FCEUX's in both cases. (And FCEUX happens to be on crack with m79's register at $8000)

—Lidnariq 20:13, 10 September 2012 (MDT)

Thanks for your comments. OK, I have listed 7 and 34 under the 2 and 3 heading. For mapper 38 and 79 I have added a comment; hopefully someone who understands better will fix it. I don't know much about the differences of SEROM, SHROM, SOROM, SXROM, SUROM, but at least to me it would make sense that the same mapper/submapper number is used if and only if it makes sense that it is otherwise similar enough other than the PRG-RAM size! For VRC7a/VRC7b, I quote: "VRC7a uses $x010 for regs, and VRC7b uses $x008." I suppose it could be mirrored but doesn't make sense from a hardware perspective (unless, perhaps, you use a OR gate on bit3 and bit4 of the address; which seems strange to me, though). As I have written above, the reason I think MMC3 and MMC6 different numbers, and I quote again: "It is also mapped a bit differently, and is enabled/disabled differently from MMC3." For the VRC4x, registers are mapped differently. Some of these reasons are in case you want to write a homebrew using these mappers with different ROM/RAM amounts (of course, the RAM amounts should always be zero if the mapper does not specify any registers to control it, and in some cases there are simple changes to the registers just using different number of bits so they shouldn't have a different number, but in some cases they really are different other than just the ROM/RAM amounts). At least this is my opinion. You can ask other people working on NES/Famicom to see if they know better; I don't know it that well, and as I wrote in the document, these are only suggestion (subject to change) and not official specifications in any way (this is why it is a subpage of my userpage instead of main namespace). --Zzo38 22:56, 10 September 2012 (MDT)

Uh, that's a big pile of stuff, so I'm going to break them out again:

• I should have added mapper 66 (GNROM) to the list of discrete mappers that have/don't have bus conflicts along with UxROM, CNROM, AxROM, BNROM.
• The best description of the MMC1 variants I can think of is either at SxROM or at MMC1 pinout. At least SOROM, SXROM, and SUROM are exactly described by the preexisting fields of the NES2.0 header: SOROM necessarily has 16KiB PRG RAM, ≤8KiB CHR RAM+ROM. SUROM always has ≤8KiB PRG RAM, ≤8KiB CHR RAM+ROM, 512KiB PRG ROM. SXROM always has 32KiB PRG RAM, ≤8KiB CHR RAM+ROM. On the other hand, SEROM, SHROM, and SH1ROM always have 32KiB PRG ROM, but so does SIROM, and only the last doesn't entire ignore the MMC1's PRG banking abilities.
• The VRC2x/VRC4x/VRC7x collapse is handled is emulator sources I've read exactly as you say: the registers are (e.g.) (address&0x42). An emulator that required NES2.0 would be able to be clearer, but given that there are 5 different layouts for VRC4 it wouldn't actually make the code any simpler. (As an academic exercise, it would be interesting to make a ROM that autodetected which variant of VRC4 it was running on)... I think I've talked myself out of objecting to these.
• 0 or 8KiB PRG RAM → MMC3. 1 KiB PRG RAM → MMC6, and the behavior of the protection register would follow from that. Furthermore, since 1024x8 RAMs are at best ancient, saying "1 KiB RAM implies MMC6 behavior, 0,2ⁿ (n=7,8,9,11,12,13) imply MMC3 behavior, ≥16384 is an error" is unambiguous and seems cleaner to me.
  • The counterargument would invoke the X1-017 IC, since its internal memory (5KiB) isn't directly expressible in NES2.0.

—Lidnariq 01:25, 11 September 2012 (MDT)

I can't tell from INES Mapper 082 exactly how the X1-017 is supposed to map its battery-backed memory ("$7000-$6FFF"?), but I'd guess that non-power-of-two memory sizes would round up the same way they do in the Super NES internal header. --Tepples 06:52, 11 September 2012 (MDT)