NES 2.0 submappers

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

NES 2.0 submappers

Post by tepples »

It's been six years since the NES 2.0 spec was first published, and kevtris and I are finally getting around to defining some values for the submapper field.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Re: NES 2.0 submappers

Post by MottZilla »

Glad to see it finally being used.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: NES 2.0 submappers

Post by nocash »

From the wiki page:
One proposed general principle for backward compatibility is that submapper 0 be reserved for the default iNES

Good idea! Apply that proposal!
If it's 0 then the emulator/tools can try to guess or autodetect what mapper is meant (as happens in old rom images).
If it's 1..15 then emulator/tools can rely on the submapper number (as happens in newer/updated rom images).
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: NES 2.0 submappers

Post by tokumaru »

nocash wrote:If it's 0 then the emulator/tools can try to guess or autodetect what mapper is meant (as happens in old rom images).
If you want the old behavior, wouldn't it be better to just not update the header to iNES 2.0? I mean, why go through the trouble of using the more complete header if you have nothing to add?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 submappers

Post by tepples »

Part of it has to do with behavior subtleties in extant mapper variants that have not yet been fully characterized.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 submappers

Post by rainwarrior »

I'm kinda wondering about the question of whether to use a submapper, or assign a new mapper. Forgive me if this has already been said, but to me, it seems the only important value of the submapper field is that it will be ignored by emulators that don't support iNES 2.0, allowing them to fall back on a "mostly compatible" version of the mapper.

I don't know if you share my line of reasoning here, but I think it leads to the following two principles:

- If a game already has an assigned mapper, don't change it, because there's already an iNES 1.0 fallback implementation.
- Don't introduce submappers that can't acceptably fall back to the iNES 1.0 version of that mapper. (Assign a new mapper instead.)


I also like the idea that submapper 0 just means the default iNES 1.0 handling. I think this also suggests:

- All submappers except 0 must unambiguously specify a single implementation, and not be dependent on external configurations like PRG / CHR / CRC.
- All iNES 1.0 mappers that have ambiguities resolved by external configurations must be given a submapper for each case that needs resolution.


Finally, iNES 2.0 only mappers (mappers 256+) have no concern for iNES 1.0 backward compatibility. For these, it should be acceptable to group related mappers by submapper. For instance, the proposed 1-chip mapper has a lot of jumper configurations which could be presented as submappers of, say, mapper 257.


I'm proposing these guidelines in the interest of needing less arbitration about what to do in various cases. (Personally, I don't have much stake in it anyway, since I'm really quite happy living within the confines of iNES 1.0 for my own purposes.)


Another question re: the proposal on the wiki: if you're going to have an option to force NINA for mapper 34, why not also have an option to force BNROM? What is the Union Bond mapper? (Does it have a 5 bit latch?)
Last edited by rainwarrior on Fri Sep 28, 2012 6:32 pm, edited 2 times in total.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: NES 2.0 submappers

Post by Bregalad »

Another question re: the proposal on the wiki: if you're going to have an option to force NINA for mapper 34, why not also have an option to force BNROM?
I agree.
I'd definitely see a higher probability of someone ever wanting to do BNROM + 8kb CHR-ROM than someone wanting to clone NINA's weird and strange mapper with CHR-RAM.

As for why both were assigned to the same number, I suspect two different people assigned it at about the same time without consulting eachother. This is pure speculation though.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 submappers

Post by rainwarrior »

Added a suggestion above about submappers for iNES 2.0 only mappers (256+).
iNES 2.0 only mappers (mappers 256+) have no concern for iNES 1.0 backward compatibility. For these, it should be acceptable to group related mappers by submapper. For instance, the proposed 1-chip mapper has a lot of jumper configurations which could be presented as submappers of, say, mapper 257.
Or, I suppose we could even be crafty and stick it in mapper 256 or 512 or something that would read as mapper 0 in iNES 1.0...

Are we supposed to pick iNES 2.0 mapper numbers according to what iNES 1.0 mapper they might best fall back on?
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: NES 2.0 submappers

Post by nocash »

Currently, submappers are used to fix old mis-defined NES 1.0 roms.
In future, similar mis-definitions might occur also in NES 2.0 roms.
So, I think, even in NES 2.0 files, submapper numbers should be kept reserved for future bugfixes.

BNROM... I think it was originally defined as mapper 7 (AOROM), I've seen an old Deadly Towers rom-image from 1997 assigned like so, and then somebody "corrected" it by assigning it as mapper 34 (NINA-001). In so far, both mapper 7 and 34 may need a BNROM submapper number.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: NES 2.0 submappers

Post by zzo38 »

nocash wrote:Currently, submappers are used to fix old mis-defined NES 1.0 roms.
In future, similar mis-definitions might occur also in NES 2.0 roms.
So, I think, even in NES 2.0 files, submapper numbers should be kept reserved for future bugfixes.

BNROM... I think it was originally defined as mapper 7 (AOROM), I've seen an old Deadly Towers rom-image from 1997 assigned like so, and then somebody "corrected" it by assigning it as mapper 34 (NINA-001). In so far, both mapper 7 and 34 may need a BNROM submapper number.
I think you should enforce it more, and if the header specifies NES 2.0 then assume that the header is correct. (If it does not specify NES 2.0, then use checksums and whatever to correct the header automatically.)
rainwarrior wrote:Or, I suppose we could even be crafty and stick it in mapper 256 or 512 or something that would read as mapper 0 in iNES 1.0...

Are we supposed to pick iNES 2.0 mapper numbers according to what iNES 1.0 mapper they might best fall back on?
Well, I suppose you can do this if making a game that uses mapper 256, which might also work in mapper 0 or otherwise will detect if it is running on mapper 0 and display an error message saying that you require a emulator compatible with NES 2.0.
(Free Hero Mesh - FOSS puzzle game engine)
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: NES 2.0 submappers

Post by nocash »

I think you should enforce it more, and if the header specifies NES 2.0 then assume that the header is correct. (If it does not specify NES 2.0, then use checksums and whatever to correct the header automatically.)
Yes, that's the idea behind the NES 2.0 specs. What do you want to enfore more?
Ìf things go wrong in future, then you'll need to use the "checksums and whatever" tricks also for some NES 2.0 files.
rainwarrior wrote:Are we supposed to pick iNES 2.0 mapper numbers according to what iNES 1.0 mapper they might best fall back on?
Oh, no, please not! That would look messy. Better suggest to allocate numbers straightly increasing from 256 and up.
For the "best fall back on" thing, that's what the submapper number is intended for.
rainwarrior wrote:Or, I suppose we could even be crafty and stick it in mapper 256 or 512 or something that would read as mapper 0 in iNES 1.0...
In that special case, for mapper 0, it's a good idea. I suspect that there are plenty "mapper 0" roms that aren't NROM (things like the Game Genie bios, for example). If there are too many such mapper 0 variants then the 15 submapper numbers won't be enough ro resolve that mess, using 256 and 512 would extend available space for "NROM" variants.
But then it would need to be defined/reserved for that purpose right NOW. So that emulator programmers can implement the required "fallback on mapper 0" - else the fallback trick would work only for very-old NES 1.0 emus, while the current NES 2.0 emus would see 256 as unsupported mapper.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: NES 2.0 submappers

Post by nocash »

http://wiki.nesdev.com/w/index.php/INES_Mapper_023 tells that mapper 23 is used for three different boards, one VRC2 board, and apparently two VRC4 boards (I don't know what game is using VRC4f though). That'll be needed to be puzzled into the submapper definitions, too. The VRC2 won't match too well with the "treat submapper bits as address lines" stuff. Would have been better to use submappers 1 and 2 for VRC4 variants, instead of doing that address-line mapping.

And the submapper page chapters should be better strictly sorted by mapper numbers. At the moment some entries are filed under board names like VRC4 and MMC1, and others are filed under mapper numbers. That's confusing, and VRC4 as chapter name doesn't work out for cases like the shared VRC4+VRC2 mapper number.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 submappers

Post by rainwarrior »

Yeah, cancel my thoughts on 256+ mappers maybe having a fallback. That's probably counterproductive. The only thing is that unlike the 255- mappers, when run as iNES 1.0 they're going to fall back to a random mapper. Not a great error condition.

I dunno what I'd suggest, though. We could reserve another 8 bits for extended mapper number, and make them all use the same iNES 1.0 mapper number. At least then, something more predictable could happen.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: NES 2.0 submappers

Post by zzo38 »

nocash wrote:
I think you should enforce it more, and if the header specifies NES 2.0 then assume that the header is correct. (If it does not specify NES 2.0, then use checksums and whatever to correct the header automatically.)
Yes, that's the idea behind the NES 2.0 specs. What do you want to enfore more?
If things go wrong in future, then you'll need to use the "checksums and whatever" tricks also for some NES 2.0 files.
I think it is a very bad idea...you should write on the specification, any file specifying NES 2.0 in the header MUST NOT have incorrect and the program reading it MUST NOT automatically change it to something else.

Another thing to specify is how a trainer and battery RAM is interacted (my suggestion: a part of the battery RAM is initialized with the trainer data, and if a battery RAM file already exists, ignore the trainer; what do existing emulators already do about this, and do any such files already exist?).

However, I don't know what the checksums are and it might be difficult to write the emulators to add these mappers supports, especially with the checksums and so on using, so my solution to this problem is: (link) (yes, the specific paragraph I am linking to is relevant; the rest is unimportant to this discussion) It would be a more precise specification of what each iNES mapper means and what the other stuff in the file means. (I have heard of a program which compiles a hardware description into software codes using GCC)
(Free Hero Mesh - FOSS puzzle game engine)
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: NES 2.0 submappers

Post by nocash »

I think it is a very bad idea...you should write on the specification, any file specifying NES 2.0 in the header MUST NOT have incorrect and the program reading it MUST NOT automatically change it to something else.
Of course NES 2.0 headers SHOULD be correct. But that won't be always the case - things can go wrong there.
Normally you'd trust NES 2.0 headers with submapper=0 to be correct. If you KNOW that there are multiple definitions for a NES 2.0 mapper number then you can try to detect the desired mapper type (via known ROM checksum databases or other trickery). If there is a NONZERO submapper number than you can rely on that value and do need the detection trickery.
Another thing to specify is how a trainer and battery RAM is interacted (my suggestion: a part of the battery RAM is initialized with the trainer data, and if a battery RAM file already exists, ignore the trainer; what do existing emulators already do about this, and do any such files already exist?).
I've never thought about that special case: Trainer PLUS battery. Yes, that should defined. Your suggestion looks fine... from the how-it-should-work point of view. The way how-it-did-actually-work might have been different, and then we should keep that behaviour.
What I mean is: The "trainers" are (as far as I know) dated back to old copiers (equivalents to modern flashcarts, that loaded ROMs from built-in floppy disc drives into built-in RAM). And emulators should adopt their behaviour.
Does anybody know how original copiers did handle the trainer bit? I would suspect that they did destroy the first 512 bytes of saved battery ram (if they did support saving at all), and did overwrite it by the "trainer" data (?)
Post Reply