The two new Dizzy games (Wonderland Dizzy, Mystery World Dizzy) released by the Oliver Twins are set to Mapper 2, even as Wonderland Dizzy retains the CIC stun code. All Camerica games other than Fire Hawk and the Quattros work nicely as Mapper 2 (UNROM). The additional latch register range from $8000-$BFFF and the CIC stun register range from $F000-$FFFF do not seem to throw UNROM emulation off the rails in any emulator except FCEUX, and the latter is thrown off because it always emulates bus conflicts. If the point is that UNROM has bus conflicts while Camerica boards don't, UNROM's submappers already account for this.

I found this question asked once before, but not answered. My motivation for asking is that the Everdrive N8 does not support submappers and requires the Camerica games at Mapper 2 except for Fire Hawk and the Quattros, and doing so seems like a sensible idea in general.

There's been a long simmering argument—I can't really call it a debate, because ultimately it's not really rational—between "lumpers" and "splitters" in allocating mappers.

"Lumpers" say that two boards can be emulated using the same code, so they should be the same mapper."Splitters" say that the hardware on the boards is different, and that a game could be found that would require separate implementations.

But ... anyway ... I'd just like to point out that your argument ultimately boils down to "FCEUX should implement submappers so that the Everdrive doesn't have to"

No, that's not what my argument is at all. My argument is that instead of lumping two incompatible mappers under Mapper 71 (H/V and single-screen mirroring Camerica), two compatible mappers should be lumped under Mapper 2 (UNROM and H/V mirroring Camerica).

The original purpose of submappers was mostly to obviate "ugly hacks" in the existing mapper implementations. If you look at how emulators disambiguate Fire Hawk's special case, it's a big mess. A CRC check is perhaps cleaner but inflexible. Others heuristically change the mirroring behaviour depending on which values get written to $8000 by the game, which seems to work in practice but is a little bit horrifying, if you're of a certain mindset.

Its true that these games seem to run compatibly as UNROM, but it depends where you're trying to do the bare minimum to get the games to run, or you want more thorough accuracy. For example, if you were looking to exploit a bug for a speedrun opportunity, it will probably become very relevant whether $8000-BFFF can bank PRG or not.

Emulating bugs correctly is important to many people (not just speedrunners). Probably the design of the code never intends to write to $8000-BFFF, but that doesn't mean it won't ever. If you're running on UNROM instead, you know that emulation and discovery of any such behaviour is compromised.

Why did they get their own mapper? Because 1/4 of the address space doesn't behave like UNROM, and that seems like a huge and clear difference to me. I don't think this is really about "lumping" vs. "splitting". These mapper assignments were made long before submappers were an idea, the submappers are just a coping mechanism to get us out of that hole. You don't get to reassign mapper 71 in 2017.

If you just want to change the headers on your ROMs and run them as UNROM, though, there's really nothing stopping you. Probably none of us in this conversation will notice a difference either way.

The two new Dizzy games (Wonderland Dizzy, Mystery World Dizzy) released by the Oliver Twins are set to Mapper 2, even as Wonderland Dizzy retains the CIC stun code. ... If the point is that UNROM has bus conflicts while Camerica boards don't, UNROM's submappers already account for this.

By the way, the related new Oliver Twins game Dreamworld Pogie had a bug exposed by emulating UNROM bus conflicts. Bus conflicts are not necessarily a trivial difference: this broke the game's ending!

Some emulators do support submappers for UNROM, but a lot don't. Dreamworld Pogie wasn't using an NES 2.0 header, and I think it was just using mapper 2 because they presumed it would have the widest compatibility (everybody implements mapper 2, not everybody mapper 71)-- unfortunately it had a bug that made this not true.

Mapper 2 is kind of a minefield for this problem, since emulating bus conflicts or not are both compatible modes for the vast majority of games-- the differences come up in obscure cases like this that are hard to catch in testing. The NES 2.0 submapper solution doesn't help when using emulators (or e.g. Everdrive) that don't implement it!

Why did they get their own mapper? Because 1/4 of the address space doesn't behave like UNROM, and that seems like a huge and clear difference to me. I don't think this is really about "lumping" vs. "splitting".

I agree that this is not about lumping versus splitting. From reading your response, it seems to be more about the NES header containing just enough information for an emulator to run the games properly, versus the header serving to "document the hardware" for other purposes, such as swapping ROM chips between compatible boards. Obviously, you could not put Contra on a Camerica board, for example, because of the address space differences.

rainwarrior wrote:

By the way, the related new Oliver Twins game Dreamworld Pogie had a bug exposed by emulating UNROM bus conflicts. Bus conflicts are not necessarily a trivial difference: this broke the game's ending!

Yes, that's FCEUX emulating bus conflicts even in the absence of a submapper mandate to do so, as I mentioned previously. This FCEUX-specific behavior causes quite a number of problems with other unlicensed games as well, mostly CNROM-like ones.

rainwarrior wrote:

If you look at how emulators disambiguate Fire Hawk's special case, it's a big mess.

Nintendulator's heuristic is pleasantly simple: Use horizontal/vertical mirroring from the NES header until $9000-$9FFF is written to, which no game other than Fire Hawk does.

From reading your response, it seems to be more about the NES header containing just enough information for an emulator to run the games properly, versus the header serving to "document the hardware" for other purposes, such as swapping ROM chips between compatible boards.

No, it's not really that. We've got other sources for collecting detailed information about various boards. The iNES header is just trying to provide enough information for correct emulation.

Software that works as intended probably won't show a difference in emulation between the UxROM and Camerica setups, but all software has bugs. I guess it's like "undefined behaviour" in programming languages, if you consider the bugs to be important to the experience, you need to emulate the correctly. If you consider them to be "undefined", maybe you don't care whether the bug is accurate to the original, you're ready to reset the game anyway. From the software developer's perspective, you'd probably have good expectations for something to be able to run on both mapper 71 and mapper 2, because you don't know about your own bugs (else you'd fix them). Very popular games have well known and well documented bugs, but unpopular games do too-- and we probably won't discover them if we only ever emulate them as "compatible" hardware. That's the difference this makes.

The original iNES file format presumed there would only ever be 16 mappers. Just getting a game to run at all was kind of amazing, and I don't think bus conflicts were even being considered at that point. Splitting Camerica games to mapper 71 was a subsequent refinement. Adding bus conflict emulation was another later refinement, and very lately we can add bus conflict designation as submappers (not really put to much use yet). The final form wasn't known in advance, this is the product of a lot of years of corrections being made.

In the case of Dreamworld Pogie, I have no idea whether the carts they eventually made were subject to bus conflicts (did anyone here get one?). The code itself, however, was clearly written with bus conflicts in mind. All the bank writes were through a table, just as you normally do with bus-conflict mappers. The bug was the result of a typo writing to the wrong part of the table.

So, I mean, if you're a developer maybe you would want to try your software as if on different compatible boards, but I don't think that's a good example purpose. Usually you would know the intended hardware for your software. Running ROMs on a foreign board isn't really that common, except as a repro/pirate/donor problem, I think? Accidentally causing bugs, though, just by playing, lots of people do that. Intentionally causing bugs as a speedrun exploit, etc. is another thing that many people do (and need accurate emulation to rely on).

In the case of Dreamworld Pogie, I have no idea whether the carts they eventually made were subject to bus conflicts (did anyone here get one?). The code itself, however, was clearly written with bus conflicts in mind. All the bank writes were through a table, just as you normally do with bus-conflict mappers. The bug was the result of a typo writing to the wrong part of the table.

I haven't checked if they ever updated the ROM on the site, though, and don't know whether the carts they eventually built were affected. You'd have to play all the way to the end to find out.

It is fixed, I download the game and did not need the patch.

The Game Genie code LEULOSGE should fix it for people with real cartridges. That code should change the value at BDB1 from 0C to 0B.

As I understand the code, the game is trying to switch to bank 1. It writes a 01 to the bank select area, which is any memory location from $C000-$FFFF. But the value in 1C00C (last bank in the ROM) is an 02. If the CPU wins the bus conflict or bus conflicts are not emulated, then the right bank is loaded and the game works normally. If the ROM wins the bus conflict or bus conflicts are emulated so that it wins, then the wrong bank is loaded and the game works incorrectly.

The 2A03 is an NMOS device, which will sink current driving the data lines low. When two NMOS devices face contention, typically the result looks like a logical AND, so in this case, selecting Bank $01 and writing to $1C00C (containing $02) could result in Bank 0 being the result.

I expect a typical flash rom (29F* series), a 27C* EPROM, or another ROM behind a level-translating buffer to be a CMOS device, driving data lines high and low. In this case, I would expect $02 to win.

Many mapper 7 games on the ANROM or AOROM board fall into "Requires CPU's value to prevail over the ROM's value" because they expect the PRG ROM to disable itself during writes. ANROM decodes PRG ROM with 74HC02, and AOROM uses a PRG ROM whose +CE is wired to CPU R/W.

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum