It is currently Sun Oct 22, 2017 1:26 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri May 26, 2017 9:56 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
NESDev wiki and NesCartDB want all Camerica games, except the Quattro multicarts, at Mapper 71. NESDev wiki also assigns a submapper to Fire Hawk's one-screen mirroring. Why?

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.


Top
 Profile  
 
PostPosted: Fri May 26, 2017 12:10 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6294
Location: Seattle
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"


Top
 Profile  
 
PostPosted: Fri May 26, 2017 12:39 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
^^^ well-put. Problem is, of course, that submappers favor lumping (+submapper assignment), and iNES backwards-compatibility favors splitting (…sort of. Some mappers are allocated in this spirit, others are lumped, like MIMIC-1), and NES2.0 unifies these features…

iNES header does not have a configuration meaning "one-screen mirroring"…and the Quattro games aren't 1s, either.

I should really get back to making the submappers for PP.


Top
 Profile  
 
PostPosted: Fri May 26, 2017 1:16 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
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).


Top
 Profile  
 
PostPosted: Fri May 26, 2017 8:27 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5730
Location: Canada
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.


Top
 Profile  
 
PostPosted: Fri May 26, 2017 8:47 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5730
Location: Canada
NewRisingSun wrote:
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. :P

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!


Top
 Profile  
 
PostPosted: Sat May 27, 2017 10:54 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
rainwarrior wrote:
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.


Top
 Profile  
 
PostPosted: Sat May 27, 2017 12:43 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5730
Location: Canada
NewRisingSun wrote:
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).


Top
 Profile  
 
PostPosted: Thu Jun 29, 2017 11:09 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
rainwarrior wrote:
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.


Was a fix or a patch released for Dreamworld Pogie?

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Thu Jun 29, 2017 11:21 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5730
Location: Canada
Great Hierophant wrote:
Was a fix or a patch released for Dreamworld Pogie?

I made an IPS. It was linked in the previous post: https://twitter.com/bbbradsmith/status/811344703538991104

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.


Top
 Profile  
 
PostPosted: Thu Jun 29, 2017 12:01 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
rainwarrior wrote:
Great Hierophant wrote:
Was a fix or a patch released for Dreamworld Pogie?

I made an IPS. It was linked in the previous post: https://twitter.com/bbbradsmith/status/811344703538991104

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.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Thu Jun 29, 2017 2:21 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1306
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.


Top
 Profile  
 
PostPosted: Thu Jun 29, 2017 2:28 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6294
Location: Seattle
The NES's NMOS pulldowns usually seem to be stronger than most ROMs' PMOS pullups.


Top
 Profile  
 
PostPosted: Fri Jun 30, 2017 7:23 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
As I see it, games tend to fall into three categories :

Requires Bus Conflicts (bitwise AND of CPU value and ROM value) to function properly :
Cybernoid

Board's Hardware ensures that the ROM's value prevails over the CPU's value :
Death Race (bit 0 only)

Requires CPU's value to prevail over the ROM's value :
Donkey Kong Official Edition/Pie Factory (Nintendo's Official Hack)
Colorful Dragon (Sachen) - What about Tagin Dragon from Bunch Games?
Dreamworld Pogie (Codemasters, unfixed)

What else exists? These were the only games I could find.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Fri Jun 30, 2017 8:21 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 14 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group