It is currently Fri Jul 19, 2019 5:00 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 58 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
PostPosted: Mon Aug 22, 2016 11:22 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2097
Location: WhereverIparkIt, USA
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Last edited by infiniteneslives on Tue Aug 30, 2016 11:13 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 11:46 am 
Offline
User avatar

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


Last edited by rainwarrior on Tue Jan 08, 2019 2:55 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 1:33 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4191
There's always the old "four screen" iNES 1.0 flag.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 1:42 pm 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 6:04 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
As an alternative, there are actually 4 possible mirroring configurations:
Code:
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)

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.


Last edited by rainwarrior on Tue Jan 08, 2019 2:53 pm, edited 3 times in total.

Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 11:47 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 965
4scr&vert = 1scr? Seconded. (This also means we could drop Major League's submapper.)
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..

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


Top
 Profile  
 
PostPosted: Tue Aug 23, 2016 11:39 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
Myask wrote:
(This also means we could drop Major League's submapper.)

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


Top
 Profile  
 
PostPosted: Tue Aug 23, 2016 8:36 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 965
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.


Top
 Profile  
 
PostPosted: Sun Jan 06, 2019 2:51 pm 
Offline
User avatar

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

Code:
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


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:

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.


Last edited by rainwarrior on Sat Feb 23, 2019 5:23 pm, edited 3 times in total.

Top
 Profile  
 
PostPosted: Sun Jan 06, 2019 3:01 pm 
Offline

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


Top
 Profile  
 
PostPosted: Sun Jan 06, 2019 4:05 pm 
Offline

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


Top
 Profile  
 
PostPosted: Sun Jan 06, 2019 5:39 pm 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Mon Jan 07, 2019 12:20 am 
Offline

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


Top
 Profile  
 
PostPosted: Mon Jan 07, 2019 1:02 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Mon Jan 07, 2019 1:22 am 
Offline

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


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Majestic-12 [Bot] and 4 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