NES 2.0 submappers

It's been six years since the NES 2.0 spec was first published, and kevtris and I are finally getting around to defining some values for the submapper field.

Glad to see it finally being used.

From the wiki page:
One proposed general principle for backward compatibility is that submapper 0 be reserved for the default iNES

Good idea! Apply that proposal!
If it's 0 then the emulator/tools can try to guess or autodetect what mapper is meant (as happens in old rom images).
If it's 1..15 then emulator/tools can rely on the submapper number (as happens in newer/updated rom images).

If you want the old behavior, wouldn't it be better to just not update the header to iNES 2.0? I mean, why go through the trouble of using the more complete header if you have nothing to add?

Part of it has to do with behavior subtleties in extant mapper variants that have not yet been fully characterized.

I'm kinda wondering about the question of whether to use a submapper, or assign a new mapper. Forgive me if this has already been said, but to me, it seems the only important value of the submapper field is that it will be ignored by emulators that don't support iNES 2.0, allowing them to fall back on a "mostly compatible" version of the mapper.

I don't know if you share my line of reasoning here, but I think it leads to the following two principles:

- If a game already has an assigned mapper, don't change it, because there's already an iNES 1.0 fallback implementation.
- Don't introduce submappers that can't acceptably fall back to the iNES 1.0 version of that mapper. (Assign a new mapper instead.)


I also like the idea that submapper 0 just means the default iNES 1.0 handling. I think this also suggests:

- All submappers except 0 must unambiguously specify a single implementation, and not be dependent on external configurations like PRG / CHR / CRC.
- All iNES 1.0 mappers that have ambiguities resolved by external configurations must be given a submapper for each case that needs resolution.


Finally, iNES 2.0 only mappers (mappers 256+) have no concern for iNES 1.0 backward compatibility. For these, it should be acceptable to group related mappers by submapper. For instance, the proposed 1-chip mapper has a lot of jumper configurations which could be presented as submappers of, say, mapper 257.


I'm proposing these guidelines in the interest of needing less arbitration about what to do in various cases. (Personally, I don't have much stake in it anyway, since I'm really quite happy living within the confines of iNES 1.0 for my own purposes.)


Another question re: the proposal on the wiki: if you're going to have an option to force NINA for mapper 34, why not also have an option to force BNROM? What is the Union Bond mapper? (Does it have a 5 bit latch?)

I agree.
I'd definitely see a higher probability of someone ever wanting to do BNROM + 8kb CHR-ROM than someone wanting to clone NINA's weird and strange mapper with CHR-RAM.

As for why both were assigned to the same number, I suspect two different people assigned it at about the same time without consulting eachother. This is pure speculation though.

Added a suggestion above about submappers for iNES 2.0 only mappers (256+).


Or, I suppose we could even be crafty and stick it in mapper 256 or 512 or something that would read as mapper 0 in iNES 1.0...

Are we supposed to pick iNES 2.0 mapper numbers according to what iNES 1.0 mapper they might best fall back on?

Currently, submappers are used to fix old mis-defined NES 1.0 roms.
In future, similar mis-definitions might occur also in NES 2.0 roms.
So, I think, even in NES 2.0 files, submapper numbers should be kept reserved for future bugfixes.

BNROM... I think it was originally defined as mapper 7 (AOROM), I've seen an old Deadly Towers rom-image from 1997 assigned like so, and then somebody "corrected" it by assigning it as mapper 34 (NINA-001). In so far, both mapper 7 and 34 may need a BNROM submapper number.

I think you should enforce it more, and if the header specifies NES 2.0 then assume that the header is correct. (If it does not specify NES 2.0, then use checksums and whatever to correct the header automatically.)

Well, I suppose you can do this if making a game that uses mapper 256, which might also work in mapper 0 or otherwise will detect if it is running on mapper 0 and display an error message saying that you require a emulator compatible with NES 2.0.

Yes, that's the idea behind the NES 2.0 specs. What do you want to enfore more?
Ìf things go wrong in future, then you'll need to use the "checksums and whatever" tricks also for some NES 2.0 files.


Oh, no, please not! That would look messy. Better suggest to allocate numbers straightly increasing from 256 and up.
For the "best fall back on" thing, that's what the submapper number is intended for.


In that special case, for mapper 0, it's a good idea. I suspect that there are plenty "mapper 0" roms that aren't NROM (things like the Game Genie bios, for example). If there are too many such mapper 0 variants then the 15 submapper numbers won't be enough ro resolve that mess, using 256 and 512 would extend available space for "NROM" variants.
But then it would need to be defined/reserved for that purpose right NOW. So that emulator programmers can implement the required "fallback on mapper 0" - else the fallback trick would work only for very-old NES 1.0 emus, while the current NES 2.0 emus would see 256 as unsupported mapper.

http://wiki.nesdev.com/w/index.php/INES_Mapper_023 tells that mapper 23 is used for three different boards, one VRC2 board, and apparently two VRC4 boards (I don't know what game is using VRC4f though). That'll be needed to be puzzled into the submapper definitions, too. The VRC2 won't match too well with the "treat submapper bits as address lines" stuff. Would have been better to use submappers 1 and 2 for VRC4 variants, instead of doing that address-line mapping.

And the submapper page chapters should be better strictly sorted by mapper numbers. At the moment some entries are filed under board names like VRC4 and MMC1, and others are filed under mapper numbers. That's confusing, and VRC4 as chapter name doesn't work out for cases like the shared VRC4+VRC2 mapper number.

Yeah, cancel my thoughts on 256+ mappers maybe having a fallback. That's probably counterproductive. The only thing is that unlike the 255- mappers, when run as iNES 1.0 they're going to fall back to a random mapper. Not a great error condition.

I dunno what I'd suggest, though. We could reserve another 8 bits for extended mapper number, and make them all use the same iNES 1.0 mapper number. At least then, something more predictable could happen.

I think it is a very bad idea...you should write on the specification, any file specifying NES 2.0 in the header MUST NOT have incorrect and the program reading it MUST NOT automatically change it to something else.

Another thing to specify is how a trainer and battery RAM is interacted (my suggestion: a part of the battery RAM is initialized with the trainer data, and if a battery RAM file already exists, ignore the trainer; what do existing emulators already do about this, and do any such files already exist?).

However, I don't know what the checksums are and it might be difficult to write the emulators to add these mappers supports, especially with the checksums and so on using, so my solution to this problem is: (link) (yes, the specific paragraph I am linking to is relevant; the rest is unimportant to this discussion) It would be a more precise specification of what each iNES mapper means and what the other stuff in the file means. (I have heard of a program which compiles a hardware description into software codes using GCC)

Of course NES 2.0 headers SHOULD be correct. But that won't be always the case - things can go wrong there.
Normally you'd trust NES 2.0 headers with submapper=0 to be correct. If you KNOW that there are multiple definitions for a NES 2.0 mapper number then you can try to detect the desired mapper type (via known ROM checksum databases or other trickery). If there is a NONZERO submapper number than you can rely on that value and do need the detection trickery.


I've never thought about that special case: Trainer PLUS battery. Yes, that should defined. Your suggestion looks fine... from the how-it-should-work point of view. The way how-it-did-actually-work might have been different, and then we should keep that behaviour.
What I mean is: The "trainers" are (as far as I know) dated back to old copiers (equivalents to modern flashcarts, that loaded ROMs from built-in floppy disc drives into built-in RAM). And emulators should adopt their behaviour.
Does anybody know how original copiers did handle the trainer bit? I would suspect that they did destroy the first 512 bytes of saved battery ram (if they did support saving at all), and did overwrite it by the "trainer" data (?)

It assumes that there is a "how-it-did-actually-work"; it is possible that different emulators differ, or will ignore the trainer in such case, or something like that. Using trainer and battery together in the way I suggested may be useful if you are making a game and want to specify the initial contents of battery RAM (when copying to a cartridge, you load the first 512 bytes of battery RAM with trainer; same thing with emulators), and it also allows the game to detect if the battery is dead.

Is there a submapper proposed to distinguish FME-7 from Sunsoft-5B? FME-7 doesn't have the music chip.

Same deal with N163 vs N106, though not sure how necessary a submapper is, since in these cases (so far as I have seen) games that don't use the audio features don't do anything that would make them incombatible with the mapper that has audio features, and vice versa (excepting the lack of expansion sound).

Probably worth having:
0 - iNES
1 - FME-7 / Sunsoft 5A
2 - Sunsoft 5B

If nothing else, it will help tools/emulators actually distinguish which games do need the audio features.

If there is no conflict, why waste the effort to fix a non existent problem?

At least in the case of Namco 163/175/340 (ines 19/210), I'm not certain what's really going on. I got a friend to translate the linked writeup Naruko had made. I'm a little skeptical of Nestopia's decision to collapse mapper 210 into mapper 19, but without getting a native speaker to play through all of the Namco 175/340 games I'm not certain whether that's reasonable or not.

I'm also concerned whether the 175 and 340 don't secretly pose some kind of compatibility issue, but that's certainly solveable using submappers. It would be nice to see a commercial example that made it clear they were necessary, though. (I could clearly write test code that would detect which variant it was being emulated as)

I think I know how to solve that one: default to BNROM behavior for 8192 byte CHR ROM.

I reviewed the list of NES 2.0 submappers today, promoting drafts that hadn't changed in a while to recommendations on the principle of silent consensus. A few questions remain before I can take some proposals further:

• On MC-ACC (Acclaim MMC3 clone), does loading 0 into the latch produce an IRQ every scanline, or does it produce no IRQs?
• TEROM and TFROM boards can be configured for fixed H/V mirroring instead of MMC3 mirroring, presumably added in case the supply of DEROM and DE1ROM ran out. Do any games actually use the fixed H/V mirroring?
• What makes Mindseeker, to which kevtris allocated its own submapper, different from any other Namco 163 game?
• Are the bugs in the wavetable synthesizer of the Namco 129 mapper characterized? The difference between it and Namco 163 is that Namco 163's synth is corrected. Or is it safe to emulate all N129 games as if they have no expansion sound?
• Anything we missed?

If the unneeded audio emulation can be turned off, this can save CPU.

Information about whether or not the audio chip is present can be useful for automated ROM tools, statistics gathering, etc.

It could potentially make a difference to a homebrew that wants to rely on the audio chip not being there, but I kinda doubt this would ever be of real use.

It's hair splitting, yes, but the "extra effort" is also pretty small. I mean, it's just a few more lines in a spec doc. The emulator implementation doesn't need to do anything with the extra information unless its author wants to.

Trainer data + backed battery save data would be PRG RAM in hardware terms. Well, you know: "battery" means "data at $6000-$7FFF" is saved & loaded there, and "trainer" is usually loaded/started at $7000. In software terms, once you load the battery data, the trainer should overwrites it. In my emu, I don't check for battery if there's trainer data.

I don't know, but maybe it can be used in case someone makes up a new game which uses the fixed mirroring (or if someone finds a previously unknown game that uses it).


This really ought to be specified.

• MMC1: I agree using the PRG RAM sizes to distinguish SUROM/SOROM/SXROM, if it is more than 8K, or if the PRG ROM size is more than 256K. This looks like the only use of such mappers, so a submapper number for such thing is useless.
• MMC5: I have made the proposal to distinguish SL/CL and contiguous/non-contiguous PRG RAM. As far as I know, no known commercial games care (if the emulator provides 64K PRG RAM then it will work from what I have read), although these features are present on the MMC5 and may be useful for homebrew.
• Some mappers may use trainer ROM for other purpose. No mappers are known to do this, though.

Does anyone know what game this is?

As far as I (and the fceux team, and the original author of nestopia) know, nothing like 78.2 exists. I have no idea why kevtris allocated it. (nesdevwiki)

In fact, there are a lot of things in that list I don't understand, although most of them are explained if his list predated the RAM size fields.

I assume it'd be used for a variant of the Uchuusen board with fixed V or H mirroring, and that's what I listed it as in the community-maintained submapper page. But I guess new development on that mapper should use the Holy Diver configuration instead of the fixed mirroring configuration that no commercial games used.

I also don't think mapper 78.2 is useful, and it should be deallocated (or "deprecated", like it currently is), but see below anyways if anyone wants to use it; it is possible that someone wants to use it for some reason.

Nevertheless, I have defined G'.4 which happens to be the same as the currently defined 78.2 (mapper G'.12 would be an oversize 70, and G.4 is oversize 11). Maybe someone somehow finds this useful, but I don't know. It seems to me that it would be a usable generalization of several GNROM-like mappers, but I don't know if anyone uses it.

great news!
I will update soonish MESS handling of iNES2.0 to match this!

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.

In terms of multiple console emulators, MESS seems to have competition from Retroarch now.

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...

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

I'm not certain where this is? The iNES Mapper 068 and Sunsoft 4 pinout articles don't seem to muddy this point?

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

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



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

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.

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")?

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.

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.

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.

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.

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 ). If not, don't worry about it being out of order later.

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.


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.

SxROM


Mostly I was drawing an analogy between MMC6 and SOROM. Here's how MMC1 (iNES mapper 1) behaves:

More than 8K CHR ROM or RAM: CHR A16 selects CHR ROM page
8K CHR ROM or RAM: See below
SNROM: 8K PRG RAM, CHR A16 is a second enable for PRG RAM
SOROM: 8K+8K PRG RAM, CHR A15 enables one of two PRG RAM chips, #0 not battery backed, #1 battery backed
SUROM: 8K PRG RAM, CHR A16 selects a 256K half of a 512K PRG ROM
SXROM: 32K PRG RAM, CHR A15-A14 selects an 8K bank of PRG RAM, CHR A16 optionally selects a 256K half of a 512K PRG ROM

These are completely identifiable from ROM size and PRG RAM size. PRG RAM size is stored in one place for late iNES and another for NES 2.0, in part because very few emulators ended up supporting late iNES's PRG RAM size field. Emulators that don't support PRG RAM size bytes are using PRG ROM size to identify SUROM and CRCs to identify SOROM and SXROM.


My suggestion was "any with two SRAMs acts like MMC6", but after looking at it for a while, I guess it'd be better to explicitly indicate that a program uses independent enabling of halves of PRG RAM.

The more I look at this, the more annoying the current state of things seems to be. When I look at kevtris' original submappers draft (submapper.txt), it is very clear that the goal is disambiguating extant games that currently do CRC or other heuristic checks to select a mapper implementation. This is a usability improvement to the iNES mapper set, not an attempt to specify every hardware quirk that ever was.

When I look at the wiki page (NES 2.0 submappers) I see no goal or criteria as to how submappers are selected. Here's a short list of problems I can see at a glance, there's probably more:

• MMC1 half of kevtris' suggestions were confusingly "deprecated" because someone thinks the size fields should be used to select the mapper instead. (Why the hell are we already "deprecating" things? This is a new spec!) I've said before that I don't think size fields are an appropriate place to select a mapper, because it muddies the specification significantly.
• 002/003/007/UxROM/CNROM/AxROM proposes submappers for emulation of bus conflicts. Why? Does failing to emulate them cause a problem for any game?
• MMC3 - confusingly different than kevtris' original set. What happened to "hardware mirroring" and is this necessary for any games? I actually thought that MMC6 was the "poster child" for why we needed submappers and I thought it was bizarre to find it not on here. (It was assigned to submapper 1 in kevtris' original doc, and Nestopia UE actually implemented this already.) Why did we throw away both of kevtris' suggestions before reassigning the slots to new ones?
• MMC5 - what does "wishlist" mean? Does this have anything at all to do with compatibility with existing software?
• VRC4 - why would we want to create submappers for board permutations that don't exist?
• 34 - why did we discard the "union bond" mapper variation? Was it not used for anything?

Kevtris' document seems quite practical to me, and straightforward to implement. The version on the Wiki is currently unusable, and not even close to compatible with Kevtris' list. How do we expect to create a standard like this?

What I want to suggest again is that we treat this just like iNES mapper allocation. Find the problem case first, then create the submapper to resolve it. Don't create solutions to problems that don't exist. Submapper (and mapper) allocation must follow the needs of published software. This is not a wish-list. This is not a catalog of endless hardware variations. The wiki covers that kinda stuff in detail, and if anyone ever wants to make use of yet-unused board/mapper incompatibilities, publish the software that needs it first, then you can allocate the submapper.

As for whether PRG-RAM or other fields should be used to select a mapper implementation, I vote against this, but if it really is consensus I would accept it. I think the more additional steps of logic one has to compute when selecting a mapper implementation, the more difficult and confusing the specification becomes. I think Kevtris may have had the same reasoning.

(Similarly, I also think it's really dumb to call this "NES 2.0" instead of "iNES 2" but I'm not going to fight for a meaningless name change if this is really what we want to call this thing.)

Yes, the independent enabling is exactly what makes it MMC6.

Though, the problem I'm facing is not whether someone could theoretically build an MMC3 with 1k of PRG-RAM. The problem is that the wiki's "standard" is patently unusable, and conflicts with kevtris' other "standard", and there's no consensus between emulators that have tried to adopt NES 2.0. Because of this I can't possibly hack Startropics and have that hack run in existing emulators.

It's an arbitrary decision whether to use PRG-RAM size for disambiguation where possible, or whether to use submapper number, but you must realize that kevtris already made this decision, and changing it later and re-assigning those submappers works against the effort to establish a standard! Startropics was the poster child for why we needed NES 2.0 and it's been totally bunged up by this needless effort to avoid spending a submapper on it (??). I think it's an extremely bad idea to start putting special case logic in every time we could save a submapper allocation. The real world implementations of NES 2 mapper 1 and 4 are already in a bad way because of it.

The submappers aren't scarce, and the problem cases are very small! Of all the problem cases there seem to be fewer problem games than there are submapper slots, and even if we ran out (which we won't) we could just create a new NES 2.0 mapper to hold extra sub-mappers (presumably with the same low-8 value as the original).

Honestly I think we should scratch what's on the wiki, and start over from kevtris' document, adding only what is needed to solve existing problems that kevtris missed (or possibly correcting errors he made, if any).

I've made a proposal on the wiki: http://wiki.nesdev.com/w/index.php/Talk:NES_2.0_submappers#Major_revision_proposal

You want to know why the wiki's submappers definition differ from kevtris's?

Because I read his reference and decided it was patently unusable. They were underdescribed (Mindseeker + mapper 80), overfine (VRC4?), apply to non-existant things (see next ¶), and their release coincided with a time when he was taking a break from the forum.

The bonus fictitious mapper 78 variant? Doesn't exist. MMC3 TEROM/TFROM hardwired mirroring? Never used. The mapper 1 weirdness? His original draft was lousy with typoes. Mapper 32? Incomplete. The mapper 34 weirdness? On him.

It was necessary to throw the whole thing out and start with just a list of where things were needed. It contains more mistakes than useful starting points.

There are myriad documented games that rely on the presence/absence of bus conflicts on discrete logic mappers. You can search the wiki for them.

So, let's talk specifically about StarTropics.
1- There is no definition of MMC6 that makes sense with a PRG-RAM quantity other than 1 KiB.
1b- There is no definition of SUROM vs SNROM that makes sense without the latter having 512 KiB PRG-ROM; there is no definition of SNROM, SOROM, and SXROM that makes sense without those three having 8, 16, and 32 KiB of PRG-RAM.
2- The decision was made to allocate a field to specify the amount of PRG-RAM AS WELL AS a generic submapper field
3- Why specify the same exact information twice in the header ("This is StarTropics ... oh, and just in case you weren't paying attention, this is StarTropics")
3b- Why specify the same exact information twice in the header ("This is Titanic 1912 ... oh, and just in case you weren't paying attention, this is Titanic 1912")
3c- I'd repeat myself for all the S?ROM games, but ugh.


Finally, despite your complaint: The reason the NES 2.0 submappers haven't been deployed is EXCLUSIVELY because there isn't a ROM set that uses them. That's it. Nothing less, nothing more.

Anyway, Nintendulator already uses PRG RAM size to determine MMC1 behavior and the presence of RAM presence to handle Low G Man. And MESS implements everything as on the wiki ... except for MMC3, because I didn't decide on anything (other than that kevtris's recommendations were inadeuate) until after etabeta implemented things.

I may have screwed up.


I originally made these changes in the interest of denormalization, or removing redundant data to reduce possibility for inconsistency. The only truly distinguishable behavior is whether CHR A16 disables PRG RAM.

1. CHR A16 always goes to PRG ROM A18 if it exists.
2. CHR A15-A14 always go to PRG RAM A14-A13 if they exist.
3. CHR A15 selects from two PRG RAMs if both exist.
4. CHR A16 goes to PRG RAM /CE only on SNROM. Not making this a submapper is arguably my mistake.

It causes a problem for new homebrew games in development. It also is known to cause defects for mapper 144, which relies on ROM always winning the bus conflict on the D0 line.


I have removed the revised set for this mapper in favor of coming restoration of at least part of the original set.


Hardwired mirroring was available only on the TEROM and TFROM boards, and it was never actually used in any game on those boards. The games most likely to have used it use mapper 206 (Namco 108): Karnov, RBI Baseball (licensed version), and Ring King. But all were released on DEROM or DE1ROM instead.


I think "wishlist" means we haven't actually decided to assign codes yet.


Because I didn't know they didn't exist.


"iNES 2" is the name of a version of an emulator. This emulator does not support NES 2.0 format.


I can think of one definition (which I'm not proposing to fully implement):

MMC6-1K (existing): $7000 and $7200 can be enabled independently
MMC6-4K (hypothetical): $7000 and $7800 can be enabled independently

Okay, good, so you had some reasons to make the changes (except the "spelling mistakes" complaint, that's completely tangential and not really related to validity of a submapper). The problem I think we need to address is there is no documentation or accountability for this. i.e. a new user can't come in and find out why anything is in the state it's in, I'll get to my proposal to address this in a moment.


These games should actually be listed in the submappers article, which is part of what I'm about to propose below...


I think we already covered all of this in this thread already. This information was acknowledged. My opinion is that the implementation of a mapper should be selected exclusively by the mapper+submapper number, rather than adding a weirdo "look elsewhere in the file" rule wherever we could possibly save a submapper. It's a bad precedent that complicates the specification. I think it's more important to have a consistent use of fields in the specification than it is to eliminate every possible redundancy from them. I also think that making this arbitrary decision to change the method of mapper selection specifically breaks continuity with kevtris' earlier attempt to establish this specification, which I think is a bad thing. The spec can be functional either way, I suppose, but it was already started in the other way. We've also applied this change inconsistently ("deprecation" for mapper 1, complete reassignment for mapper 4), which makes it even worse.


My complaint was that I found a different implementation for this in Nestopia UE, Nintndulator, and puNES when I started looking into it. I'll take a look at MESS. "There isn't a ROM set that uses them" is a very good point, actually, but it isn't really the truth; it looks like many in-development emulators are trying to adopt iNES 2.0 already. The lack of standardization would be worked out by having some ROMs to test the implementation against, though, which would actually be great.


An emulator that nobody uses or ever refers to except in oblique "did you know" reference to the file format.


Let's not consider these things.


Okay, so with that response out of the way, I want to make my proposal. The problem as I'm looking at it is that it's not practical for anyone looking at the wiki page to understand 1. what is this submapper for? and 2. do I want to implement it?. These are important questions for an implementer, and it's not reasonable to make someone read hundreds of forum posts and wiki pages to learn these things. I made a proposal on the wiki about how to allocate new submappers in the future, but here are two immediate changes I would very strongly suggest:

1. Move anything that is speculative (e.g. wishlist, incomplete draft, etc.) off the article. The article should be a list of things that can be implemented now, not a nebulous warning of the future.
2. For every submapper, list the games that require it. This answers both questions I posed above.

If we did this, a new user (like me) looking at the article would be able to understand exactly why each submapper exists, what games to look at to test and understand the problem, and can evaluate whether it's even important for them to support those particular games. It would solve the chain of authority problem we're having by making the rationale for the submappers completely opaque.

The proposal for how to add new submappers was basically to maintain this standard of disclosure going forward, and to establish a process for evaluating it and maintaining continuity.

If there are 13 games that use a particular submapper, how shall they be listed? I have linked to a NesCartDB query that returns the list of 13.

We should limit the list to games that are incompatible with submapper 0, i.e. the games that would have required a CRC or other kludge to run.

For example, 001:5 suggests SEROM / SHROM / SH1ROM, which is a large list of games. Do all of these really fail on submapper 0? (I strongly suspect not, but requires more research.)

What I'm trying to do by listing the games is provide both the rationale for a submapper's existence, and also give the implementer a test case they can use to verify it. If a ROM technically uses that board variant but is compatible with submapper 0 it's counterproductive to list it.

... Here's your thread on it: viewtopic.php?t=8955


Nestopia only grew submapper support in the past month.
Nintendulator doesn't implement submappers at all.
MESS does according to the version of that page on the wiki as of 2014-01-xx.
I can't speak to puNES, since it's not open source.


Seriously? Your response to my entire argument is "I don't care" ?

Having the same information in the header twice is actually a serious complaint. So, fine, answer me this:
* An emulator author writes an emulator using kevtris's original standard.
* A ROM is marked as being MMC1 submapper 2, SOROM, but is marked as having 8+0 KiB of RAM
What is the correct behavior?
- Crash?
- Refuse to load the ROM because it's talking nonsense
- Assume the submapper is correct, and ignore the PRG-RAM size. If so, why on earth did kevtris add the PRG-RAM size field?
- Assume the PRG-RAM size is correct, and ignore the submapper #. If so, why on earth do we care what the submapper # is?

Analogy first: if I have a database table with configuration records, I'd much rather looking up a single record by primary key then by matching all the properties. PK is guaranteed unique, combination of field values are not necessarily so.

for iNES 1.0 roms, mapper is determined by major mapper # and deriving the particular variant by properties of the game. the is accepted as necessary but terrible right? The whole point of submappers for 2.0 was to avoid that business. Why ignore that in favor of a more complex method? If a major mapper # isn't sufficient to determine configuration, I'd rather have an explicit value telling me what it should be rather than trying to scope it out from one or more other properties.

And secondly, if there are some cases where we deem submapper necessary, the submapper should be the go-to for all cases where the major mapper isn't enough. Consistency is important. Submappers can define every variation ram+other properties that could ever be needed. Is the reverse guaranteed? I think you'd have a hard time proving that true.

Really if we settle on submappers as the authority, ram units will likely be redundant in many cases. I'm ok with that- it's easy enough to disregard in case a submapper is given. There may still be cases where it's useful, e.g. no submapper specified but the rom expects some amount of ram.

So in summary: explicitness and consistency are priority, and flexibility should also be maintained.

(Ninja'd twice)
Do programs incompatible with the existing submappers have to be games, or can they also be test ROMs?

Thank you, I will review this and try to add the relevant information to the wiki.


That was a direct response to tepples proposing an MMC6 with oversize PRG-RAM, and not to anything else. I'm sorry for the confusion.


If the header is inconsistent, behaviour is unspecified. The implementer can choose how to handle this, it's not important for us to specify what happens in response to every possible header, only what happens in response to well-formed headers.

My primary objection to the change is that I think the mapper functions like what registers do should always be specified in the same place. My secondary objection is that it contradicted the precedent kevtris' original implementation set.

I presumed the PRG-RAM size field is to differentiate mappers that have the same register set but different PRG-RAM sizes, just like there are plenty of mappers with the same or compatible registers sets but different PRG-ROM sizes (e.g. MMC3 with no PRG-RAM vs MMC with PRG-RAM). That's what its purpose looks like to me, at first glance, but you are asking for it to also be part of the selection of register function (as well as other size fields).

What I actually propose is that we should have both in the spec. Put a submapper for each of the MMC1 size variants, and for MMC6, and advise that both should be specified together. An implementer can choose to override the submapper choice with size fields if they choose, or vice versa. The redundancy supports both approaches if the headers are well formed, and honestly I would not expect malformed headers to be a problem anyway (we actually have a central hub to disseminate information here, it's not like the iNES 1 days anymore).

If a submapper's only reason for being is to run a test ROM, I don't really understand why anyone would want to implement it...

However, I don't want to quibble about the definition of what constitutes a "test ROM". If there is a published ROM that requires a submapper for support, it's probably worth listing.

Mostly I'm trying to understand your view on resolving the chicken-and-egg issue inherent in creating a new mapper. At one point during the creation of a new mapper for the Action 53 project, I was at that point: "I have a game in progress. Here are screenshots of the game running on an existing mapper with reduced features, as well as a spec and test ROM for a new mapper or submapper. Implementing the new mapper would allow all features to be implemented." Should someone in this situation obtain a compiler, learn C, and modify an existing emulator?

Okay, I've made a large revision to the wiki page: http://wiki.nesdev.com/w/index.php/NES_2.0_submappers (diff)

1. Moved any implementation that is unimplementable or speculative to a proposal page. This included stuff that was "wishlist", merely trying to open discussion, or otherwise didn't have any submapper assignments or

2. Added game examples for everything that I could find information on so far.

3. Attempted to format everything in a consistent way.

I believe these changes have made no actual change to the specification as-is, I'm merely trying to reorganize the information. Tepples did change the MMC3 assignment, which was a response to my request, but otherwise everything is the same. My intent is that the wiki page should always be ready for implementation and that proposals and future changes should be done elsewhere.

If anyone wants to implement a new mapper, they should do it themselves first. Hack an emulator or otherwise create an implementation that they can use to develop with, and finally publish a ROM that requires it before asking for a mapper allocation.

If someone wants to directly approach maintainers of emulators and ask them to pre-emptively implement something for them, that implementer can make an evaluation about whether it's worthwhile (just like they can evaluate any part of the spec and implement it or not). It is up to the emulator author whether they would do that kind of thing. This mostly has to do with what kind of faith they might have in the person making the request, I suppose.

My interest is that the allocation process should be clear-cut. Publish the software first, then allocate the mapper in the specification. The specification should follow existing material (i.e. this it not chicken vs. egg, the ROMs are the source and reason to implement).

People should not be adding things to the spec in lieu of asking someone for help in hacking an emulator for their needs, or developing some kind of relationship with emulator authors. Adding your wishlist mapper to the spec is a detriment to that spec until there is some ROM that an implementer can actually run with it.

Guess I should weigh in. I created the whole submapper thing to eliminate the need for CRC checking and other hacks on the existing roms. There is no way in the world to ever come up with a perfect "100% all inclusive" format that could account for anything ever new that showed up. I attempted to make additions that would benefit emulator writers and for my FPGA NES.

In fact, the spec doc I wrote is how my FPGA NES implements it. And probably this is how it always will implement it. I noticed on the wiki that someone came up with a whole set of extended mapper numbers for things like homebrews and hacks; this is exactly the kind of thing I did NOT want to happen with extra mappers. This is just another willy-nilly mapper number mess like what exists currently with the 256 we already have.

I do not like hacks to determine what kind of mapper/ROM/etc a game is, including CRCs, ROM sizes, and other things which are not extensible to new stuff that might appear (be it more games, or homebrews, etc). If you rely on CRCs or ROM sizes and someone hacks a game to include more levels, etc. (or just some other kind of minor hack) it will no longer work because the ROM size changed, or the CRC changed.

So that was the rationale for it all along- disambiguating existing stuff and with support for all the newer stuff I had ever come across up to that point. The idea was only a few percent (say, 2-3% at most) of existing ROMs would need to be modified so they could be disambiguated. In fact, the header was designed so if the ROM was run on a "Regular" emulator it'd still run as it always did.

Given this forthcoming flash cart whose mappers are compiled from the same source, I guess we ought to defer to you to some extent. This is why I've tried to seek your input in #nesdev on submapper proposals.


CRC I agree with. But if the ROM size changed, then it's often supposed to go on a different board. For example, expanding a 256K SNROM game to SUROM means that at a minimum, 1. the reset code needs to be fixed carefully to clear CHR A16 if the game powers up in the second 256K, and 2. the game needs to not rely on CHR A16 disabling PRG RAM. This is why I suggested guessing SUROM, SOROM, and SXROM behavior based on memory sizes. Besides, even in "submapper 0", CHR A16 is a PRG RAM disable bit only if CHR size is 8K (SNROM), not larger (SLROM).

I think "guessing" is the wrong approach. If the header has a bad/inconsistent specification, it's just a bad ROM, and it's allowed to crash or do other stupid things. We don't need to be able to recover from bad headers; we just need to be able to handle the things that the old headers couldn't specify.

I didn't spot this earlier because I misread the tables when I was trying to understand earlier, but now that I've looked at it again I'm very confused about the SUROM, SOROM, SXROM submappers. What is it that makes them mutually incompatible?

By the description here I don't see any inconsistency between how each of them uses the bits, i.e. they just become a disconnect/mirror if the connected RAM/ROM isn't large enough, just like we do with any mapper that has support for variable sizes.



What am I missing? Why is this 3 submappers and not 1? (This looks VERY different than the MMC6 situation, in which the bits of the register have different functions.)

I get (and am sympathetic to) your point: the 16 bits of mapper and submapper should represent a fixed ABI... but...

So, that's a vote for "crash". With bonus "possibly yielding an exploitable surface for arbitrary code execution when the emulated 6502 VM uses an unallocated pointer".

I'm not talking about "typical" usage here. The set of four choices I gave was not a request for which behavior we should recommend.

My entire point is the observation that permitting the header to contradict itself is asking for trouble: designing things to explicitly expose pointy bits is asking for people to hurt themselves.

No, it's not a vote for crash. When I say it should be "unspecified" this is a vote for it to be the implementer's choice how to handle an inconsistency.

If a crash or insecurity is not a problem for the implementer, it is a valid choice for them to make. If these things are a problem, they will figure out how to prevent it.


Those four choices are outside the scope of the specification. The spec isn't telling them whether it's executing on an NES, flash cart, VM, Mac, Windows, whatever. That's entirely irrelevant to the goal of being able to specify the stuff needed to run a ROM. That's their choice, not mine, and not yours.


All of the pointy bits are put there by the implementer, not by this spec. This concern is outside the realm of what we are doing here.


Anyhow, this has gotten far too ideological. I think I have heard your argument and you have heard mine about whether MMC6 should have a submapper assignment. Argument has clearly been unconvincing for either of us. What form of authority would you suggest we defer to instead?

SNROM is the only one with an actual behavior difference. CHR A16 (the "P" bit) can be one of three things:

1. A16 of 128K CHR ROM or RAM, disconnected if smaller
2. A18 of 512K PRG ROM, disconnected if smaller
3. Disable PRG RAM, disconnected if PRG ROM larger than 256K or PRG ROM larger than 8K

Yet SNROM never received a submapper allocation. I presume this is because the PRG-RAM enable is redundant and unnecessary for compatibility? I've added notes on how the SXROM submapper is a superset of SUROM and SOROM to the wiki to make it clearer how they are related.


None of the extended mappers have been allocated, so I'm not really sure what "mess" you're referring to?

Personally I've been advocating the stance that the software must come before an allocation. If there's no ROM that needs it to run, don't allocate it. This actually puts a pretty big barrier to new mapper allocation, because people aren't nearly as good at making software as they are coming up with ideas for new mappers. So... no allocations so far.


Now that kevtris' assignments for MMC3 have been re-instated, the wiki version of the spec appears to be fully compatible with kevtris' original document, so I don't think we have a problem yet. I moved everything that was unimplementable to "proposals", which cut us down to what is mostly a subset of the kevtris version.

Here are the things we have added w.r.t. kevtris' proposal:

• 001:5 - fixed 32k PRG for MMC1. I haven't tested all the games yet, but it seems that in at least some cases simply initializing the PRG banks in NROM order at load is already sufficient for compatibility with submapper 0. This might even be true for all of the games?
• 068:1 - Sunsoft Dual Cartridge System for Nantettatte!! Baseball.
• 210:1 - Namco 175 specification to remove the need for heuristic detection.
• 210:2 - Namco 340 specification to remove the need for heuristic detection.

Here are the things we have removed:

• 001:3 - Deprecated because this is already iNES 155.
• 004:2 - Not removed, but requirement for hard-wired mapping of MMC3 unclear. (Any games?)
• 016:1 - Bandai FCG.
• 016:2 - ? (No description.)
• 016:3 - ? (No description.)
• 019:1 - N106 Mindseeker.
• 034:1 - NINA-01. (Isn't Impossible Mission 2 is already compatible with 034:0?)
• 034:2 - Union Bond (Does anybody know what this means?)
• 065:1 - ? (Insufficient description.)
• 078:2 - Fixed vertical + WRAM. (Not needed for any game? NES 2.0 lets us specify WRAM already too?)
• 080:? - Description says they were moved to mapper 207.
• 083:1 - Cony with 2k CHR banking.
• 083:2 - Cony with other modifications.
• 166:? - Description says it is really mapper 27.
• 167:1 - ? (No description.)
• 188:1 - 256k PRG Karaoke ROMs.
• 245:1 - Flat CHR RAM.

So, many of these are insufficiently described to implement. Maybe some of them can be included. By the same criteria that I outlined for allocating mappers, I think we should treat these the same.
1. Explain what game/ROM needs a submapper to run.
2. Sufficiently describe the submapper implementation.
3. Let someone else verify that it is needed, and the implementation works.
4. Allocate the submapper, and keep an eye on backward compatibility. (If kevtris already had it, don't reassign.)

As long as we do this going forward, I don't really see a conflict with kevtris' original spec. If we don't have a known use case for one of kevtris' suggestions, there's no reason to put it in the spec (it can't be implemented until we know what it is, right?). If anybody comes up with something that needs a submapper, explain what it is and we should add it. Pretty simple.

Anything kevtris pre-emptively added because they might be nice for homebrew can wait until that homebrew exists before we add it to the spec. The spec isn't preventing people from trying any new mapper idea they want, and it'll still be here if and when any software is made for that new mapper. The wiki is living and changing, and a central source for this, there's no need to try to guess the future here because we can easily add it when we get there.

Is the Quattro submapper necessary? According to the NES Cart DB, both the standalone cartridge release and the Aladdin Deck Enhancer release of Adventure and Sports use the same ROM.

Also, for the discrete logic mappers with bus conflicts like UNROM and CNROM, iNES 2.0 does not seem to be able to tell the emulator that this game needs not to have bus conflicts.

The default implementation is not to have bus conflicts.

If there are games that require bus conflicts to be able to run correctly, please list them.

Bootgod's CRCs for the quattro games being the same is interesting. Does anyone have the relevant ROMs to elaborate on the problem?

Requiring specific power-on values that don't come from the hardware is asking for problems.
It's vital to understand that the original hardware MUST be the authoritative version, and adding hacks like this to fake the right behavior will result in romhacks, translations, and homebrew that can't run on the hardware that they're theoretically designed for.
This is the same reason why MMC3 must be capped to 512 KiB—not because we can't make something that looks like an MMC3 that supports more, but because the original hardware must be the reference implementation.

Relatedly:
That is patently false. The default implementation DOES have bus conflicts, both in hardware, and in more recent emulators that implement these bus conflicts to keep people from hurting themselves on derivative works.

There's at least one instance documented on the wiki page for mapper 003. (as distinct from the page for CNROM)

Anyway, this is the same point. It is absolutely vital that these emulators emulate the hardware as it existed, not an abstracted idealized version of the hardware. Otherwise, there'd be nothing wrong with creating things that only ever worked on Nesticle.

Union Bond (a developer)'s mapper seems to be oversize BNROM with PRG-RAM. I don't see why it needs a submapper.
Has to be referring to Fudou Myouou Den. I have no idea why it's plural.
I'm pretty certain those things weren't in kevtris's page when the information was copied to the wiki.

----------

But that's exactly what abstention is, here. Of those four, any implementor can ONLY (consciously or subconsciously) pick one of those four results. And the "crash" choice is the most naïve choice, the one that would happen from what happens if a person doesn't think about it and just makes code that says "Oh, ok, 8KiB of PRG-RAM is marked, allocate 8KiB of RAM" and "Oh, ok, SXROM, I'll index into a 32KiB array".

If you vote to allow contradiction, and don't warn in giant blinking letters HEY THERE COULD BE A PROBLEM HERE YOU SHOULD KEEP IT FROM HAPPENING BECAUSE SOMEONE WANTED TO ALLOW THE FORMAT TO CONTRADICT ITSELF someone WILL implement it poorly. When, not if.

So, should we explicitly add that warning label to the submapper page? (Is it fair to say that you're arguing that that is that an acceptable cost for your clean 16-bit-UID-as-ABI-version ?)

People don't intentionally write bugs (bug bounties notwithstanding). People don't intentionally write vulnerabilities (bribes and the underhanded C contest notwithstanding).

And people usually assume that their not-explicitly-security-based software will not be used in a location where such a vulnerability could be exploited. (e.g. the libtiff and libpng vulnerabilities)
Specifications have sharp edges. Implementations have bugs. Sharp edges in specifications cause bugs in implementations. A vote to explicitly allow the format to contradict itself is a vote to create bugs later on.

Evidently not kevtris, since you've realized many of his submappers don't even mark a different ABI, nevermind my argument of whether the header should be allowed to contradict itself.

The chip markings on the Aladdin Deck Enhancer carts match the ones on the standalone carts, so I would guess that the Aladdin Deck Enhancer Quattro carts may scramble the game selections, but otherwise should have no effect.

As far as bus conflicts go, Donkey Kong Original Edition, the official Nintendo hack of Donkey Kong that adds the Cement Factory level into the game and was included with certain Wii consoles, requires bus conflicts to be disabled.

Well, there's different format goals. iNES was a compatibility format, lumping compatible boards together where it's convenient to implement them together. Actually, I think this kind of stuff is a good reason to use UNIF. UNIF's goal was accuracy by being very specific about the hardware that it wants emulated.

Specifying a power-on value for 32k MMC1 isn't really asking for problems at all in any practical case. There's only two obscure games that don't, and it doesn't break compatibility with them, or MMC1 games of any other size. It breaks accuracy with them in exactly the same way that emulators break accuracy with most games by initializing RAM, or a myriad of other things. This seems rather trivial and not worth specifying a submapper for. There doesn't seem to be an existing problem with running the 32k MMC1 games and the original iNES format; nobody is doing a CRC check to support them, as far as I can tell, so it seems unlikely that anyone would want to adopt that submapper to solve a problem they don't have.

iNES' goal of compatibility rather than accuracy is actually one of its biggest strengths. It's a big reason why it was more practical to implement than UNIF. Maybe a hundred mapper implementations instead of a thousand board implementations?

I'll put it another way, if somebody needs thorough validation tools for homebrewing, they should go ahead and build those things, but iNES is a terrible place to try and stuff all those needs. It began life as a compatibility format, and it would be a colossal mess to try and turn it into something that can specify every hardware quirk. You're proposing to change a format that was born for one purpose into something completely different. NES 2.0 is a compatibility patch for iNES, not a total change of direction.


Sorry, I misstepped there. I lost track of which mappers we're talking about. For boards that have both bus-conflict and non-bus-conflict versions, no bus conflict has been the default, has it not? If all boards for a mapper had bus conflicts, then yes that is the proper default (and it should be specified in our definition/description of that mapper-- nothing to do with NES 2.0, the iNES 1 version of the mapper should do it).


So for mapper 3 the question should be the opposite. Are there any mapper 3 games that require no bus conflicts? If yes, we should propose the submapper for this. If not, we don't need it yet.


Hmm, well if it writes values to the last 3 bytes of PRG-RAM it would conflict with the NINA-01 + BxROM mapper 34 implementation, so that could require the submapper. Anyhow, until somebody can come up with the ROM that needs it I don't think we should worry about it.

Okay, so in response to this change allocating 3 submappers for VRC2/VRC4:

• 023: 8 - this one I don't understand the description of. Is this a compatibility issue for "World Hero"?
• 023: 15 - the mapper articles claim that this is already compatible with the existing PRG-RAM implementation, i.e. it's not a compatibility issue.
• 025: 15 - the description claims that the one extant ROM is already compatible with submapper 0. This is future proofing against a romhack that wants to add an IRQ? I strongly suggest that we should not do this.

Both of 023:15 / 025:15 are clearly invalid by the criteria I think we should be using for submapper allocation, and 023: 8 has a very opaque description so I will need further clarification to understand what it is. The ROMs listed are said to be compatible already, so they're clearly not a valid test case to verify a correct submapper implementation.

This is really digging at what I was just saying about format goals re: compatibility or accuracy. If it's not currently incompatible, it really doesn't need a submapper. We should be solving existing CRC and heuristic problems, or possibly accomodating existing romhacks. We should NOT be future proofing against potential romhacks. It's a waste of our time. (Make the romhack first! We need a test case before it's worth implementing.)

Again, I think emulation accuracy tools for homebrewers and hackers are a wonderful thing to have and I would love to use them, but I think this is a completely different goal than NES 2.0, and should not be shoehorned into it. It seems that lidnariq and I have somewhat mutually exclusive goals here, and some consensus from others on how to proceed would be very helpful I think. I do not wish to engage in an edit war, as that will be simultaneously detrimental to both lidnariq's goals and my own.

Yes, there are both mapper 3 things that require the presence and absence. That's why I put CNROM in the list on the page.

And yes, emulators are beginning to move towards "discrete logic mappers enforce bus conflicts by default", even in iNES1 images.

Looks like Titanic 1912 and/or Darkseed.

It is incorrect to provide PRG RAM to a game whose header says it does not have PRG RAM.

For the compatibility argument, there are only seven original games that require NES2.0's PRG RAM field. They are:
* Low G Man and/or StarTropics, because the former is the only game that requires the absence of RAM (but it uses the MMC3's PRG RAM disable) and the entire problem here is due to the MMC3/MMC6 PRG RAM protection differences
* The games that used SXROM and SOROM. (FF1+2, Best Play Pro Yakyuu, Genghis Khan, Nobunaga's Ambition, Romance of the Three Kingdoms)

Every other game could be safely emulated with 8 KiB of PRG RAM, except:
* Those that use MMC5, which needs somewhere between 32 and 64 depending on just how klever you're being.
* Those that use Bandai's LZ93D50 with I²C EEPROMs, where they need 128, 256, or 128+256 bytes of EEPROM, but this division is already accurately handled by the three assigned iNES1 mappers.

These seven games are a small enough list that marking this set of games could easily have fit in the submapper field. Since it was NOT put in the submapper field, I can only conclude that the intent of the field was to accurately represent the amount of nonvolatile storage on the cartridge. And, therefore, I have to conclude that a "compatibility" implementation is against the spirit of NES2.0, at the very least for the PRG RAM size field.

Basically, my opinion is that this emulation container should handle both the "simple emulators" use case, as well as people making reproductions, as well as people making ROM hacks. And that means we can't just implement the lowest common denominator, but must enforce extra restrictions to keep people from assuming things that happen to be false.

Why is it incorrect? That implementation flawlessly supports the ROM. It really doesn't matter whether it came on a VRC2 or VRC4 board, or whether it was a glob top or DIP, whether the PCB was red or green. It's still a completely valid setup to run that ROM. You're asking for a unique mapper to add support for a game that already has support.

I appreciate the desire for emulation tools that can really verify hardware accuracy. I've said before and I'll say it again, I want an emulator like that too. An emulator that I can go into the options and say "run this as if it was board X with jumper Y etc." and have it flawlessly validate whether it would run on that board. That would be a cool tool.

The thing is, only a very small group of people need that. Millions of people play NES emulators, and almost all of them have the primary concern of "will it play my games?" The question of "what would happen if I put this ROM in my Genghis Khan cartridge" is an incredibly niche concern, and requires a few metric shit-tons of meticulous implementation and testing to provide. Almost nobody would even think of trying to implement all of this crap, and if we put all of it in the NES 2.0 spec, it will be very poorly adopted. Quite frankly I think you're destroying the NES 2.0 format by trying to put this burden on it.

I would really love someone to build the meticulous hardware-oriented emulator tool. They don't need an NES 2.0 specification to do it, though. They can get to work on that right now. It really has nothing at all to do with NES 2.0... why do you want this format to do all that?

It's very clear that kevtris' intent was to make a format that was a practical extension to the existing format to get those last handful of problem games running. It wasn't supposed to do any more than that, and it really shouldn't if we expect it to be adopted. Every unnecessary submapper that is added makes more work for the implementers, and retards proliferation of the format. Creating a schism by making a parallel spec with the same name that's incompatible with whatever kevtris is up to just makes the situation worse. It's... ugh.

This is very frustrating. Like, I know what you want, but it's extremely impractical to expect this specification to solve that problem. Specifying the hardware details doesn't make the emulator that implements them appear. If you want that emulator, just build it. Build the shit out of it. I want to see that emulator. Arguing about the NES 2.0 specification doesn't make that magical tool any easier to implement. It just makes the NES 2.0 specification harder to implement, and more obscure than it already is.

The exact same argument holds for StarTropics in an emulator that doesn't implement the MMC3/6 protection registers.


And the people who just want to play their games can safely just use Nesticle. Nesticle is phenomenally inaccurate, but it is wonderfully compatible.

The first 16 mappers gets 80% of the NES and Famicom library. Old crappy iNES files, only mappers 0 through 15, no ability to mark Vs. System or Playchoice. The full iNES1 definition gets us up to 95%. Compatibility is basically a solved problem...

But an emulator cannot be wholly separated from a development tool. People DO test with the emulator that they play their games with. And so the emulator must implement the same restrictions as the hardware... because otherwise these people aren't developing software for the NES/FC, but instead are developing software for Nesticle.

And part of "implementing the same restrictions as the hardware" requires knowing what those restrictions are. And knowing what those restrictions are requires encoding it somewhere. And that somewhere can only be either a hash lookup table, or metadata that is bundled with the image.

That's a heavy accusation and pretty blatantly unjustifiable. There's plenty of instances of people who have implemented NES2.0, submappers or no, and it's not incrementally a greater load than implementing the 200+ mappers already present.

On the other hand, deciding that the submappers page was horrible and needed to be gutted? Yeah, suddenly changing things like that pretty clearly is a problem.

Then spare a sentence to conjecture why you think he added the PRG-RAM size field. Explain to me how my logic is flawed, or what concept I'm missing.

Or if Kevtris wants to answer, I'd happily accept his explanation. Even better if he additionally explains his allocation of submappers 19.1, 34.*, and 78.2.

Yes, I think that is a pretty good solution, actually, but it was inconsistently adopted. The submapper is a good solution to the difference of opinion, I think. A practical way to fix the issue.


Could you treat this discussion with more respect, please?


I didn't "gut" the page. Most of the information is exactly the same as it was before. I moved ones that seemed to be unimplementable, or in some "draft" state to the proposals page. All that info is still there on the proposals page too! Nothing at all has been removed, just transferred to another place so that we can keep "work in progress" stuff bubbling somewhere else until it's stable and ready to implement.

The transfer of VRC2/4 to proposals was made in good faith that it wasn't finished yet (and it looks very unfinished in the state you moved it back to the page).

Most of my work on the page was simply to add description of the allocations that exist, add games lists to explain why those allocations exist, and uniform formatting for organization.


It's not a big mystery why PRG RAM was added to the format. It seemed like a field with practical use so he added it. This isn't some hyper-elegant attempt to minimally specify every existing game with not a wasted bit anywhere. He thought being able to know if a game has no WRAM, 8k WRAM, or other WRAM size would help being able to emulate them correctly.

Its intent wasn't for mapper selection at all, which kevtris stated clearly a little while back, even though it's obviously dependent on mapper. WRAM sizes, especially when it's battery backed, can be helpful for emulators and tools that need to manage save files, for example. I think it's useful additional information, rather than inferring it from mapper or other heuristic info.

Especially now that FME-7 is known to support large PRG RAM and tpw_rules has been working on a program that makes use of it.

As far as I can tell, you're arguing that compatibility is one of the foremost objectives here. Compatibility requires imprecision. Precision is necessary for accuracy.

The entire reason for the wiki's Program compatibility article is to demonstrate this: these programs were made by testing against emulators that were more compatible (they implemented a superset of the NES that had the various gotchas elided) and therefore less accurate.

Yes, it's unfair to exaggerate and use Nesticle here, but it's only a straw man in the sense that it's an exaggeration of FCEUX's inaccuracies. And I'm serious when I say that for just playing games, it really was adequately accurate, because SMB1 was a fairly grueling test of raster effects, $2007 delay, sprite 0 hit, and so on. But no-one would say that Nesticle was accurate in any absolute sense—especially not for development.

An emulator that allows writing to CHR/NT during rendering produces homebrew that assumes that it can write to CHR/NT during rendering.
An emulator that doesn't enforce bus conflicts produces homebrew that assumes the absence of bus conflicts.
An emulator that doesn't emulate DPCM glitches produces homebrew that assumes the absence of DPCM glitches.
An emulator that always provides 8 KiB of RAM mapped from $6000-$7FFF produces homebrew and translations that assume it has that RAM.
An emulator that doesn't implement MMC3's protection register AND always provides 8 KiB of RAM produces conspicuously wrong music in Low G Man.
An emulator that conflates VRC4 variants produces translations that randomly pick a different set of mirrors relative to the game.
&c.

Is this about emulated them correctly, which can only mean accurately, or is this about emulating them compatibly?

If the objective is compatibility, denoting that piece of information is superfluous. No Famicom game relies on or detects mirrors for the few games released with a 2 KiB PRG RAM, nor does any MMC5 game. The only place this matters at all is for the different ABIs for Generic MMC1 vs SNROM vs SXROM/SOROM/SUROM.

As far as "helping", a lookup table of
Mapper 1, submapper 2: 16384
Mapper 1, submapper 4: 32768
is really not significantly different than
Mapper 1, PRGRAM=0x77 or 0x80 or 0x08: 16384
Mapper 1, PRGRAM=0x90 or 0x09: 32768

On the other hand, if the objective is accuracy, it's necessary to encode the actual set of restrictions that comes from the exact hardware and to precisely enforce them. And stating that VRC2 on PCB 350926 has 1 bit of "RAM", or that VRC4 PCBs 352396 and 351406 has 2 KiB of RAM that can be addressed at $6000 and $6800 but not at $7000 or $7800 is precise.

That's an ex-post-facto justification, so not really relevant to my argument...

Sounds like you guys are getting a bit off track with emulator accuracy vs compatibility. The iNES header represents the configuration of a particular hardware setup in cart the accompanying program runs on. In this regard I believe it should be as explicit as possible, i.e. as many submappers defined as necessary to eliminate ambiguity and deduction. How well any given emulator honors the stated config is another issue, but ideally iNES should make it absolutely clear what the config is.

I might need to clarify what I mean. I'm using this specific definition of compatibility and accuracy:

• Compatibility means "necessary to run existing games correctly."
• Accurate means "try to represent the specific original hardware as closely as practical".

Tepples wrote a relevant definition on the wiki, where compatibility means "correct output with known ROMs", and accuracy means "correct output with unknown ROMs".

I think compatibility is a much clearer goal. The test for whether a submapper is needed is easy: for the game in question, will any of the existing ones already produce the correct output? The second part of this is that it demonstrates why someone would want to implement it, i.e. if you do this your emulator will be able to run a specific game. The third part of this is that the game provides a test ROM for correctness. If you can verify that your emulator produces correct output for the game, you know it's correctly implemented.

Accuracy on the other hand I don't think is a practical goal for this format. If you create a submapper for VRC2c, you can't test it with any existing games. Ganbare Goemon Gaiden is going to look the same with or without the IRQ. This bit of accuracy has no practical test yet. You could easily make a mistake when implementing it if you don't have a test ROM; especially if you're implementing 100 little features at once like this and not testing any of them.

And hey, if you want to make the test ROM for a proposed submapper, do it. Do it first, though, don't just put it in the spec and then expect somebody else to do it for you. This is basically my entire suggestion for arbitration. If there's no ROM that can demonstrate the difference yet, don't add it to the spec.

So, the "why should I implement this?" question for accuracy is, "in case homebrew wants to use it in the future, I want to help them with development" which is a nice thought but it's impractical to think you can cover every way that a new programmer can fail simply with a file format specificatoin, or perhaps "in case somebody finds an undiscovered VRC2c game that relies on the non-existence of IRQ". I think this is getting rather obscure and unnecessary. Compatibility as a goal keeps the spec compact and gives a clear guideline for what to implement, and what you're supposed to get for implementing it. Accuracy is more of a lifelong pursuit with no clear boundaries.


I love all the great hardware/accuracy descriptions that the wiki has (and it continually grows); this stuff is wonderful. An emulator with an option to turn on bus conflicts, PPU rendering address conflicts, enforcement of other weird rules that aren't needed for compatibility would be AWESOME. I just don't think this is a good goal for NES 2.0 specifically. iNES certainly wasn't aiming for that, and kevtris' goal was to extend iNES; he said as much a few posts back, it was explicitly compatibility (plus a few arbitrary extra things he wanted).

The stuff currently in the article (with the exceptions of VRC2/VRC4, and SEROM/SHROM) all have test cases, and nothing re-assigns any of kevtris' assignments now that Tepples re-instated MMC6. The stuff that kevtris allocated that doesn't have any test cases yet should be left out of the spec until they get used in the future someday. It's not like we can't add things in the future as they happen. Same deal with all that proposal stuff. If there's no test ROM, leave it out. For stuff that's not in kevtris' spec, I see no problem with us allocating new things that he didn't think of, just so long as we don't reassign his original ones. There's plenty of room here. Same deal with the WRAM fields; leave things in a way that's compatible with kevtris' version; it's really not hard to accomodate this. There's no need for a format schism.


TLDR version, this is really what I'm getting at:

1. A test case, like a game that won't run without it, or even a test ROM should be a minimum standard requirement before allocating a submapper.
2. Don't redesign kevtris' format or reassign older allocations.

I get what you're saying now. I supposed I'd mostly support compatibility.

On VRC2c, I think I disagree with you. We have a hard example, and that should be accounted for somewhere. If an emulator chooses to support that by using the generic VRC core rather than VRC2c strict, that's the author's decision. If I were personally writing an emulator my goal would be strictness, and I'd want to know the actual cart config is VRC2c. It seems like a bad idea to omit that info when it could be clearly provided.

Otherwise I would agree on declining new assignments without a test rom or physical cart.

What's the example for VRC2c? Ganbare Goemon Gaiden is reported to be compatible with the VRC4 default. Is there another game that breaks if you don't emulate it as strict VRC2c?

There isn't one, but since it's a known quantity I think it should be identified as such.

After reviewing your an my posts, I'll have to correct myself and say I lean towards accuracy as preferred, but maintaining flexibility. We don't have to limit ourselves to only known hardware cases, but anything known should be at least specified as such. And again if an emulator author chooses to support that with a generic implementation so long as there's no case to force the strict implementation, I can't argue with that.

Also I think it's bad that we've overspecified the submappers for VRC2/VRC4. 45 assignments have been made for only 8 existing variations, and the VRC2-only specification only has one possible assignment (in 2 cases already used up). I think it would be a lot better to just assign submappers 0,1,2,3 to the existing cases instead of devising a scheme to accomodate fictitious ones.

Since VRC2/VRC4 wasn't in kevtris' original set and there are no current test cases, I would presume this is still open for debate, but if we want to stick with it I wouldn't fight it. Just saying I think it's a bad idea.

Are you referring to deriving the submapper from the address line numbers? If so I'd agree that's overly complicated, and handing out submapper assignments in order for known cases would be preferable. Maybe leave a few blank spots between vrc4/2 groups, e.g. vrc4 starts at 1 and vrc2 start at 10 or so, as a sort of logical grouping. That's mostly for human readers.

This is an aside but it looks like VRC4 and VRC2 are labeling the address lines in opposing fashion. In particular VRC4 seems to have the line numbers flipped if we're looking at the VRC4 page for reference.

Yes, I've been trying to make it very explicit what each submapper is required for. I think I've done this for each of the submappers currently in there and I'd like to see this standard applied in every one that gets added.

What I'm really after is that the spec on the wiki should be in an implementable state, and part of that means already proven and testable. Every allocation is a request that many emulators should implement it. I don't think it's too much to ask that a person make and test ONE working implementation of it before they request many implementers to go at it. (It's also important for consistency and correctness.)

Like, I don't really want to quibble about ideology for whether this or that variation needs a specification. That's thoroughly exhausting (and seems rather fruitless so far). If there's a ROM for it, go ahead I guess, but just run it by people first so we make sure it's not already covered, or improperly described, etc. and keep continuity with earlier versions of the spec.

Here is my alternative proposal for VRC2/VRC4 submapper assignment: Wiki: VRC2 / VRC4 alternative submapper assignment

It reserves exactly 4 assignments per board. 2 for the addressing scheme x 2 for VRC2/VRC4. This covers everything that exists and provides a space for any future undiscovered VRC2 on those boards.

I don't see the point of allocating any other addressing schemes, since those wouldn't be related to the underlying iNES mapper anyway. A new addressing scheme should get a new mapper allocation, not a submapper on an existing one.

Somehow I'd gotten the impression that VRC4 was kevtris's doing, not tepples's. Nonetheless, kevtris did give his thumbs up for it. I am definitely happier not having allocated all fifteen submappers, but we'll need to notify and/or push a patch to the people who have already implemented the loquacious version.

Anyway, I should go ahead and finish that VRC2/4 validation test ROM set, because I've wanted one for a while.

This appears to be MESS and Nestopia UE.

From what I can gather from open source searches:
- MESS implements "everything", more or less
- Nestopia UE implements three submappers (MMC6 004:1, and both VRC2 submappers)
- Bizhawk reads but doesn't use the submapper field
- Nintendulator reads but doesn't use the submapper field
- FCEUX reads but doesn't use the submapper field

I'd like to suggest BNROM get its own submapper value. NINA has its own, and submapper 0 can the compatibility implementation. This is similar to how VRC2c gets its own submapper without a strict test program, by virtue of the hardware existing.

Yeah, there's a proposal already for mapper 34, since it was already in kevtris' spec anyway. I added a BNROM solo to the proposal. It just needs test ROMs, really.

Holy Diver Batman
[ download | discuss ]

Run it on a BNROM-compatible board with PRG RAM. It'll mess up if the emulator implements overlapping BNROM and NINA. (You may need to hex edit its header to match the submapper proposal.)

Since there seems to be a desire for validation tests, here's one for SEROM/SHROM/SH1ROM:

Here's two test ROMs for mapper 34.

Famicom AV + InviteNES flashcart.

Your InviteNES appears to be crashing during the BNROM bus conflicts test (see test_bbus in the source code). My guess is that it produces the bus conflicts, but doesn't properly mask the ROM address to match the size of the ROM available, so STA to a location containing $FF switches to some out-of-ROM bank and it crashes? It didn't even detect any bankswitching in the previous test, though, so... ? Does it even run any BNROM games, or the NINA-001 game?

It runs Impossible Mission 2.

Here's test ROMs for the proposed mapper 3 submappers. (i.e. CNROM-like, with or without bus conflicts)



edit: fixed ordering of submappers 1/2

Did you mean to reverse submappers 1 and 2?

Sorry, I don't know why I didn't double check that. :S I will correct this shortly. (Edit: fixed now, I hope)

Finally got around to test roms for the other two bus conflict submappers: