Adding 4screen mirroring to UNROM-512 mapper definition

The discrete logic board design I created all those years ago _{which apparently belongs in the repro section of the forum even though it was created specifically for publishing homebrews..} is being made use of for a couple upcoming releases. Roth is working on a new game which is to be the first to make use of the four-screen mirroring feature I made available with the boards. I'm here to help formally define the mapper to be properly emulated as it's now being made use of for game development and would benefit Roth's development efforts to have emu support.

The mapper follows 95% of the current UNROM-512 mapper 30 definition. The identical parts include PRG-ROM flash save operation, mapper register definition, and 32KB banked CHR-RAM. The only variation is the creation of 4 screen mirroring support by making use of what were two unused OR gates of the '32 chip which was already on the circuit board for PRG-ROM banking. I just recently made updates to the wiki to fully define how the board's CHR-RAM is mapped and used so that definition could be used to add emulator support to FCEUX. I made the assumption that the logical decision for mapper assignment would be a variant of mapper 30.

I had imagined that a sub mapper wouldn't even need to be used as the header's four-screen mirroring flag could simply be used to denote this variant. Upon editing the wiki I noticed that the 4 screen flag is apparently being used to denote when the 1screen option is in use. To me this seems directly contradictory to the ideology of why NES 2.0 was created but oh well...

I wanted to post here to ask for the community to decide how to disambiguate mirroring options which I'm making available for what I had guessed would fit within the original mapper definition. Apparently there was discussion on the IRC to give this 4 screen variant it's own mapper number 270. Personally I don't understand the logic of assigning a new mapper number when NES 2.0 has been defined as it is, and any emu which desires to support this mapper must also support NES 2.0 headers. But I'd rather not get to deep into the politics that are mapper definitions as I don't feel I have a dog in the fight. I'm just looking to start the conversation so the powers that be can make a decision and standardize this 'new' hardware configuration for emulator purposes.

My apologies on preemptively editing the wiki, that seemed like the most logical place to document the design. I can remove my edit and place it somewhere else if need be, or if anyone feels the need to undo my changes themselves I won't be offended.

I'd probably suggest just making a new mapper for it, rather than trying to combine it with the existing mapper 30. There are literally thousands of new mapper numbers to choose from with iNES 2, and I think you already require iNES 2 because of the CHR-RAM size anyway.

IMO:

• Submappers are for disambiguating existing mappers that were allocated before iNES 2. Not applicable here.
• The four screen bit is legacy iNES 1 stuff, and really shouldn't be used to disambiguate between 2 incompatible mapper implementations like this. I think practically speaking in some cases it's more like metadata, additional info about the game.

Edit: I don't really agree with either of those two statements at this point.

Then again, there's a lot of permuations of this board. Flashable or not. Single screen or fixed (and now 4-screen). Maybe submappers are appropriate after all?

As for adding the mapper definitions to the Wiki or FCEUX. I suggest the same process for any proposed mapper:

• 1. Release a game or other useful ROM that needs the new mapper.
• 2. Make a test ROM that can be used to verify that it works.
• 3. Document it and propose the change, and await commentary and/or implementers to take it up.

Some people might be willing to skip step 1 on faith that a game is eventually going to come out for it. The main question this is supposed to answer is: "Why should I implement this mapper?"

As for the Wiki, the documentation is fine on the same page as the other UNROM-512 mapper. (Plenty of articles group more than one iNES mapper on the same page.)

There's always the old "four screen" iNES 1.0 flag.

That's the same in iNES 1 and 2. The problem isn't that you can't specify 4-screen, it's that there was never a flag for 1-screen; there's 1 bit for horizontal/vertical and 1 bit for 4-screen.

Unfortunately what happened is people took to using the 4-screen flag to mean "4-screen or 1-screen", so it's often set for 1-screen games.

...and in this specific case we are trying to disambiguate between 4-screen and 1-screen. (Doh!)

Also, I forgot to mention that at least 1 game using the Sealie UNROM-512 board uses fixed 2-screen mapping. (Battle Kid 2 uses horizontal mirroring.) BK2 is compatible with extended mapper 2, at least, but we could potentially have games on that board using the mapper 30 CHR banking or flashable ROM.

Not sure if Owlia counts too... I presume this uses INL's variant of the Sealie board, though it also appears to be mapper 2 compatible.

As an alternative, there are actually 4 possible mirroring configurations:

It might not be too late to specify that if the header is iNES 2, then case D would specify instead "1-screen". That by itself would be enough to cover all current mirroring variations of the board.

This can't retroactively be applied to iNES 1 (and I have no idea how often the H/V bit is set when the 4-screen bit is also set), but since iNES 2 is still a new thing, it seems like a plausible extension.

With such an extension, the only permutation of the board left flashable vs. non-flashable, though maybe even that would be covered by the iNES 2 battery backed PRG RAM fields. Since there's no place for regular WRAM on this board and the flashable ROM is really a substitute for that, it seems that this data would be sufficient.

Similarly, the CHR banking bit only applies if CHR-RAM is bigger than 8k, so this too is covered by the iNES 2 header.

So... I mean, I guess you could do everything this board does with iNES 2 with that one case added to the nametable mirroring flags? Anyhow, just another way to solve it, potentially. Could use input/comments from others.

Edit: See below for my own follow-up on this. The current implementation used by Black Box Challenge / FCEUX as of 2019-01-08 uses 1..1 for the 4-screen variant. I also don't really feel that 1-screen can ever be a generic header value, it only works as a mapper-specific disambiguation for a mapper that has some kind of 1-screen mapping.

4scr&vert = 1scr? Seconded. (This also means we could drop Major League's submapper.)

That's a link to edit the post, which we can't. You want this. (Also, the topic does say "dev/repro" board…)

According to the submappers page, it's not just the mirroring that's different, so I don't think we could.

Whoops, right, it ignores all writes to $9000, which also fixes the PRG bankmode. Lemme double-check if my Verilog 020s1 draft has that…didn't, fixed.

Okay, so a few years ago I made that proposal above. I'm going to follow it up now with the hindsight of (as of the last few months) there actually being 2 ROM releases that now rely on it. (Also, someone was asking in the other thread about a PowerPak mapper for it.)

So... I don't think that proposal I made above as an iNES 2 extension was a very good idea. Horizontal, vertical, 4-screen can apply generically to most mappers, but 1-screen always requires direct mapper interaction, so it's not really appropriate as part of a generic field like this.

Either way though, back then it was an entirely moot point because this still only mattered for Mapper 30, and there still weren't any finished ROMs at all that were public. I think I considered it "to be resolved later" and didn't really think about it for a long while. INL had left the wiki stating that it was undecided at the time. Later on when I was working on emulating various mapper 30 ROMs privately, I think I completely forgot about that proposal, and instead used this:



I think my rationale was that 1..0 was the "old" way for this mapper, and also I think I checked a bunch of ROMs that set bit 3 and they had bit 0 clear. So... this was the "default", and should apply to the original board. The 4-screen version was a "new" variation of the board, and so got 1..1 to specify this. I'm not really trying to debate the merit of this line of thinking, just I believe that's what was going through my head at the time. The wiki said TBD, and I had totally forgotten about the iNES 2 proposal thing above, so I picked something arbitrarily for my personal internal work.

Anyway, in November a Black Box Challenge ROM was released for free, and its headers were based on this version of things. It was added to FCEUX's development build, and finally with an actual ROM people could download and test with, I declared it official on the wiki.

I think my proposal above (and subsequent absent mindedness of it) caused a bit of confusion, unfortunately. I don't know what the PowerPak mappers implemented. Mesen seems to have implemented that proposal and also made UNROM512's mirroring contingent on the same proposal, tying it up with the need for an iNES 2 header.

TLDR: What I'd suggest now is forget about iNES 2. This doesn't need to have anything to do with that. The minimum problem here is just "UNROM512 needs disambiguation", there is no larger generic problem to solve, and it should just look at bit 0 of the mirroring field to do so. This is just one case of "mapper defined mirroring", and not really a revision of iNES.

As for whether 1..0 means 1-screen or 4-screen in this case, well, I personally declared Black Box Challenge's release as having settled that. I'm not going to fight for it, though, if someone thinks this needs to be overruled for some reason or other. My declaration was entirely motivated by there being an actual ROM file out there that needed disambiguation, so I arbitrarily picked that side to go with that one existing ROM's header. If this decision is disliked and there is consensus to change it, I won't stand in anyone's way, but to me it looks very arbitrary and I'd leave it as-is just for the sake of stability.

At present, I know of only 2 releases where it matters:

• Black Box Challenge (4-screen)
• Twin Dragons (full version) (1-screen)

I haven't seen the header Twin Dragons is using, as it is a paid release. (I own the cartridge version, and I've dumped the ROM from that, but obviously that doesn't come with the header.) Edit: Twin Dragons was found to use $E8 in its header, confirming the standard.

I think there may be RetroUSB releases that require 1-screen, but they don't release ROMs publicly, only cartridges, and none of the RetroUSB cartridges I own required 1-screen mirroring, so as far as that goes I can only tell you about mapper 30 RetroUSB releases that aren't affected by this disambiguation problem. Edit: After asking Bunnyboy about it, I think the conclusion was that there are no RetroUSB releases using 1-screen.

So... sorry about the confusion on this one, no small part of which was caused by myself.

Personally, I'd really rather not have 1..0 mean four screen everywhere except mapper 30 ... and mapper 218 ... really I just want it to be consistent throughout.

But... wishes and fishes.

As I mentioned on the wiki talk page, I would not mind using one of the combinations with the 4-Screen Bit set as a generalized One-Screen mirroring option, even for other mappers.

However, it irritates me that 1-Screen-Mirroring would be the one with Bit 0 clear and 4-Screen-Mirroring the one with Bit 0 set. I would have made it the other way round, sort of thinking that Bit 0 clear means that the original meaning of Bit 3 is not modified, hence 4-Screen, and Bit 0 set means that the original meaning of Bit 3 is modified to 1-Screen. But I suppose it's too late to flip those two around, is it?

As I documented on the Mapper 070 wiki page, using the 4-Screen bit to denote One-Screen Mirroring actually goes back twenty years, even as it has never been officially approved.

Well, just keep in mind that whatever you want to do here practically can only apply to mapper 30. There's no other mapper that can meaningfully interpret a difference between 1..0 and 1..1 here.

1-screen mirroring is always a mapper-specific interface, not something you can generically apply via header. (4-screen on the other hand, is.)

Mapper 70 doesn't have a four-screen game, and there's no reason for anyone to ever create a four-screen game for it. Even hypothetically it'd be a bad idea to do anything but create a new mapper for that case. The battle is already lost there.

Major League isn't a four-screen disambiguation case either, this is 1-screen vs. H/V mapper controlled, so bit 0 must be ignored entirely for this mapper. I don't know if bit 3 has been used historically to mean 1-screen on this one like with Mapper 70, but either way it also needed a separate mapper for an additional functional difference.

Mapper 218 I guess is already living this dream, with 4 special cases for the 4 mirroring configurations, none of which is generic. (Isn't there only 1 game for this mapper? Why do we have 4 implementations for 1 game? ...feels like the mirroring experiment was considered more important than the game here. ;P)

Then there's all the mappers which have to ignore one or both of the mirroring bits (e.g. MMC3 ignores bit 0 but not bit 3). There's a lot of these, I'm not going to try listing them.


So... I can't really see a case where I think defining that bit one way or the other is going to make anything simpler to implement, now or in the future. Maybe 1..1 as "mapper defined" would have been a nice bit of meta-info, but that's already encoded in the mapper number, and you'd be invalidating many existing ROMs using iNES 2 headers by requiring this. I think this field has to be special-case ignored or interpreted for any mapper controlled mirroring.

(Or maybe you wanna throw away the mirroring bit approach and try submappers instead... but as far as I'm concerned the definition and documentation problem is already solved as-is, and implementation can begin catching up as soon as people are willing to stop poking at it, but I'll try to stay out of the way if that's not the case yet.)

There are also two mappers, 355 and 512, that allow 4-Screen Mode to be turned on and off. I have written the description of header bit 3 such that because they must provide the additional memory for doing so, the bit must be set for them even though it is not enabled for all the time.

All right, before making a further mess, let's not change the meaning of the two header bits for all games, just in the described manner for Mapper 30. If that turns out to be the consensus, I will add a notice to the NES 2.0 wiki page. The problem that remains is: if a future homebrew board designer sees this exception for Mapper 30 and wants one for his board as well, would that then be accepted?

I don't see anything pertinent at Mapper 355?

Mapper 512 looks like very decidedly "mapper controlled" mirroring. I don't think an implementation of this mapper as described could do anything but ignore both mirroring bits? What do you mean that it "must provide the additional memory"? There's only a single game to describe here, right? There's really only one set of thing this mapper can be attached to, so there probably isn't much for the header to meaningfully specify there.

As for future homebrew, I have no idea. Every one of these is a unique case. Even mapper 30 certainly wouldn't have turned out this way if the 4-screen were part of RetroUSB's original board, and not a later addition by INL's copy of it. Mapper 218 is completely out in leftfield with very different goals than any other board. I wouldn't be comfortable making any blanket statements about what people might propose in the future. If someone releases a ROM, let's look at it then.

Both mapper 30 and 218 could easily have been specified a different way. Personally I don't see much difference whether bit 0 set or clear means "1-screen" or "4-screen" for mapper 30, or whether it was a submapper, or whether a new mapper was created for one of the cases. These all look more or less equally useful and/or ugly to me, and I don't really think that making this choice for mapper 30 has strong implications for how you need to do it for any other mapper.

Sorry, mapper 356.

"Must provide the additional memory" means that the emulator must allocate 4 KiB for additional nametable memory, which it does not have to do for regular mapper-controlled memory. This affects Gauntlet, Rad Racer 2, Rocman X, Jurassic Boy 2, JY-208, Zhongguo Daheng and all Vs. System games. Mapper 512 uses the additional 4 KiB VRAM in addition to the 2 KiB of CIRAM for a total of six nametable pages. It is the only one which requires six independent nametables, to my knowledge; the others will run fine if two of the four pages are mapped to the same memory as CIRAM, the way stock Nintendulator does.

Okay, well 356 seems pretty much the same case as 512? Completely mapper controlled, only one board/game, and no plausible use for the mirroring bits in the header, as far as I can tell.

Stating that the mirroring bits are of no plausible use is not helpful when my goal is to define canonical headers for all games. The header bits, useful or not, exist, and must have some defined value in every situation, for every mapper. No ambiguities may remain.

In the magical world where I get to completely ignore precedent, I would specify

0..0 = any variation of mapper-controlled, or horizontal (PPU A11)
0..1 = vertical (PPU A10)
1..0 = four-screen, always overriding and precluding mapper control (necessary for mappers 1 and 75 on Vs. System)
1..1 = undefined and invalid

This means that mapper-controlled mode for mapper 30 and 1-screen modes for mapper 218 would require submappers or new mapper #s instead of crap in the mirroring bits.

If extra memory is provided, that doesn't necessarily make it four-screen. If the game requires four RAM nametables but also requires the ability to bank them, that's not something that would be backwards compatible anyway.

Well, another way to put it is just that I have no opinion as to what value you should specify when the value can't possibly be used by the implementation.

So... specify whatever you like for that, I guess? Or specify nothing. There's no natural fit for it, so it doesn't really matter what it is.

I guess "when in doubt leave it 0" would be my rule of thumb? But that's about it. I think that's sort of what lidnariq just suggested with 0..0 = mapper controlled or horizontal, and 1..1 is invalid (which also would mean: reserved for future use)...

Maybe try this expression of that concept that would be compatible with existing stuff:

• 1. The standard use of these flags is:
  
  • 0..0 horizontal
  • 0..1 vertical
  • 1..0 4-screen (dedicated 4K RAM not banked or accessible elsewhere)
  • 1..1 reserved
• 2. A mapper may override these definitions, but if either of the mirroring bits is unused/ignored it should be set to 0.

So most mapper-controlled mirroring should have 0..0. MMC3 also allows 1..0. Mapper 30 and 218 have special values. Mappers 356 and 512 would be 0..0, even though it's dedicated it's also required, and thus the bit must be ignored, so 0. Etc. By allowing the mapper to override, the standard use becomes a guideline rather than a hard rule.


Separately, there seemed to be an implied question about how to specify the VRAM. I'd say if it's "dedicated" (standard use) then it's not specified as CHR-RAM, and it's directly implied by standard 1..0 or by the mapper itself (356, 512). If it's not dedicated, then it's naturally part of the existing CHR-RAM. At least, that would work for UNROM512, and GTROM, which both place it within bankable CHR-RAM. Napoleon Senki would seem compatible with 1..0 standard but since it's not an optional part of the mapper would that dictate 0..0?


As for the other question about "is this too late to change", the work involved is basically getting No Cash, Sly Dog Studios, Broke Studios etc. to update their ROMs, updating FCEUX, and hoping wild copies get updated. Also there may be other ROMs out there I'm unaware of, and really I think that's why I used 1..1 for UNROM512's 4-screen; I had the assumption that people were already using 1..0 for 1-screen with that mapper, which had been its definition for years prior. In hindsight, I'm not sure if such ROMs exist in any non-private setting. So... I do not advocate for making a change like this, but that seems to be the scope of what it would take.

Isn't that what they arelady are meaning ? Except maybe 1..1 might be the same as 1..0 and be valid, but I don't think any ROMs of the 3 licenced games that uses 4-screen mirroring uses this, thus making it invalid will not change anything outside of homebrew community in practice.

Look above in this thread for existing examples where they don't mean this.

The OP subject of this thread was about one of those examples, where for mapper 30 1..0 marked the 1-screen variant of the board, and 1..1 marked the new 4-screen variant.

"Ignoring the subsequent mess that the homebrew community has made of the header bits" is the entirety of my desire.

My god whoever came up with this idea had a godawful idea. Don't be offended I have such ideas myself too this happens to everyone... but it's only problematic if the idea is implemnented. iNES is already weak as it is, espcially mappers, so redefining headers bits is... arrghh...

I agree.You asked for it:

• Mapper 30 submapper 0 may take hard-wired H, V, 4-screen mirroring, as defined by iNES header bits in their original meaning. The 4-screen variant must have the H/V bit set to zero, as is the case with mapper-controlled mirroring.
• Mapper 30 submapper 1 takes hard-wired 1-screen mirroring. Both mirroring header bits must be 0.
• On the wiki NES 2.0 page, Header Byte $6 bit 3 gets renamed (back) to "Hard-wired four-screen mode", and an explanation section is added stating "Header Byte $6 bit 3 is set if the cartridge is hard-wired to use four independent nametables, at least two of which must be provided as additional memory on the cartridge. It is not set if four-screen mode can be enabled or disabled by the mapper hardware. Bit 0 must be clear if Bit 3 is set."
• The CHR-RAM explanatory section will have the sentence "The CHR-RAM size does not include the additional memory for four nametables denoted in Header byte $6 D3." changed to "Memory for additional nametables is included in the CHR-RAM size field unless that memory cannot be mapped by the board hardware into the pattern table address range ($0000-$1FFF) at any software setting and thus can never become CHR-RAM. This implies that memory hardwired for four-screen mode, denoted by Header Byte $6 bit 3, is not included in the CHR-RAM size."

Rationale:

• We have assigned new mappers or submappers for all other hard-wired one-screen mirrored variants, so in the name of consistency, let's do it this way here as well.
• I am not buying the argument that the 4-screen-bit is "legacy" and thus should not be used for new mappers. We use it for mappers 4 and 206 even in NES 2.0, and so should continue to use it for new applicable cases for consistency.
• I am also not buying the argument that submappers are only to disambiguate mappers that were defined before NES 2.0. The emulator source codes that I have seen use one source code file per mapper and differentiate submappers within that source code file because the differences usually affect one or two lines only. That flexibility should not be given up lightly. And I have already defined submappers for Mapper 256, to nobody's complaint.
• Hard-wired one-screen mirroring that is not defined by the mapper number was never part of the iNES spec, and it's not up to a single mapper to redefine header bits. I previously mentioned the precedent from mapper 70, where a new mapper 152 was allocated instead of accepting the repurposing of the 4-screen bit.

Okay?

Why not change it to your latter expaination sentece, then ? It sounds much clearer than the first sentence you intend to put into the wiki.



Is much simpler to understand than.

Because the latter is not a synonym but a consequence of the former. The former's generality is needed to apply to mappers 356 and 512.

I said specify whatever you like for a bit that has to be ignored by the implementation. You were the person asking for "canonical header", which means you needed to specify a value even where it can't be used. I wasn't asking for any specification for things that don't matter.

You're now specifying stuff for something that has to be used to implement mapper 30. That's completely different than what I was referring to by "specify whatever you like for that, I guess?"


I'm not arguing either of those things now, and I regret having written them. Maybe I should edit that post to clarify that it should be treated as me spitballing about it, and that I don't feel the same way as I did in that moment a few years ago. In the matter at hand, I think using the mapper bit to disambiguate mapper 30 without resorting to iNES 2 at all is perfectly valid.

I don't really see the meaning of mirroring bits as an iNES 2 issue at all. The stuff we're talking about could apply equally to iNES 1. Mapper controlled cases are generally an "ignore the mirroring bits" situation. The only thing iNES 2 is really contributing is the possibility of using submappers for different mapper variations... which yes could have been used for 30 and 218, but weren't. The meaning of mirroring bits should be defined the same for both iNES 1 and 2.


Like I said, the problem for mapper 30 is solved in its current state as far as I'm concerned, and really the same thing for 218. If you feel the need to overturn prior work, then I won't stop you but I'm also not going to help. I don't think there is any need to do so, and it's a lot of extra work to contact people who have already released ROMs, inform everybody, get changes made to ROMs and emulators, etc. So, no, my vote is to leave mappers 30 and 218 how they are.

Aside from 30 and 218 though, everything else seems germane to what's been proposed by everyone here. We all seem to agree more or less what the 4 values should normally do, I think? I don't really see any conflicts in any other examples given.

I cannot accept any ambiguity. Everything must be specified, or a format is useless. Allowing ambiguity is what got us "DiskDude!" many of the incorrectly-headered ROMs that we have, and precludes indexing headered ROM image files.

Then forget about my Mapper 030 proposal; I'll just add the stuff about clarification of the 4-Screen-Bit meaning for cases other than mappers 030/218, based on what I understand to be the result of our discussion of Mappers 356 and 512, and add a notice that Mappers 030 and 218 use Byte $6 bits 0 and 3 in a non-standard way.

Yes, I understand that desire and I'm sympathetic to it. I don't see a problem with that. Sorry. All I was trying to clarify is that in cases where the bits being one way or the other can't affect the implementation, I don't have a strong feeling about how it gets defined.

For a normal mapper whether an emulator wants to reject 1..1 as a bad header, or treat it the same as 1..0 is really up to the emulator author. It's not everybody's job to police bad headers; a lot of emulators just want to be able to run anything that has enough information to specify what it needs. A header validator/fixer is a cool tool, but it's a different goal than just wanting to be able to run stuff accurately.

So... the idea that the spec is "useless" without it, or that having 1 or 2 slightly-unspecified-edge-case mirroring bits is comparable to "DISKDUDE!", I am not really sympathetic to. ;P My main point is just that if the bits don't matter, there is no natural specification for them, only arbitrary ones. (The "0 if arbitrary" rule of thumb seems equivalent to other things being proposed, though, not that I'd suggest wording it that way in specification.)

...and again, even mapper 30 or 218, if you want to do the footwork I described to move these to a submapper implementation instead, if you've got the desire energy and inclination to do that, then I'd be okay with it, but I don't have desire/energy to assist with what I see as a lateral change, and without coordinating fixes to the existing stuff I think it'd be a decidedly backward change instead of lateral.


Here's a stab at defining canonical 4-screen:

"4k RAM is present at PPU $2000-3FFF (mirrored once), exclusive to that region, and can't be banked, replaced, or rearranged. Non-canonical types of 4-screen may share memory with CHR-RAM, or have other unusual arrangement as defined by the mapper."


And finally the question of what to put in the CHR-RAM size and mirroring bits for some of the non-canonical cases:

Napoleon Senki is a weird thing to resolve. I'd say it fits that definition of canonical 4-screen, but I'd also say that this mapper can only exist as 4-screen, so any interpretation of the mirroring bits is useless. Thus if you want a canonical value here, I'd maybe suggests 0..0 as "mapper defined", and then 8k of CHR-RAM. Otherwise it seems like it deserves 1..0 and 6k of CHR-RAM?

Mappers 356 and 512 would both fail that canonical definition, again I'd just suggest 0..0 "mapper defined", and from the sound of their definition when in four-screen mode the RAM used is exclusive and separate from CIRAM and the other CHR-RAM, right? I'd probably leave the 4-screen VRAM out of the CHR-RAM field for that reason too.

I don't have a strong opinion about these 3 mappers, but that's my guess as to how they might fit "cleanly" into this form, though I'm not sure if it's really possible to come up with a definition that is 100% clear cut and consistent for everything. In some cases it might be a whole lot simpler just to say "mapper X is a special case" than to create some serpentine definition that negotiates around it.

I have updated the NES 2.0 wiki page ("forced" myself upon it, as one poster would call it) to denote mappers 30's and 218's idiosyncratic interpretation of the header mirroring bits, and clarified the meaning of the 4-screen bit. I chose to include mapper 77 as an example of a hard-wired 4-screen mode because it is technically hard-wired, is listed in several places as a Four-Screen game --- granted, those pages were not aware of this discussion ---, because every ROM image of the game that I could find has that bit set, and because the only reason I can think of why it would not meet the definition is that it shares the memory chip with CHR-RAM as a peculiarity of the PCB design. I agree though that it is a bit tautological since that mapper does not exist with any other mirroring type, but so what.

I have removed, for the time being, the statement that this extra nametable memory should not be considered part of the CHR-RAM size, because... I am not so sure any more that it should not be. If it were included, it would streamline the CHR-RAM definition as simply "RAM that goes into PPU address space", thus removing the awkward distinction in RAM sizes between mapper-controlled and hard-wired 4-screen memory, resolve mapper 77 in a clean way (CHR-RAM size 8 KiB), and account for the fact that the same RAM chip provides pattern table RAM and 4-screen-RAM in mapper 356.

The reason I suggest that is that I think for the canonical 4-screen case it creates a redundant and error prone situation to try and include it as CHR-RAM.


For most mappers you should be able to substitute CHR-RAM for CHR-ROM and have exactly the same behaviour, and exactly the same size for the CHR-RAM version as CHR-ROM. Swapping ROM for RAM should not affect anything else, it should be unrelated to other factors as much as possible.

Similarly, canonical 4-screen should also be as orthogonal as it can be. 4-screen should just mean there is automatically 4k of dedicated RAM, and it shouldn't interfere with or interact with anything else. We shouldn't have think about whether the cart did it as 2k of RAM + CIRAM, or completely internal 4k, etc. any hiccups like that should only be non-canonical mapper-specific exceptions. It also shouldn't add on to other CHR-RAM that's only used for pattern tables. 8k + 2k? 8k + 4k? 16k? The standard 4-screen meaning should not require determining interactions like this. It should just be able to "drop in" on most mappers without having to parse the other fields to figure it out.


With mapper 77, you could call it 6k CHR-RAM + canonical 4-screen 1..0. You could also call it 8k CHR-RAM + 1..0, but I don't think that's canonical anymore (at least not by the way I suggest defining it); in this case it's a special variation of 4-screen where you're specifically including 2k it as part of the CHR-RAM. 0..0 "mapper defined" + 8k CHR-RAM also seems valid to me, which is just as much a special case. ...but there is only one possible thing to emulate here, all of the PPU-RAM is implied directly by the mapper, so arbitrarily even putting a 0 in the CHR-RAM field seems valid to me. (I don't really have a preference between these 3 possibilities, but I think it's an inherently ambiguous case that can't really be resolved by anything less than a special callout. Otherwise I think interpretations are going to differ here for any way we might attempt to define around making it a special case.)


In 356/512 it sounds like it's a completely separate and dedicated RAM just for nametables in the specific mode. That seems like a part of the mapper itself, not a "CHR-RAM" chip that needs to be specified as +4K on the CHR-RAM value. MMC5 ExRAM seems like the same situation to me, I wouldn't expect to put +1k into the CHR-RAM field for that. That's sort of what bugs me about trying to put it in the CHR-RAM field. It puts complicated interactions into the parsing of that field.


Though a way to demonstrate what I'm suggesting is that you should be able to take a UNROM with 8k CHR-RAM, and then set 1..0 for canonical 4-screen, and just get that without having to now specify 10k or 12k or 16k or 32k CHR-RAM. If you want to implement it any other way than some dedicated separate nametable RAM, it should be a new mapper or special case definition (like UNROM512).

Even though putting a flat 32k SRAM across the PPU address space would be the most straightforward way to build a simple CHR-RAM + 4-screen mapper, this should not be included in the canonical 4-screen case, it should be a special case. The canonical has to be more restricted than that, especially w.r.t. the $3000-3FFF mirrored area, because otherwise it's incompatible with the original 4-screen mappers that did it with half CIRAM. In the example I just gave, would 10k and 16k/32k have functionally different meanings (half CIRAM, mirrored twice, vs. no CIRAM and no mirror), and 12k would be functionally the same as 10k but somehow explicitly saying not to use CIRAM...? These possibilities feel really weird to me, and I think there's a lot of unpleasant room for interpretation if you go that route.


At least, that's what I would suggest as the standard/canonical definition of 1..0. The examples I'm giving about taking an existing mapper and changing ROM to RAM, or fixed mirroring to 4-screen, etc. obviously the games for this don't exist at this point, but the question that is in my mind is if I'm an emulator parsing a header, or a homebrew author trying to choose a mapper, can I deduce what's will/should happen if I take old mapper X and write "4-screen" in its header? Can I know what happens if I write 0 CHR-ROM and 256 CHR-RAM? The less interaction between fields, the less room for interpretation there is.

My approach may be unwarranted though. You could also decide that any mapper that has not already established a 4-screen variant is not allowed to use that bit... though in that case we should have to say that each of the ones that can use it is special. (Though, that's still a pretty small an practical list?) I had for a long time felt comfortable in thinking of the 4-screen bit as something that could at least in theory be easily applied to a great many mappers, but I'm not sure if others feel that is even a necessary goal. (In practice... support for it is very restricted in many emulators, I think.)

Though, I might suggest that for the sake of assisting interpretation, since the number of different categories of 4-screen mapping is pretty small, it might be prudent just to make a list of all of them as a supplement to whatever specification you decide on. Based on what I've seen I think the definition for this is going to be difficult to parse/interpret, no matter which way it ends up, and some more direct clarification could go a long way toward stabilizing it.

Not really a list of all games, just a list of mappers which currently have 4-screen games + what to put in their mirroring and CHR-RAM fields. (Maybe a table at the bottom with an internal link from the relevant fields.)

In a wiki edit, Lidnariq wrote "Mapper 77 doesn't map anything at all to PPU addresses $3000-$3FFF." What does it do with this address? Open bus?

Actually, I had assumed that all the old 4-screen mappers had $3000-3FFF as a mirror for $2000-2FFF, but maybe I was wrong in that assumption. Are they all the same or different? It's possible that $3000-3FFF has no canonical 4-screen behavior at all and must always be mapper specified? (This is something that the wiki seems to have very little to say about.)

...though of course in practice this region is not likely to matter at all for basic game compatibility, but the stated goal here is to be completely specific about the implementation.

Correct.

I'm not confident it's consistent for any given mapper. The games that add a 2 KiB RAM and decoding logic most likely ignore PPU A12 and thus mirror into $3000-$3FFF ... but they also might leave it open bus. Certainly 800004 and DRROM use a 74'00 to generate a one-of-two demultiplexer, and there aren't enough inputs for PPU A12 to enter into the equation.
The games that use an 8 KiB RAM may leave A12 unconnected, making $3000 a mirror of $2000 ... but they may also have naively connected PPU A12 to RAM A12, making it an obtuse but technically available extra 3.75KiB of RAM. TR1ROM uses an 8KiB RAM with no extra decoding logic, but the only image in NesCartDB is both bad quality and only of the front, so I can't trivially find out which.

The problem is that because we put MMC6's internal WRAM into the PRG-(NV)RAM field, we in fact would put MMC5's ExRAM into the CHR-RAM field for consistency, unless it is put into the PRG-RAM field, where it seems to be more logical to put since as I understand the wiki it is still halfway-accessible there even in modes 0 and 1, and the same RAM should not be included in both fields since it only exists once. But yes, EXRAM is another can of worms that I have not thought about before.
I am not sure what the advantages of such orthogonality would be. The memory area mapped to PPU $2000-2FFF has to be allocated by the emulator based on some kind of information. I would like to minimize the amount of differentiation one has to do, and always mapping to CHR-RAM included in its size field would accomplish that. I want to minimize the number of situations where, after having all these size fields in the header, more memory keeps just popping up because of this or that header bit. Right now, that occurs only in the case of Namco 163 chip RAM and the Datach main unit's EEPROM. The first is acceptable since it is not directly mapped into CPU or PPU address space, sort-of "out of sight", and the second one because it is not part of the game cartridge being described by the header.

Why do you think the "somewhere" is messy? I think it's the only non-ambiguous way it can be applied generically and orthogonally. You don't even have to look at the CHR-RAM field to apply it, you know exactly where to put it, and can use the same implementation across all mappers that support it. Can even reasonably be statically allocated by the emulator.

Edit: Sorry, I seem to have missed an edit to the above when replying. There was some snippet of Nintendulator code being used as an example of putting the nametable RAM "somewhere" vs in CHR-RAM that I was responding directly to.

Otherwise, you have to make arbitrary decisions about where in the extra CHR-RAM it goes, how to mirror it, what portions of the CHR-RAM are bankable or not, etc. This seems like a big parsing problem to me.

Especially there is a combination problem with the separate goals of being able to substitute CHR-RAM for CHR-ROM interchangeably, and being able to add 4-screen independently. Here's a couple of hypothetical headers for some mapper that has CHR banking, and standard hardwired nametables:

1. 32k CHR-ROM, 0k CHR-RAM, 0..0 hardwired
2. 32k CHR-ROM, 0k CHR-RAM, 1..0 4-screen
3. 32k CHR-ROM, 2k CHR-RAM, 1..0 4-screen
4. 32k CHR-ROM, 4k CHR-RAM, 1..0 4-screen
5. 0k CHR-ROM, 32k CHR-RAM, 0..0 hardwired
6. 0k CHR-ROM, 32k CHR-RAM, 1..0 4-screen
7. 0k CHR-ROM, 34k CHR-RAM, 1..0 4-screen (Edit)
8. 0k CHR-ROM, 36k CHR-RAM, 1..0 4-screen (Edit: forgot this is not a usable CHR-RAM field value, but cases 7-8 here could be padded to 64k for the hypothetical I'm arguing.)

So 1 is some standard hardwired mirroring, no ambiguity here. 5 is the same board but with RAM instead of ROM, which should be completely unambiguous, no problem there.

Now what's the difference between 2, 3 and 4? Does it matter if the 4-screen RAM is supposed to be half CIRAM (3)? Is the added CHR-RAM supposed to go in the lower or upper nametables, or the two sides? If the header says 4k (4). With 0 in the CHR-RAM field (2), I think it's explicitly clear that the emulator has to provide the 4k itself, and no further decision needs to be made.

So 5 has a clear definition for replacing ROM with RAM, but what happens in 6 or 7? If canonical 4-screen is separate, there's no ambiguity in 6, and the bankable CHR-RAM continues behaving exactly as in 5. However, if it's not, then we're now insisting that that nametable RAM resides somewhere in that 32k and shares utility with the existing CHR banking schemes... that immediately becomes a series of mapper specific decisions about how this is going to behave. Should the nametables start at 0000 in that CHR-RAM? At 2000? At 6000? It also creates problems for someone who wants to convert something already using CHR-ROM to CHR-RAM, we can't just copy the previous data into RAM, we now have to make room for this extra 4k (or 8k) that gets eaten up by it...?

So okay, instead we want to explicitly make "room" for it in the CHR-RAM field, to give it its own orthogonal space... thus 7 or 8. These look like a nightmare to me. Now we have to recognize that 32k of this CHR-RAM goes into the mapper's usual CHR banking, and there's an extra 2 or 4k that gets combined with CIRAM for a separate nametable function?

I think any case where we have to mix nametable RAM into the rest of CHR-RAM has to be a mapper specific thing. For UNROM512 or GTROM it looks good to have 32k CHR-RAM in the CHR-RAM field. For mappers 356/512, I don't think it'd be good to have 4k CHR-RAM sitting next to 512k CHR-ROM (or whatever it is these things have). We should have either CHR-ROM or CHR-RAM but not both, except in special cases, so that it remains interchangeable.

Mapper 77 I'm ambivalent about. It's a special mapper that definitively has both CHR-ROM and CHR-RAM. Fundamentally, though, I think the "CHR-RAM" field should really be about stuff that's used for CHR tiles ($0000-1FFF), and if it gets used in nametables or other places that's some mapper specific override, not a generically applicable function.


Okay, well I don't think this is a fair thing to compare with, and I think trying to make a definition that fits every single case, not only 4-screen RAM and CHR-RAM uses but also PRG-RAM uses across all possible mappers... this is an impossible set of constraints to design a definition for. This just doesn't work. MMC6 is already a solved problem, and perfectly fine sitting in the PRG-RAM field where it is. I think you can do no better than saying "use 2k in the PRG-RAM field for MMC6" as a special case, and that's the end of it. Anything else you try to pile on this as a generic definition will make it more complicated.

The biggest difference between these two fields is that PRG-RAM is not a substitution for PRG-ROM in the way that CHR-RAM can be for CHR-ROM. Though... substituting them doesn't actually come up in games that much, this is mainly a homebrew concern, I guess, and largely hypothetical. Old emulators aren't going to grow support for weird CHR-RAM substitutions and 4-screen mappings, so maybe it's OK if this kind of usage becomes new mappers anyway... mostly I'm trying to outline how I would assume to use these fields, and the kind of usage that would be intuitive to me, but I can't make an argument for what's really best based on what I think is intuitive, only consensus will help with that.

Yes, I removed the emulator code because I reconsidered that a format specification should not be defined by the whims of particular emulators.

Mapper 77 actually turns out to be irrelevant for the CHR-RAM size question because we cannot specify 6 KiB of CHR-RAM anyway. 8 KiB CHR-RAM including two nametable pages or 6 KiB CHR-RAM excluding two nametable pages padded to 8 KiB because 6 KiB cannot be specified amounts to the same header.

Having thought about EXRAM, I would say include it neither in PRG-RAM size nor CHR-RAM size because it is not clearly either?

And for 4-Screen, then let's go back to the previous standard: outside of CHR-RAM size if it cannot be mapped into the pattern table address range, and inside if it can. Makes no difference for Mapper 77 as mentioned. That means that Vs. games do not get a CHR-RAM size specified for the 4 nametables either.

What about Vs. System's 2 KiB of shared WRAM --- specified as PRG-RAM or not, because it's part of the different console type and not the game (quite an arbitrary distinction in the Vs. case)?

Ah yeah, had forgot that 6k isn't an option. Anyway, either 1..0 or 0..0, or 0k or 8k all seem "fine" to me for this mapper, if you want 1..0 + 8k, I have no preference, but I think it needs a 1 line special case definition to clarify what to do for it.


Agree.


Since it's in the normal WRAM place, I think it's fine specified as PRG-RAM. Very similar to MMC6. If it's not specified, I think the emulator would have to put RAM there anyway. So... another arbitrary case worth a clarifying line, IMO.


I would agree that it's best not to put 4k in the CHR-RAM field for Vs. System's 4-screen, for the reason of orthogonality.

I am not sure how I feel about the more generic guideline given here... whether or not it maps into $0000-1FFF might be sufficient (what was "previous" standard?) but I guess it's probably good enough to describe existing cases.

As far as I can tell, those 2KiB are required for Vs. DualSystem games ... and Vs. SMB ... and nothing else. But there is something convenient about having it marked whether a game uses it.

At the same time, because the 2 KiB are not necessarily available, I don't think it's appropriate to mark all Vs. UniSystem games have 2 KiB available...

So trying to address existing ambiguities in how the mirroring bits have been used historically, here's three guidelines to remove the ambiguity that exists in current usage. Sort of a concise way to say to leave the bit as 0 when there's two ways about it:

• If mirroring is mapper controlled, use 0..0 and not 0..1.
• If the mapper has fixed 4-screen, use 1..0 and not 1..1.
• Mappers 30 and 218 have special meaning.

As for which of the other mappers should use 1..0, there seem to be use cases for the following:

• MMC3 (4-screen option) Rad Racer 2
• 206 (4-screen option) Gauntlet
• 77 Napoleon Senki
• Vs. System
• GTROM Edit: Forgot this has two banks for nametables. Could also be "0..0 mapper controlled".

We were attempting to define what standard meaning of the 4-screen designation should be, but after considering the behaviours at $3000-3F00 (which could really use some documentation on the wiki), I don't think it's a good idea to have the iNES header spec define the exact behaviour, only a more broad category:

• 4k of nametable RAM fixed at $2000-2FFF, not able to be replaced or rearranged within that space.

I think that addresses the 5 cases above where it is already in use. Have I missed any?

As for how it applies theoretically to all the fixed-mirroring mappers, I think that would ultimately be subject to the same problem. The most practical thing to do for e.g. UNROM might be a flat RAM, combining but not overlapping with its traditional CHR-RAM. On a board with CHR-ROM, maybe decoding a more narrow range would be more practical. I don't think there's enough to specify which should be used right now. Though we've talked about it many times in the past, nobody appears to be using those mappers for 4-screen homebrew, AFAIK?

So ultimately... I don't think you can make a hard spec that will cover that theoretical future use overlapping existing mappers. I think in the 5 cases I listed above, they are all compatible with the broad category I gave, but the more specific behaviour is pretty divergent among them. The "accurate" behaviour of 4-screen is therefore, unfortunately, always mapper defined, IMO.

Other than this, mappers 356 and 512 were mentioned. I think these are both 0..0 mapper controlled?


The other question was what to put in the CHR-RAM field:

• MMC3 - 0k
• 206 - 0k
• 77 - 8k
• Vs. System - 0k
• GTROM - 32k
• UNROM 512 - 32k

This is consistent with what I suggested earlier, that we should theoretically be able to swap CHR-ROM with CHR-RAM if its practical, which it should be for MMC3/206 and Vs. System? Mapper 77 couldn't ever switch since it contains both. GTROM can't do 4-screen without its CHR-RAM, and neither can UNROM 512, though the latter could do CHR-ROM in its other 3 configurations.

Otherwise I do not think we should try to define how it might apply to any of the other mappers that could but don't currently have 4-screen variation. Wait for the use cases first, and this is much less of a problem to sort out.

I'd be tempted to add "and cannot be reused for tiles" ... but
* 4-screen variant of UNROM512 can
* in GTROM its 4 screens can be replaced by a different 4 screens.

I don't think we need a bulletproof definition, though. (hope we don't need?)

On the one hand, I can't see a way for my following musing to ever matter, but...

Napoleon Senki has twothree memories on the CHR side, for a total of 40 42 KiB of address space. While "only ROM on the cart" has the same problem that UNROM512/4 does, "only RAM on the cart" would actually be a usable configuration.

(On the other hand, one wouldn't bother with two physical chips. In practice one'd just use a single 32K RAM, similar to UNROM512, and then it'd behave differently enough that it'd need its own mapper number)

Oh! I forgot that GTROM had two pages. Might be an argument that it should be 0..0 mapper controlled then.

Edit: on the other hand, I have subsequently had a conversation with a few homebrewers that are working on GTROM games. Universally their intuition was to put 1..0 there. Maybe that's a case for keeping the definition a little wider, so that it's closer to what most would expect.

As far as I know, there has never been a public ROM of a GTROM game so far. All the releases I know of are from the cartridge-only crowd. Emulators have to ignore the mirroring bits by this mapper definition anyway.

The current wording on the NES 2.0 wiki page implies that the 4-screen bit is invalid when the mapper does not support 4-screen mirroring, in particular the sentence "Currently, only the four-screen variants of mappers 4 and 206 as well as 77 and the Nintendo Vs. System meet that definition". A discussion on the iNES page however has shown that some people expect the 4-screen bit to override any mapper-controlled mirroring. My opinion is that while iNES is not clear on that issue, NES 2.0 should be clear. So: Should the 4-screen bit on, say, CNROM be usable to create a hitherto unheard-of CNROM-4-Screen board?

iNES is very clear - when this bit is set you get 4-screen mirroring. Only on mappers where this conflicts with something would that be unclear. And we agree that NES 2.0 should be clear, but if I remember well it should also be retro-compatible with iNES whenever this is possible.

Nothing is clear about iNES when it does not even have the ability to specify mapper-controlled mirroring, and it does not become clear just because you put the word "very" in boldface. I will take your comment down as a vote for "In addition to mappers 4, 77 and 206 that historically have existed in four-screen variants, the four-screen bit may also be specified with the same effect for any mapper without software-controlled mirroring." It is still unclear what to do with mappers that have software-controlled mirroring --- the wiki talk page says that it is supposedly "clear" that it also applies to MMC1 and MMC3, but not to mappers that have "complex VRAM features", whatever that means --- all very un-"clear" to me.

There also is an argument to be made that we should not allow the specification of headers that are impossible to replicate with original hardware. For example, it has been argued that no mapper 4 game with more than 512 KiB PRG-ROM should be allowed, because the MMC3 does not have PRG address lines beyond A18. Sure, you can specify a 2 MiB PRG-ROM and argue that this just means that an MMC3 clone with more address lines be assumed, and that all eight bits of bank registers 6 and 7 be considered. But it would be a different board than what is historically meant by mapper 4, and using such features precludes putting such ROM images on donor boards. Using 4-screen mode on mappers with no historical support for that seems to be a similar situation. Now, that of course would not mean that you must never create a CNROM-like PCB with four-screen mode, but you would just not be allowed to denote mapper number 3 for it under that regime.

(Edit: Spelling)

I think I'm actually pretty comfortable with the notion of "you want a novel use of 4-screen layout? You must use a NES2.0 header"

As far as describing what the bit means in original iNES, I have to admit I was dismayed to read Rainwarrior's edit to the iNES page: “Mapper 70 had a 1-screen variant that was sometimes specified with bit 3 set. This was relocated to Mapper 152.” so it sounds like the mess with mapper 30 isn't even particularly novel.

(edit) I'd like to say that it "should" mean that the mapper always wants four screens of nametables, and this use is unambiguous in cases that never have mapper-controlled mirroring, but ...

Are you dismayed by the edit, or dismayed by the thing the edit describes? Do you think it shouldn't be acknowledged? My goal with the edit was to prepare someone for what they would actually find in existing iNES headers.

As for other goals defining these bits... I thought NewRisingSun was asking for clarification so that for things that exist where a bit was ignored, it should be clear how to set the ignored bit, so that we don't have 0..0 and 0..1 on equal footing for e.g. MMC1 games. That part of the goal seems fine for an iNES 2 clarification, which in a way takes up the unused variations as "reserved", though most probably they should never be used. I think that's a reasonable kind of "cleanup" additional thing to specify for iNES 2. (...and of course emulators can go on ignoring these bits just as they always have, so it shouldn't actually complicate implementation.)

As for specifying what every mapper is supposed to do when you set the 4-screen bit? No. This is impossible to specify. All actual practical ways of changing mirroring types like this involve build decisions that interact with the mapper, there is no generic way to fully specify this. A weakly compatible definition may be compatible with all mappers with hard-wired mirroring, but this deliberately has to ignore the details of what happens at $3000 and not pretend that this is an accurate specification of some sort. For mappers that already software control their mirroring? No, there is nothing we can insist about their non-existent potential 4-screen modes.

Any combination of mapper and mirroring that no released ROM is using is simply undefined and/or reserved. The specification should just be "don't use it". When new things exist, then the new things can find a new definition. Doing otherwise puts extra work on anyone reading/implementing the spec for no reason, and puts unnecessary complications and constraints on the future use of the format.

Since it's not clear I'll make a nth attempt to clarify. The error you make is that you consider mirroring is linked with mappers. This is simply, in the original sense, not true. In the mindset of iNES, 4-screen mirroring is a cartridge-feature that can be coupled with any mapper, including no mapper at all (mapper 0). This is done by adding additional RAM for the nametables. Similarly, vertical or horizontal mirroring is selected with solder pads. This is independant of the mapper.

Now, there is mappers which overwrite the mirroring of their own. MMC1 and MMC3 are among those. Then bit 0 is ignored, but bit 3 still takes effect.

Then, there is "complex" mappers that does complex effects such as merging CHR-ROM/RAM with nametables or whathever. Those are considered special cases, and in those cases the mapper overrides the iNES mirroring bits.

It's weird that you said just because no game using mapper X has combined it with 4-screen VRAM, that it should be "forbidden". iNES was developped to allow combinations that didn't (yet) exist in hardware, for the better or the worst. I see no reasons those features would be forbidden.

EDIT : You are however right that many emulators authors could get lazy and not implement 4-screen VRAM features with mappers where it wasn't used and get away with it, thus a iNES 1.0 header can unfortunately not be sufficient for reliable emulation. But that's not because iNES is unclear, that's because emulator authors were lazy.

Emulators are free to (and should be free to) implement whatever they want in response to undefined or reserved situations. Leaving behaviour undefined is helpful, it gives people room to breathe when implementing. This is an important part of a lot of technical specifications.

It also lets emulator authors do things like speculatively support 4-screen for fixed-mirroring mappers, which are perfectly harmless otherwise and potentially very useful for experimentation. All of that potential is harmed by telling people what they have to do with stuff that nobody is otherwise depending on being reliably specified.

There's no reason to demand that an emulator has to support the 4-screen bit for e.g. mapper 2, but it's very clear that Bregalad likes this potential, and according to the discussion on the iNES talk page it seems a lot of emulator authors liked it too. It's convenient to do if your code is structured in a certain way, but it's also convenient to ignore for now if it's not. This freedom is good to have!

What I do think could be helpful is to specify better where the boundary of "undefined" is. That's important so that people don't make assumptions about reliability of features. That's a careful boundary that should reflect how things really exist and are being used. The best guideline I can suggest is that if there is no ROM that needs it, it's not specified yet. That's the same rule of thumb that was being used to prevent spurious fantasy homebrew mappers from appearing on the WIki, or submappers with no testable or implementable specification. Don't pile currently untestable definitions onto the workload of people trying to learn/implement this stuff.


No, this is not lazy. This is a perfectly reasonably thing not to emulate. There is nothing to emulate with it! iNES 2 doesn't change that in any respect.

Emulators should support 4-screen mirroring, regardless of mappers. Those are orthogonal features. Except in some specific cases. Why is this so hard to understand ? Because your definition of 4-screen mirroring is not the same as mine (as previous talk on wiki) ?

Until the day before yesterday, I've NEVER heard that 4-screen mirroring could only be used with a restricted list of mappers. I might have not listened. This is similar to PRG-RAM and battery-backed PRG-RAM. iNES supports those regardless of mappers (including mapper #0 - no mapper) even if those cartrdiges configurations never existed.


It might be good for emulator authors, but definitely not for game authors who aims to use 4-screen mirroring ! Half of emulators not playing their game just because emulators authors were lazy to implement iNES correctly, as no games used a combination of two features they support !


At least we aree here !

Oh, get off your high horse. This is the very first time that you have attempted to clarify anything. Before, you simply asserted that everything was clear and written the word "very" in boldface.I am well aware of that line of thinking back in the iNES days. But today, we have a good understanding of board hardware and its limitations. NES 2.0 is based on that better understanding. Yes, NES 2.0 should be backwards-compatible to iNES to the extent described on the NES 2.0 wiki page. But that does not require still following iNES' way of thinking. In this context:
I think that is actually the crux of the issue: modern emulators do not want to implement iNES correctly; they want to implement actual hardware correctly, and use iNES, NES 2.0 and UNIF merely as a means to describe actual hardware.
That is all I was arguing for on the wiki. But you kept pestering me about "most emulators" which as it turns out nobody has even said.
But there is a demand (at least by me) to define what an emulator should do when it encounters a NES-2.0-headered ROM with that bit set, and the board specified by the mapper number did not originally exist in such a variant.
As mentioned before, there is disciplinary value in not allowing game authors to use features that were not available as such on actual hardware.

To sum it up: I really have no stake in either side. I am perfectly fine with adding to the NES 2.0 spec that "Header byte 6 bit 3 may not be specified together with mapper numbers describing board hardware that never existed in a four-screen variant; emulators should ignore the bit in those cases." I am however also fine with adding to the NES 2.0 spec that "Header byte 6 bit 3 may also be specified together with mapper numbers describing board hardware that never existed in a four-screen variant; emulators should override bit 0 or any mapper-controlled mirroring setting in that case." I really don't care which one it is, as long as it is defined one way or another.

Well, this is basically directly in the same category as "fantasy mapper" for me. Specifying how 100+ mappers should work with this bit just in case someone might make a homebrew for it in the future?

For actual homebrew releases that use 4-screen, there has been GTROM and UNROM 512. For the most reliable way to use 4-screen for homebrew, MMC3 is the clear choice. It's not even impractical to implement subsets of MMC3 on a homebrew board at this point. These are some good options that have already become real.

For the rest... what's the point in forcing it? If it remains unspecified and emulators are free to do what they've been doing, there's a lot of potential there to experiment. You can use some current emulators to test out your prospective project using 4-screen with whatever it is you thought was needed... and if you finally decide to release it, great! A bunch of emulators will already support it with not changes.

...and until that day, there's no reason to demand it via specification. Specifying it won't make that homebrew happen, it just leads people do extra work for nothing.

The latter. Dismayed that it had apparently happened.

The only argument that occurs to me goes:

Given that the Vs. System always came with 4 screen layout, was used with a small but nontrivial handful of mappers, and never supported run-time mirroring control...
Therefore at least one of the two bits in the header (Four screen and "Vs system") should strictly override whatever mapper control is provided by that mapper and irrevocably force four-screen layout.

Yes, I know that's explicitly why you called out "the mapper number did not originally exist in such a variant". But I guess that's the root of it all, right? Prescriptive vs descriptive?

I like the uniformity of saying "the four-screen bit always means four-screen layout and the mapper IC can't opt out of it after the fact", but that has plenty of its own problems. Are we allowed to say that the behavior is explicitly undefined?


In practice, I guess, FCEUX's gross hack (it loads whatever ROM with four screens, subsequent mapper control writes irrevocably throw away the extra nametables) may actually be the compromise position.

I think that's exactly the way to strengthen the specification. Explicitly undefined, which also means reserved.

It makes it clear that you should be putting 0 in this bit unless it's time to take in that reservation to put it to use. NewRisingSun wants it to be clear what should go into a header for any given thing that already exists. Saying to use 0..0 and not 0..1 for mapper-controlled mirroring addresses that. It also might help dispel misconceptions like "0..1 on MMC1 should power-on the mapper with that mirroring" that pop up from time to time.

Other than doing that, though, I don't know what iNES 2.0 is supposed to clarify over iNES 1 for this field. CHR-RAM size is definitely something that needs to be explained for iNES 2, but the mirroring bits from prior use are pretty consistent for the existing/defined iNES 1 cases, aside from a bunch of uses of bit 0 while it's ignored?

The existing use probably needs some improvement of documentation, which is why I started adding some info to the wiki's iNES page, but I don't see much role that iNES 2.0 has to play in this, other than taking back and reserving the undefined cases.


I don't think anyone wants that.

This is where there is a disagreement among us. Sure, there was no games released on, say, mapper #2 and 4-screen mirroring simultaneously. However, we know how to create 4-screen mirroring (either by adding a 8k RAM on the board like Rad Racer 2, or by adding a 2k RAM and an extra chip to do the decoding, like Gauntlet). Both are functionally equivalent in terms of how the hardware responds and how it's emulated - only the actual hardware is different. In both of those cases, the VRAM is not connected to the mapper in any way. Thus this trick could easily have been made with any other mapper - it just happened by pure chance that both games using this feature happened to be on MMC3. But they could have easily built with any other mappers as well - again, this is completely orthogonal.

The same applies to PRG-RAM and battery bacup. It happened that some mappers had no games with PRG-RAM nor battery backup. But we know how it would be made, and they are supposed to be emulated fine, in the origianl iNES mindset. We agree this mindset is far from perfect, but nevertheless that's how it works whether we like it or not.


This is unacceptable for MMC1, as mirroring control bits are ont he same registers as other bits which should still be written to in case of 4-screen mirroring.


I currently have no plans for ever using 4-screen mirroring in any of my homebrews - but someone else could or why not in the future I could. I see no reason to be forced to use MMC3 "just because that's what the officially released games used".
When developing homebrew we require not any emulator but good accurate emulators such as Nintendultor or Nestopia - or with debugging features such as FCEUX.

EDIT : Now let's say that as a homebrewer I'd like to use 4-screen mirroring and MMC3, but with more than 128KB of PRG-ROM. Or more than 64KB of CHR-ROM. Or with CHR-RAM instead of CHR-ROM. Or with PRG-RAM and maybe why not battery backup. Neither of those were done by existing released games. Are they "forbidden" too, just because of that ? If yes, then at least the logic is coherent - i.e. "only emulates board which actually exists". If no, then it is completely incoherent.

I'm not "forcing" someone to use MMC3, I was just suggesting it is just the mapper to use if the widest emulator compatibility is really your goal, as a homebrewer. That will remain true regardless of whatever we're talking about specifying.

Also, amusingly enough I did talk to one person earlier today who has been using BxROM + 4-screen, not really as their intended release hardware, but instead as a compatible surrogate for GTROM, which currently fewer emulators support than BxROM + 4-screen.


To be clear, I like that interpretation of bit 3 as applying to nearly everything, and I am perfectly in favour of emulators being able to implement that in this space, but that's part of why I think it should be explicitly undefined. This leaves it up to the emulator author as to what is practical/desired for it until we have a game that needs to be emulated with it, and at the same time doesn't burden anybody who isn't interested in potential maybe future games.

It also means that when hardware is actually created for it, we can see what arbitrary choices were made for that hardware, and specify exactly what it does, instead of overspecifying it right now ahead of the fact and probably getting it subtly wrong.

As I said before, I can live with any well-specified solution. I personally have no problem with saying "The H/V mirroring bit must be ignored, and should be clear, when there is mapper-controlled mirroring. The 4-screen-bit overrides any mapper-controlled mirroring and forces four independent non-bankable nametables at all times." The beauty of the last solution is that it would work nicely with the 4-screen versions of Mappers 4 and 206 as well as the Vs. System without having to specify any special rules for them. It still also works nicely with mapper 77 -- I do not think we can ever dispense with tautology for that one ---, and it follows nicely that it must not be set for mappers 356 and 512, for they must software-control H/V/4 mirroring types. That would indeed dispense with the "disciplinary value" criterion, but it's not something I am particularly invested in.

I believe that actually came from the time when it was not known that the early Namco games used the N118 and not the MMC3, and was necessary in order to be able to run both as mapper 4. Thanks to the addition of Mapper 206, that annoying custom can be put to rest completely.

I added a somewhat hedged sentence to the NES 2.0 wiki entry that attempts to resolve the issue by explaining what perfect iNES compatibility would entail but does not explicitly require such behavior.