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)

I'm not very much interested in restating opinions about ideological concerns for the format either, but I am interested in the specific definition of mappers 2, 3, and 7 here, in response to the submapper 0 text you just proposed. I strongly feel that mapper 7's submapper 0 should not break the existing ANROM games. Are you really arguing that it should? I don't remember you ever responding about mapper 7. We don't actually seem to have a dispute about mapper 3 (i.e. submapper 0 with bus conflicts), but I am unsure about it because I can't find much information about the non-CNROM games that use this mapper? Mapper 2 there is even less knowledge about, but the Disch notes for mapper 2 state "UxROM has bus conflicts, however mapper 002 is meant to be UxROM and compatible. So some mappers which were similar in function, but did not have bus conflicts are included", but again I can't find any existing research about the games/boards involved. Is the best we can do for this an emulator survey? - Rainwarrior (talk) 12:40, 1 September 2015 (MDT)

Hi guys, just thought I'd mention some ideas here even though I don't have a lot of time for this kind of stuff and probably won't be back to debate it. IMO, ines 1 mapper numbers arent strict definitions but rather a vague guide for organizing a family of functionality. Moving forward, I would like to see 'submapper 0' for mapper N to be 'do what you can to get the game to boot' without increasing the strictness of the legacy mapper's definition. Then, exceptions can be written by forwarding to a submapper. For instance, we might see: "Mapper N Submapper 0 = Mapper N Legacy Mode: A game with this submapper can't be safely run without a game-specific logic. It might have bus conflicts (handle as Submapper 1) or no bus conflicts (handle as Submapper 2)." Essentially leave submapper 0 as flexible legacy hack zone ghetto. This allows us the latitude to actually prescribe as part of the specification how legacy garbage is to be interpreted as well as set a simple rule for how to define submapper 0. If there's a channel besides #nesdev I wouldnt mind lurking and giving further feedback, but I don't have time to take a strong stance Zeromus (talk) 21:25, 1 September 2015 (MDT)

Ok, here's a pragmatic argument: What's the practical difference between:

• 300 games as submapper 0 (the ones where the hardware has bus conflicts, but the games have a bus conflict prevention table)
• 2 games as submapper 1
• 2 games as submapper 2

And

• 302 games as submapper 0
• 2 games as submapper 1

Especially when the size of the two minority groups is comparable? —Lidnariq (talk) 12:27, 2 September 2015 (MDT)

Scenario the First has four games which can be emulated unambiguously without hacks keyed to hashes. Scenario the Second has two games which can be emulated unamiguously without hacks keyed to hashes--so two of the games won't work on every emulator listing itself as in complete Mapper N compliance without the emulator having special cases for them. . . . . . . . . . . . Now that I've thought about it one more day, I have another proposition. Using submapper 0 as a catch-all for legacy behaviour is a bad idea. We should use iNES1 headers as an indicator that legacy behaviour is required. A rom should not be graduated to iNES2 until it can be assigned to a submapper that precisely defines it. In that scenario, we have 2 games as submapper 0, 2 games as submapper 1, and 300 games in iNES1 that cannot be legally turned into iNES2 without simultaneously encoding their bus conflict needs. Now, from an organizational perspective, this would require namespacing and maybe even documenting iNES1 and iNES2 mappers separately. You could resolve this by declaring that iNES2 is a strict superset defined as enclosing iNES1 within submapper 0 (which was my original proposition). Another way of writing the rule might be: "For mappers with >1 submapper, submapper 0 means, select another submapper using a database" Zeromus (talk) 21:14, 2 September 2015 (MDT)