Talk:NES 2.0 submappers/Proposals

Bus conflict submapper 0

This revision makes the following suggestion:

0: Normal (The game is believed to never elicit a bus conflict. In the event of a bus conflict, the emulator should warn, abort, or produce random values; the exact behavior is not known)

I think the goal for submapper 0 should usually be the greatest compatibility, and backwards compatibility with iNES. Setting the NES 2.0 identifier shouldn't change the behaviour of submapper 0 (if all other fields are otherwise "equivalent"). Validation tools to "warn" or "abort" could work nicely with submapper 2 (i.e. emulate bus conflicts), but I don't think they would do anything except reduce compatibility if used for submapper 0. A validation tool really shouldn't be part of the submapper definition (that's its own tool with its own goal, e.g. like nintendulator DX's thing to warn on use of uninitialized memory).

Cases 1 and 2 are good, it separates two things with specific conflicting needs. I think case 0 should just delegate a recommendation for 1 or 2.

• 002:0 = 002:1 ? UxROM says that mapper 002 shares UxROM with compatible boards that require no bus conflicts. (Also, that DK pie factory hack?)
• 003:0 = 003:2 ? INES Mapper 003 lists 1 game (Cybernoid) that requires bus conflicts, and 1 (Colorful Dragon, UNL) that requires none. Does Cybernoid get priority?
• 007:0 = 007:1 ? a lack of bus conflicts is required for some existing games, but it seems that none require bus conflicts.

Alternatively I would just propose that submapper 0 be used for no bus conflicts, and submapper 1 be used for AND bus conflicts, since a lack of bus conflicts might just generally produce greater compatibility? If your goal is to give homebrewers a nice testing environment that will emulate bus conflicts for them, submapper 2 does that job great, it doesn't need to be the default. The only case I've seen listed so far is Cybernoid?

I was wondering about other mappers besides 002/003/007 but I am guessing that the other bus-conflicting mappers don't have the ambiguity problems and can safely always have bus conflicts on?

- Rainwarrior (talk) 13:53, 31 August 2015 (MDT)

The default for any mapper that physically has bus conflicts (even if never elicited) must not be "no bus conflicts" for reasons we have already discussed and you find uncompelling.

FCEUX has already decided that the iNES1 handler is "produce bogus values (always 0) for CNROM and UNROM" (although it used to be AND) and "no bus conflicts for other data-bus latch mappers". Nestopia has codified bus conflicts as AND, for the "standard" version of specific discrete-logic mappers (UNROM, UOROM, CNROM, BNROM) and none otherwise.

—Lidnariq (talk) 18:31, 31 August 2015 (MDT)

I'm confused by this response? We're not discussing any mappers that always had bus conflicts here. We're discussing iNES mappers 2, 3, and 7, none of which unambiguously represents a physical mapper that had bus conflicts. Mapper 2 seems to include many obscure boards, some of which reputedly require a lack of bus conflicts? (I have no source for this other than statements found on the wiki; what are the actual compatibility cases?) Mapper 3 appears to be have the only compatibility conflict among these 3 mappers, and from the two cases listed a bus-conflicts submapper 0 seems valid to me. Mapper 7 submapper 0 requires no bus conflicts for compatibility. - Rainwarrior (talk) 19:31, 31 August 2015 (MDT)

Your central thesis appears to be that compatibility is the foremost goal, and my argument (from experience) is that prioritizing compatibility produces homebrew that can't run on hardware, so the default must be the strictest narrowest definition instead (and that people must explicitly opt into more lenient behavior). We've already had this argument. What's the point in having it again? —Lidnariq (talk) 20:41, 31 August 2015 (MDT)