It is currently Sun Nov 19, 2017 6:53 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 105 posts ]  Go to page 1, 2, 3, 4, 5 ... 7  Next
Author Message
 Post subject: NES 2.0 submappers
PostPosted: Wed Sep 26, 2012 8:44 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19227
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Thu Sep 27, 2012 11:52 am 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2803
Glad to see it finally being used.


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Fri Sep 28, 2012 1:41 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 534
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).


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Fri Sep 28, 2012 2:15 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
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?


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Fri Sep 28, 2012 2:40 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19227
Location: NE Indiana, USA (NTSC)
Part of it has to do with behavior subtleties in extant mapper variants that have not yet been fully characterized.


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Fri Sep 28, 2012 3:11 pm 
Offline
User avatar

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

Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Fri Sep 28, 2012 3:15 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Fri Sep 28, 2012 6:33 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
Added a suggestion above about submappers for iNES 2.0 only mappers (256+).
Quote:
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?


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Fri Sep 28, 2012 9:51 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 534
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.


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Fri Sep 28, 2012 10:12 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
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.

_________________
.


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Sat Sep 29, 2012 10:27 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 534
Quote:
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.


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Sat Sep 29, 2012 12:10 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 534
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.


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Sat Sep 29, 2012 1:25 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Sat Sep 29, 2012 1:47 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
nocash wrote:
Quote:
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)

_________________
.


Top
 Profile  
 
 Post subject: Re: NES 2.0 submappers
PostPosted: Sun Sep 30, 2012 10:02 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 534
Quote:
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.

Quote:
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 (?)


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Donqustix and 5 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