It is currently Fri Nov 24, 2017 3:13 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: VRC2/VRC4 submapper hell
PostPosted: Fri Apr 28, 2017 1:58 am 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 431
Is this the right board for iNES 2.0 submapper proposal discussion? If it isn't, please move this topic to a more suitable board.

The consensus (?) proposal for submappers for iNES mappers 21/23/25 is as follows:

Code:
3210
||||
|+++- Which address line corresponds is wired to the A1 in the VRC4a
+---- 0: Use next lower address line for VRC4a A2; 1: use next higher line


However, this encoding (specifically, the use of the high bit) is redundant with the existing mapper numbers. All games that have the two register-selecting address lines in natural order (i.e. the registers that set the low and high nybble of the same CHR bank are adjacent to each other) use mapper 21 or 23, and all games with the lines in reversed order use mapper 25. Since the mapper number consistently indicates what order the lines are in, there's no need to use a bit in the submapper field to specify it again.

According to the wiki page for iNES 2.0 submappers, "test ROMs" are needed before a proposal can be accepted. How exactly are these test ROMs supposed to work? I can hack up a VRC2/VRC4 test program that'll test a cartridge (or an emulator implementation) and report which address bits are connected to which lines on the mapper (including multiple bits ORed together), whether 1-screen mirroring is supported (VRC2/VRC4 difference), and whether IRQs are supported (another VRC2/VRC4 difference) if that's what the community is looking for.

As an aside, can someone explain exactly what this sentence (from the wiki VRC2 article) is supposed to mean?

Quote:
A third variant (similar to VRC2a but with full-width CHR registers and PRG-RAM) is canonically emulated as using the VRC4, and it's assigned to mapper 25.


Seriously, what the hell is it supposed to mean that a game is "canonically emulated" using a chip that's different from the one on the cartridge? This kind of nonsense makes me want to run screaming from the NESdev community.

ETA: Also, the fact that the ending in Ganbare Goemon Gaiden sets the CHR banks wrong on a real cartridge should probably be referenced somewhere on the wiki so emulator developers don't chase spurious bugs.


Top
 Profile  
 
PostPosted: Fri Apr 28, 2017 4:53 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19257
Location: NE Indiana, USA (NTSC)
I kind of messed that one up. I made it so general (effectively a barrel shifter) because I wasn't quite confident that the community had discovered and dumped the entire library of VRC-using games. And I made it before the "'test ROMs' are needed before a proposal can be accepted" era, instead in the "run it past kevtris in #nesdev on EFnet and see what he calls plausible" era.

Things that don't work in actual NES and Famicom games go in Game bugs.


Top
 Profile  
 
PostPosted: Fri Apr 28, 2017 10:24 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6455
Location: UK (temporarily)
wiki wrote:
A third variant (similar to VRC2a but with full-width CHR registers and PRG-RAM) is canonically emulated as using the VRC4, and it's assigned to mapper 25.
For reasons of modern sloppiness and historical something, Ganbare Goemon Gaiden has a VRC2, doesn't set the mirroring control register to a value other than 0 or 1, and has extra hardware to keep the VRC2's microwire port from conflicting with the RAM that's on board.

Because the combination of both our documentation and time spent looking closely at the boards is very slow, the specific instance of "Wait a moment, that board doesn't use the VRC4 despite having RAM" has produced the above text.

Quote:
Seriously, what the hell is it supposed to mean that a game is "canonically emulated" using a chip that's different from the one on the cartridge? This kind of nonsense makes me want to run screaming from the NESdev community.
Remember that every single VRC2 game is "canonically emulated" as running on a VRC4 with RAM by 99% of emulators. This is only something we've even begun to try to set right in recent memory.


Top
 Profile  
 
PostPosted: Fri Apr 28, 2017 10:42 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5839
Location: Canada
I don't think there's consensus behind that assignment. I proposed this one instead, but nobody has commented:
https://wiki.nesdev.com/w/index.php/NES_2.0_submappers/Proposals#Alternative_Submapper_Assignment

I do not like the mapping tepples proposed because it:
  • Allocates all 16 submappers for no reason. Each of these mappers only has 2 address variations.
  • Aside from the 2 current known variants, the rest of the submapper allocations are meaningless because they're already assigned to other mappers anyway.
  • Does not encode VRC2 vs VRC4.
  • If any unknown variants exist we've shot ourselves in the foot by using up all the allocations.
  • Etc.

The only reason I didn't outright delete that proposal was that nobody else seemed to care, so there was no comment for consensus.

My proposal instead was organized with only known variations:
  • 021: 1 VRC4a (A2, A1)
  • 021: 2 VRC4c (A7, A6)
  • 021: 3 unseen VRC2 (A2, A1)
  • 021: 4 unseen VRC2 (A7, A6)
  • 023: 1 VRC4f (A1, A0)
  • 023: 2 VRC4e (A3, A2)
  • 023: 3 VRC2b (A1, A0)
  • 023: 4 unseen VRC2 (A3, A2)
  • 025: 1 VRC4b (A0, A1)
  • 025: 2 VRC4d (A2, A3)
  • 025: 3 VRC2c (A0, A1)
  • 025: 4 unseen VRC2 (A2, A3)

The ones marked "unseen" can be omitted, as there's no known cases. They're just to show there's actually a convenient symmetry to them (not necessary to preserve, IMO). The symmetry is:
  • 0. iNES 1 behavior (VRC4 + both addressings)
  • 1. Lower address VRC4
  • 2. Higher address VRC4
  • 3. Lower address VRC2
  • 4. Higher address VRC2

If there's yet another variation that's not covered I think just add it to the end of the list.

"Canonically" is a weird word to use but the meaning is that most emulators treat everything as VRC4.


I put the "test ROM" requirement in because the submappers page was full of half baked crap that was either untestable or otherwise unimplementable. A test ROM for this should:
  • Determine which of the 2 (or 6, or 16) address line mappings the cartridge it is using has. Since emulators generally support two addressings at once it should report both if true.
  • Determine whether VRC2 or VRC4 is present.
  • Optionally: test each of the VRC2/4 features to make sure they're emulated correctly.

Once you've created the ROM, just make one copy for each submapper and change the header for each.

Anyhow, that's it, basically. Once you have a test ROM it's very easy for someone to implement the submappers in an emualtor and test them. It becomes clear that you've implemented it correctly only with such a ROM. You can't just run, some VRC2 game and see if implementing the submapper makes a difference because there isn't one. It really does need its own test ROM.

A VRC2/4 test ROM has been on my to do list for a long time, but given the lack of general interest in it, I've put it off. If you want to write one that's great.


tepples wrote:
"run it past kevtris in #nesdev on EFnet and see what he calls plausible" era.

kevtris never seemed to care if the VRC2/4 mappers got submappers. I don't think there's any known compatibility issues, this is an accuaracy issue only.


Top
 Profile  
 
PostPosted: Fri Apr 28, 2017 10:58 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6455
Location: UK (temporarily)
rainwarrior wrote:
I don't think there's any known compatibility issues, this is an accuaracy issue only.
There's some pedantry about whether these two count as compatibility:
* The workaround for the bug exposed by emulating Wai Wai World as VRC4, and
* The bug in the credits of Ganbare Goemon Gaiden would produce a different set of wrong tiles if restricted to just the actual VRC2 board it's on instead of the combined VRC2/4 mapper that it's emulated as.


Top
 Profile  
 
PostPosted: Fri Apr 28, 2017 11:09 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5839
Location: Canada
The point I was making was that test ROMs will test your implementation a lot better/faster.

...but yes, I'd expect there to be some obscure differences in existing games. I was just unaware of any known ones, so thanks for finding some.

As to whether to classify something as compatibility or accuracy, I don't think these are binary terms. There is a grey area poorly defined between them.


Top
 Profile  
 
PostPosted: Fri Apr 28, 2017 11:22 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5839
Location: Canada
By the way, the wiki's current organization of stuff on these mappers is horrible. Here's the relevant pages in case someone wants to go on an expedition:

(These should probably be merged into one page. I was planning to, but lack of interest made it not a priority.)

Edit: Never mind, I've now merged them into: VRC2 and VRC4


Top
 Profile  
 
PostPosted: Fri Apr 28, 2017 1:51 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 299
For what it's worth, Mesen uses its internal game DB to assign submapper numbers when needed (based on board name, etc.) and currently assigns the VRC2/4 submappers based on rainwarrior's proposal, since they made more sense to me (and no test roms existed for VRC2/4 submappers)


Top
 Profile  
 
PostPosted: Sat Apr 29, 2017 3:55 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 431
tepples wrote:
I wasn't quite confident that the community had discovered and dumped the entire library of VRC-using games


There are a handful of Japanese MMC3 Konami games (e.g. F-1 Sensation and the Japanese versions of a bunch of US games) without bootgod-verified dumps. How confident are we that those games really are MMC3 and the dumps floating around aren't mapper hacks?


Top
 Profile  
 
PostPosted: Sat Apr 29, 2017 11:17 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5839
Location: Canada
AWJ wrote:
tepples wrote:
I wasn't quite confident that the community had discovered and dumped the entire library of VRC-using games

There are a handful of Japanese MMC3 Konami games (e.g. F-1 Sensation and the Japanese versions of a bunch of US games) without bootgod-verified dumps. How confident are we that those games really are MMC3 and the dumps floating around aren't mapper hacks?

I can't comment on whether those games might be secretly VRC2/4 games, but the original submapper proposal doesn't help even if they are. Mappers 21/23/25 support exactly TWO address schemes each-- if there is an undiscovered addressing scheme it will go in a new mapper, not a submapper.


Top
 Profile  
 
PostPosted: Sun Apr 30, 2017 4:01 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
Well, I'd prefer putting them in the same, but I suppose if we're going to keep supporting iNES over NES2.0 for some reason, it'd be necessary…


Top
 Profile  
 
PostPosted: Sun Apr 30, 2017 5:36 pm 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 568
Location: -29.794229 -55.795374
The situation can become even worse if the emulator tries to support the many VRCx hacks that are floating around, like this, this, and this!


Top
 Profile  
 
PostPosted: Sun Apr 30, 2017 5:57 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5839
Location: Canada
Fisher wrote:
The situation can become even worse if the emulator tries to support the many VRCx hacks that are floating around, like this, this, and this!

If the pirate clone is "compatible" with existing mapper 21, 22, 23, 25 it's fine to put them there, and also fine to propose a submapper to account for its minute/accuracy-oriented differences. That's what submappers are for: to add refined disambiguation to mappers that were otherwise "mostly fine" combined into one iNES mapper before.

This is also why I thought it was a terrible idea to pre-emptively allocate all 16 submappers-- there is potentially other stuff still in these categories, besides the 2 or 3 already known cases. It was allocating every single combination of addressings even though the underlying iNES mapper could only support at most four, and very much should not be trying to support more than the two they already have, which was too many to begin with (but we're stuck with).

What I am opposed to is adding additional incompatible addressings to 21, 22, 23, 25, making them even more muddled than they already are. The iNES implementation of 21 is a "two-in-one"... don't modify the iNES mapper to make a "four-in-one". If you find a new VRC2/4 addressing, create a new mapper: it doesn't fit into any existing ones.

(Though, this is all moot until someone finds and adequately describes something new in this category anyway.)


Top
 Profile  
 
PostPosted: Sun Apr 30, 2017 7:09 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
Just saying I'd've allocated VRC2 to one and its addressings to subs, but…well, backwards compatibility hobble.

Besides, if a new dump requires submapper support, then wouldn't that pressure emulator authors to implement it?


Top
 Profile  
 
PostPosted: Sun Apr 30, 2017 7:24 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 431
Fisher wrote:
The situation can become even worse if the emulator tries to support the many VRCx hacks that are floating around, like this, this, and this!


Those bootlegs are all using a VRC2 clone with one-screen mirroring and/or IRQ functionality (different from and incompatible with VRC4 IRQs) added via additional hardware. I thought that bootleg mappers with similar but incompatible behaviour to a licensed publisher's mapper get their own full mapper number, not a submapper (e.g. the countless multicart-MMC3 variants)


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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