It is currently Tue Jan 22, 2019 9:55 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 57 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Mon Jan 07, 2019 1:47 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Mon Jan 07, 2019 3:55 am 
Offline

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


Top
 Profile  
 
PostPosted: Mon Jan 07, 2019 2:01 pm 
Online

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


Top
 Profile  
 
PostPosted: Mon Jan 07, 2019 2:53 pm 
Offline
User avatar

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

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.


Top
 Profile  
 
PostPosted: Tue Jan 08, 2019 8:52 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7651
Location: Chexbres, VD, Switzerland
lidnariq wrote:
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

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.


Top
 Profile  
 
PostPosted: Tue Jan 08, 2019 12:47 pm 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Tue Jan 08, 2019 12:48 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7977
Location: Seattle
"Ignoring the subsequent mess that the homebrew community has made of the header bits" is the entirety of my desire.


Top
 Profile  
 
PostPosted: Tue Jan 08, 2019 1:19 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7651
Location: Chexbres, VD, Switzerland
rainwarrior wrote:
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.

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


Top
 Profile  
 
PostPosted: Tue Jan 08, 2019 2:08 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 805
I agree.
rainwarrior wrote:
So... specify whatever you like for that, I guess?
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?


Top
 Profile  
 
PostPosted: Tue Jan 08, 2019 2:17 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7651
Location: Chexbres, VD, Switzerland
NewRisingSun wrote:
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."[/list]Rationale:[list]

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.

Quote:
Memory hardwired for four-screen mode, denoted by Header Byte $6 bit 3, is not included in the CHR-RAM size."


Is much simpler to understand than.
Quote:
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.


Top
 Profile  
 
PostPosted: Tue Jan 08, 2019 2:28 pm 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jan 08, 2019 2:35 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7118
Location: Canada
NewRisingSun wrote:
I agree.
rainwarrior wrote:
So... specify whatever you like for that, I guess?
You asked for it:[list]

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

NewRisingSun wrote:
I am not buying the argument that the 4-screen-bit is "legacy" and thus should not be used for new mappers.

I am also not buying the argument that submappers are only to disambiguate mappers that were defined before NES 2.0.

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.

NewRisingSun wrote:
Okay?

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.


Top
 Profile  
 
PostPosted: Tue Jan 08, 2019 2:44 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 805
rainwarrior wrote:
I wasn't asking for any specification for things that don't matter.
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.


Top
 Profile  
 
PostPosted: Tue Jan 08, 2019 3:48 pm 
Offline
User avatar

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

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.


Top
 Profile  
 
PostPosted: Thu Jan 10, 2019 1:16 pm 
Offline

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


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


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

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