NES 2.0 submappers

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 submappers

Post by lidnariq »

Question for emulator authors about m185 submappers.

Does it make more sense to you to
- Store the value written to the '161 for normal function? or to
- Store the nature (-, +, n/c) of the additional chip enables on the CHRROM?

None of the games discovered have more than 8KiB CHR, nor have any of the enables be don't care. Nestopia already stores the latter using its internal database, but doesn't implement submappers. The published heuristic is more similar to the former.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: NES 2.0 submappers

Post by Dwedit »

In terms of multiple console emulators, MESS seems to have competition from Retroarch now.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
etabeta
Posts: 109
Joined: Wed Nov 29, 2006 10:11 am
Location: Trieste, Italy

Re: NES 2.0 submappers

Post by etabeta »

well, competition is always good for users so I don't complain at all

however, while I love the portability of retroarch/libretro, I think that in general gluing together multiple *separate* emulators is a bit of a waste, if the only part that gets shared is the interface... say that you want to add apple||gs emulation to libretro, it's a bit annoying that you cannot easily use the g65816 CPU from bsnes just because it belongs to a different module
in MESS components are fully shared and while this sometimes means that the fix for a system breaks some other machine, it has a lot of pros: for instance it has been very easy to add emulation of c64 carts containing z80 additional CPU (like the CP/M expansion cart), because even if the c64 only needed a 6502 variant, we had a fully featured z80 core already available ;)

back to NES, however, I definitely need a few weeks of holidays to rewrite the PPU because it shows its limits with many mappers. after that we could finally start competing with most celebrated emulators... ;)
etabeta
Posts: 109
Joined: Wed Nov 29, 2006 10:11 am
Location: Trieste, Italy

Re: NES 2.0 submappers

Post by etabeta »

OK. I have added support for confirmed+drafted iNES2.0 submappers in MESS, and tepples' holydiverbatman testroms seem to be all recognized properly, so that I would say the code works for what I can test :)

I have a few comments, though.
First of all, there is a mistake in Wiki about Mapper 68. All carts using this mapper (Afterburner, Maharaja and Nantettatte!! Baseball) actually use Sunsoft-4 not only Nantettatte!! Baseball. The "variant" required by Nantettatte!! Baseball shall be labeled as Sunsoft-DCS (Dual Cart System?) since this is the difference (compatibility with small add-on cartridge on NTBROM pcbs)
For the record, MESS supports these as separate dumps to be mounted in a second cartslot which becomes available when Nantettatte!! Baseball is loaded ;)

Second, there are also a few pirate mappers which might require submapper:
- Mapper 42 is used for both Ai Senshi Nicol and Mario Baby (the Bio Miracle Bokutte Upa pirate, with Mario on the cart), even if the games are not compatible
- Mapper 242 is used both for Waixing's Dragon Quest 8 (which requires a different mirroring handling) and for Waixing's Wai Xing Zhan Shi
- (but I'm not 100% sure about this) Mapper 113 is used both for HES 6-in-1, which has mapper-controlled mirroring, and the following games with hardwired mirroring: AV Hanafuda Club, AV Soccer, Papillon, Sidewinder

Finally, Mapper 185 should also be used for Jpn Othello (see http://bootgod.dyndns.org:7777/profile.php?id=4061 ), even if NESDev wiki does not list it with the others


p.s. I also think some chinese dumper has decided to label as Mapper 168 some Subor board, despite the overlap with Racermate... but I still have to better check the dumps since it would not be the first wrong header I find ;)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 submappers

Post by lidnariq »

etabeta wrote:First of all, there is a mistake in Wiki about Mapper 68. All carts using this mapper (Afterburner, Maharaja and Nantettatte!! Baseball) actually use Sunsoft-4 not only Nantettatte!! Baseball. The "variant" required by Nantettatte!! Baseball shall be labeled as Sunsoft-DCS (Dual Cart System?) since this is the difference (compatibility with small add-on cartridge on NTBROM pcbs)
I'm not certain where this is? The iNES Mapper 068 and Sunsoft 4 pinout articles don't seem to muddy this point?
- (but I'm not 100% sure about this) Mapper 113 is used both for HES 6-in-1, which has mapper-controlled mirroring, and the following games with hardwired mirroring: AV Hanafuda Club, AV Soccer, Papillon, Sidewinder
Aren't the other games no bigger than 64/64 ? They should be mapper 79 if they're that small and don't use mapper-controller mirroring.

For that matter, I don't recall having found any games that were either of:
smaller-than-or-equal 64/64 and required mirroring control
larger than 64/64 and didn't require mirroring control
etabeta
Posts: 109
Joined: Wed Nov 29, 2006 10:11 am
Location: Trieste, Italy

Re: NES 2.0 submappers

Post by etabeta »

lidnariq wrote:
etabeta wrote:First of all, there is a mistake in Wiki about Mapper 68. All carts using this mapper (Afterburner, Maharaja and Nantettatte!! Baseball) actually use Sunsoft-4 not only Nantettatte!! Baseball. The "variant" required by Nantettatte!! Baseball shall be labeled as Sunsoft-DCS (Dual Cart System?) since this is the difference (compatibility with small add-on cartridge on NTBROM pcbs)
I'm not certain where this is? The iNES Mapper 068 and Sunsoft 4 pinout articles don't seem to muddy this point?
I was referring to the submapper page, and its Mapper 068 subparagraph. Sorry for not being clear :)

http://wiki.nesdev.com/w/index.php/NES_ ... _Sunsoft_4
lidnariq wrote:
- (but I'm not 100% sure about this) Mapper 113 is used both for HES 6-in-1, which has mapper-controlled mirroring, and the following games with hardwired mirroring: AV Hanafuda Club, AV Soccer, Papillon, Sidewinder
Aren't the other games no bigger than 64/64 ? They should be mapper 79 if they're that small and don't use mapper-controller mirroring.

For that matter, I don't recall having found any games that were either of:
smaller-than-or-equal 64/64 and required mirroring control
larger than 64/64 and didn't require mirroring control
you might be right, and those could be Mapper 79 mislabeled... they would not be the first ones I've seen, so I would check. thanks for the suggestion :)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 submappers

Post by lidnariq »

tepples wrote:On MC-ACC (Acclaim MMC3 clone), does loading 0 into the latch produce an IRQ every scanline, or does it produce no IRQs?
There was one last question we had about the MC-ACC IRQs, as tepples mentioned above.

I noticed that Alien³ conveniently redirects both its NMI and IRQ via RAM (i.e. the two vectors point at JMP (00A3) or (00A5)), so hijacking that to write a test was easy.

The test sets up the MMC3 IRQ to run every second scanline (i.e. [$C000]←1) and had an IRQ handler that increments a counter (and then acknowledges and retriggers by writing to $E000, $C001, $E001), and see how many times the IRQ is triggered in one frame. This is a sanity check to make sure the second test is reliable.

Then it repeats with [$C000]←0.

BootGod obligingly tested for me. The former provided a count of 120 (as expected, give or take), and the latter provided a count of 241. So it appears that MC-ACC acts like MMC3C in this regard.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 submappers

Post by lidnariq »

With the above out of the way, we should allocate submappers for mapper 4. At the very least, we need to explicitly call out MC-ACC, but I'm torn as to whether we should explicitly call out anything else.

As far as I know, everything else can be emulated as an MMC3C, so theoretically everything else can just be the default behavior. Would it be useful to have a submapper to mark games that explicitly require the MMC3C? How about ones that are known to run correctly on both MMC3A and MMC3C (effectively "someone's looked at this game and verified it")?
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 submappers

Post by rainwarrior »

http://wiki.nesdev.com/w/index.php/NES_2.0_submappers#004:_MMC3 wrote: No submapper of mapper 4 is needed to distinguish MMC3 from MMC6, as any board with MMC6-sized PRG RAM will behave like MMC6.
I think this is a mistake. MMC6 needs its own submapper.

Choosing MMC6 vs MMC3 is orthogonal to PRG RAM size. An MMC3 board with 1k of PRG-RAM would behave differently than MMC6 with 1k of PRG-RAM.

If the goal is simply to support existing games, we already do that with CRCs and other heuristic methods. Checking PRG-RAM size to select a mapper implementation is just as much a kludge.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 submappers

Post by tepples »

rainwarrior wrote:Choosing MMC6 vs MMC3 is orthogonal to PRG RAM size. An MMC3 board with 1k of PRG-RAM would behave differently than MMC6 with 1k of PRG-RAM.
What "1k of PRG-RAM"? SRAMs are sold in odd powers of two bytes, which are equal to powers of four bits. There are 512 byte (4 Kbit) SRAMs, 2048 byte (16 Kbit) SRAMs, 8192 byte (64 Kbit) SRAMs, and 32768 byte (256 Kbit) SRAMs. Family BASIC v3 had two 2048 byte SRAMs, for instance. The MMC6's enable circuitry is just up-front that it contains two 512 byte SRAMs.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 submappers

Post by rainwarrior »

I didn't realize MMC6's RAM was internal, but I still have the same opinion on this: the PRG-RAM size field should not select a mapper. It should select a PRG-RAM size only. I don't think SRAM packaging is the issue.

It seems practical for selecting MMC6 as a mapper to force a 1k PRG-RAM size, but that's precisely the opposite of what I am opposed to. A mapper dictating a PRG-RAM size is okay. A PRG-RAM size dictating a mapper is not.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 submappers

Post by tepples »

I sort of see where you're coming from. But is there a functional difference between MMC3C and MMC3BS on the one hand and MMC6 on the other, other than that MMC3 has a memory enable circuit for one SRAM and MMC6 has a memory enable circuit for two (on-package) SRAMs? The answer informs how I re-add the MMC6 memory enable logic to the submapper page.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 submappers

Post by rainwarrior »

I have no comment on MMC3C vs MMC3BS, as I don't know what they are. MMC6 is obviously functionally different, which is why I've brought it up. Mapper + submapper should unambiguously select a mapper implementation. We should not have to look at other fields or resort to other heuristics to pick a mapper. For this reason, MMC6 needs a submapper allocation.

Are you asking about the other MMC3 variants because you want to add other mapper 4 submapper allocations and you're trying to keep the list "pretty" by putting MMC6 at the end? The iNES mappers don't have any logical order. The submappers allocations will grow organic and ugly as we discover new things. This is just a given. If you want to add it now, fine, do it (obviously nobody's had time to implement MMC6 as submapper 4 yet :P). If not, don't worry about it being out of order later.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 submappers

Post by tepples »

rainwarrior wrote:I have no comment on MMC3C vs MMC3BS, as I don't know what they are.
They're revisions of the MMC3 IC. MMC3A and MMC3B do not allow generating an IRQ on every scanline. MMC3BS and MMC3C do. I was asking about differences between MMC3 and MMC6 other than those related to battery RAM enabling.
MMC6 is obviously functionally different, which is why I've brought it up. Mapper + submapper should unambiguously select a mapper implementation. We should not have to look at other fields or resort to other heuristics to pick a mapper.
As far as I can tell, MMC6 differs from MMC3 in almost the same way that SNROM, SOROM, and SXROM differ from other MMC1 boards. Do they likewise need unique submapper numbers?
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 submappers

Post by rainwarrior »

tepples wrote:As far as I can tell, MMC6 differs from MMC3 in almost the same way that SNROM, SOROM, and SXROM differ from other MMC1 boards. Do they likewise need unique submapper numbers?
I am not familiar with the details of these boards. It sounds like you're saying that they're similar boards but designed for different ROM/RAM sizes and end up having enable/write registers in different/mutually-incompatible places, that don't actually matter for extant game compatibility? Or do they matter? Is a heuristic currently being done (e.g. CRC check) to choose an implementation or are emulators just not implementing the unnecessary features?

I'd say that a submapper assignment for these things wouldn't hurt, but at the same time if all extant games are compatible with some "mapper 1" subset, I wouldn't really expect anyone to implement it or use it any time soon. So... sure if you want, but probably doesn't really matter if they get an assignment or not. Do it if you need it, I guess? I think submappers can be allocated as needed. We don't need to come up with a big complicated specification where it's impossible to tell which parts are important. If someone needs to disambiguate a mapper to get something to run, let them allocate it. Same deal as if someone comes up with a new mapper. Theoretical mappers and differences aren't important, but if someone publishes software that needs it, let them allocate it.

MMC6 affects two very well known, popular games. There is really no reason for a new homebrew to target it instead of MMC3. The only new use for it is modifications of Startropics or its sequel. Given how popular they are as games, it would be unsurprising if there weren't more hacks of it in the future. I was looking into this myself, because I wanted to resolve the issue of my own Startropics hack not running on some emulators, but I was dismayed to find that even the emulators with "NES 2.0" support did not have a consistent/proper way to identify MMC6. That's the practical issue I'm trying to solve here. Nestopia does one thing, puNES does another, Nintendulator does a third, and I think it's largely because the specification is unclear. I think a submapper allocation would make it extremely straightforward.

We should be able to just look up a mapper from a table, using only the mapper and submapper numbers. There should not have to be extra code to check this-or-that other field. Yes it's true that MMC6's only practical use is if you want 1k PRG RAM. It should always be accompanied by a 1k PRG RAM specification, but that's not how a mapper should be selected.
Post Reply