- Posts: 2099
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
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.
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.
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.
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.)
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.Dwedit wrote:There's always the old "four screen" iNES 1.0 flag.
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.
Code: Select all
iNES byte 6 7......0 ======== A ----0--0 horizontal mirroring B ----0--1 vertical mirroring C ----1--0 4-screen (horizontal but ignored) D ----1--1 4-screen (vertical but ignored)
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.
That's a link to edit the post, which we can't. You want this. (Also, the topic does say "dev/repro" board…)infiniteneslives wrote: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..
According to the submappers page, it's not just the mirroring that's different, so I don't think we could.Myask wrote:(This also means we could drop Major League's submapper.)
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:
Code: Select all
The nametable mirroring bits in byte 6 of the [[iNES]] header select one of four configurations of nametables: %....0..0 - Vertical arrangement %....0..1 - Horizontal arrangement %....1..0 - 1-Screen, switchable %....1..1 - 4-Screen, cartridge VRAM
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: 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.
But... wishes and fishes.
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.
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.)
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?
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.
"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.