rainwarrior wrote:I wasn't asking for any specification for things that don't matter.
I cannot accept any ambiguity. Everything must be specified
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:
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.