It is currently Sat Nov 18, 2017 5:13 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 78 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
 Post subject:
PostPosted: Sun Jan 03, 2010 1:56 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19222
Location: NE Indiana, USA (NTSC)
After a recent discussion with kevtris on #nesdev, he and I decided to make it as official as anything else on the wiki.

http://wiki.nesdev.com/w/index.php/NES_2.0


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 03, 2010 3:57 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
In the NES 2.0 spec, kevtris wrote:
I have dumped the palettes from ALL of these PPUs, and have exact bit for bit copies of them.


- Is this available to public domain? I'd like to add/update my VS palette tables.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 25, 2010 3:52 am 
Offline

Joined: Wed Nov 29, 2006 10:11 am
Posts: 109
Location: Trieste, Italy
sorry for necro-digging this thread, but I would like add support for iNES 2.0 headers in MESS and I have a couple of questions:

1. can I assume

if ((flag7 & 0xc) == 0x8) iNES2.0
else older iNES
?

is there anything else I should check to identify the newer headers?

2. could you provide me with two sample headers for carts requiring different submappers, to play with? e.g. two mapper 34 'extended' headers setting the different submappers required? the wiki page is not really specific on how submappers should be handled, and I'd love to get rid of the crc hack I'm currently using [1]

thanks for the help


[1] in fact, in addition to adopting iNES2.0, I'm also working on adding support for separate CHR & PRG files, by using a MAME-like database in xml form, with an attribute for the PCB type. Combining the two methods (separate prg/chr for cart dumps + iNES2.0 for demo/homebrew and for backward compatibility with the ROMs most users want to load), I hope to remove the current crc checks for good...


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 04, 2010 10:43 pm 
Offline

Joined: Wed Nov 29, 2006 10:11 am
Posts: 109
Location: Trieste, Italy
sorry for the second necro-bumping, but I have now implemented basic iNES 2.0 support in MESS: we check if the format is 2.0, we check for additional mapper bits and for additional PRG/CHR bank bits. The remaining info are only logged at the moment (which should be more or less the same level of 2.0 compatibility offered by Nintendulator, according to the wiki ;) )

I would like to test the extended prg/chr feature somehow though. I seem to remember there was a multicart with 256 PRG banks, does anyone remember which game it was?

and what should be the extended header for this specific game (so that I can fix it manually)?

thanks for any help you might offer.


Top
 Profile  
 
PostPosted: Wed Aug 22, 2012 4:10 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 534
Came accross two things that need to be improved:

First, the existing Playchoice 10 ROM-Image format contains only the PC10 INST-ROM. but not the PC10 PROM (which is required for decrypting the INST-ROM). Please see here for my suggested change to the iNES (and NES 2.0) formats - viewtopic.php?f=2&t=9221

And second, the PPU type entry for VS System games is nice - but there are some games that can be DIP-switched to different PPUs (Atari RBI Baseball, Battle City, Star Luster, Super Sky Kid, Super Xevious, Tengen's Tetris, TKO Boxing, and maybe more).
For that games, specifying something like "PPU Tyoe when all corresponding DIP-Switches are OFF" would be clearer.

Agree with that two things? Better ideas?

And where would one change or ask to change such specs? Is this http://wiki.nesdev.com/w/index.php/NES_2.0 the "official" specification (and changes to that page would become official)? Or is Kevin somewhere hosting the official specs (and one needs to contact him for changes)?


Top
 Profile  
 
PostPosted: Wed Aug 22, 2012 4:27 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19222
Location: NE Indiana, USA (NTSC)
As far as I can tell, the official spec is maintained there, but I'd recommend running substantial changes by Kevin first. (Connect to EFnet, join #nesdev, and see if kevtris is in the channel.)


Top
 Profile  
 
PostPosted: Fri Aug 24, 2012 4:08 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
My unofficial MagicKit now supports NES 2.0 (although it supports four extra bits for the mapper number instead of just one). (I later intend to add support for UNIF and DotFami as well)

One idea to use those two unused bits in iNES (which are used in NES 2.0 to indicate NES 2.0 mode if set to 10), so that if set to 01 or 11 then the rest of that byte is also ignored (so that if it contains "DiskDude!" then those bits will be 01 and only uses the low four bits of the mapper number).

_________________
.


Top
 Profile  
 
PostPosted: Fri Aug 24, 2012 5:00 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6440
Location: UK (temporarily)
The heuristic used by Nestopia is: If the last 6 bytes aren't 0 and those two bits aren't 0b10, then throw away the last 9 bytes.


Top
 Profile  
 
PostPosted: Tue Jan 22, 2013 1:28 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
So whats the deal with iNES 2.0?

I've been rewriting my emulator and I just cannot decide what to do when it comes to the header of the NES ROM. What with so many ideas being proposed but none actually being used I'm finding it impossible to actually do any decisive.

The wiki is just full of 'ideas' for the extended iNES header. Take for instance mapper # 1. I can get the byte to know which mapper a ROM uses but what about which board etc. I refuse point blank to use a database for all the obvious reasons and I think that it is unreasonable just to check to see how much PRG bank there are too see if a ROM has UNROM or UOROM.

The truth is this should have all been done right back at the start of the whole NES emulation scene and I don't mean to disrepect anybody who was working on it at the time (I know that a lot of stuff wasn't known back then; bus conflicts, 100's of mappers (hence only 4 bits being originially designated for mappers)).

It seems to me that with the literally 1,000,000s of NES ROMs floating around the internet its simply too late to actually introduce a decent standard now. How on earth are we going to go back and find all of these ROMs and actually update them so that they are 2.0 compatible?

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Tue Jan 22, 2013 2:12 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
WedNESday wrote:
The wiki is just full of 'ideas' for the extended iNES header. Take for instance mapper # 1. I can get the byte to know which mapper a ROM uses but what about which board etc. I refuse point blank to use a database for all the obvious reasons and I think that it is unreasonable just to check to see how much PRG bank there are too see if a ROM has UNROM or UOROM.


But this is exactly what iNES 2 addresses. ?

WedNESday wrote:
It seems to me that with the literally 1,000,000s of NES ROMs floating around the internet its simply too late to actually introduce a decent standard now. How on earth are we going to go back and find all of these ROMs and actually update them so that they are 2.0 compatible?


The majority of popular ROMs are unambiguous with iNES 1 anyway, they don't need to be updated and should easily be backwards compatible for anybody who implements iNES 2. The rest can be updated by hand as found. I don't think this is an insurmountable task at all.


Top
 Profile  
 
PostPosted: Tue Jan 22, 2013 2:18 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
I know that 2.0 is supposed to address this but;

1. Why is the word proposed spread all over the wiki page?
2. Both Zeldas are examples of ROMs that don't have updated headers. Neither specify which board they use.
3. Do you really consider that with the 1,000,000s of NES ROMs out there that converting them all to iNES 2.0 isn't an impossible task? Obviously only god (if he actually uses nesdev for his own NES emulator) could track them ALL down.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Tue Jan 22, 2013 2:25 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
Yeah, but having one GOOD ROM set with the right iNES/iNES2 headers is all you need. Who cares about the iNES 1 ROMS? It'backwards compatible for a reason.

Still, we do need an OFFICIAL document that says "This is how it will be." as soon as that comes out, I'll update my ReadNES splitter too.


Top
 Profile  
 
PostPosted: Tue Jan 22, 2013 2:31 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
3gengames wrote:
Who cares about the iNES 1 ROMS?


We all do when they contain incomplete board/submapper information.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Tue Jan 22, 2013 3:04 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6440
Location: UK (temporarily)
WedNESday wrote:
The wiki is just full of 'ideas' for the extended iNES header.
Are you complaining about me pointing out what we need submappers for? I'm wary to act unilaterally, but should probably post in the submappers thread to that end.
Quote:
Take for instance mapper # 1. I can get the byte to know which mapper a ROM uses but what about which board etc.
iNES and NES 2 were never supposed to be unique mapping of {header}→{UNIF board}.
Quote:
I think that it is unreasonable just to check to see how much PRG bank there are too see if a ROM has UNROM or UOROM.
Why do you care about whether a game is UNROM or UOROM? They mean the same thing. Or are you talking about things like MMC1 SNROM vs SUROM? It doesn't make any sense to talk about a "SUROM" board with only 256KiB of PRG: a "SUROM" board with 256KiB is SNROM.

Quote:
The truth is this should have all been done right back at the start of the whole NES emulation scene and I don't mean to disrepect anybody who was working on it at the time (I know that a lot of stuff wasn't known back then; bus conflicts, 100's of mappers (hence only 4 bits being originially designated for mappers)).
The nice thing about hindsight is that it's hindsight. Being angry about it now doesn't help anyone. If you look at the order of the first 16 mappers, it's really clear that they were allocated in the order they were encountered by someone in the US.

Quote:
It seems to me that with the literally 1,000,000s of NES ROMs floating around the internet its simply too late to actually introduce a decent standard now. How on earth are we going to go back and find all of these ROMs and actually update them so that they are 2.0 compatible?
And that's the entire argument why NES2's backwards compatibility will help where UNIF failed.


Top
 Profile  
 
PostPosted: Tue Jan 22, 2013 3:21 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
http://wiki.nesdev.com/w/index.php/NES_2.0

Under where it says 'proposed' solution. Should that adjective still be there or is it safe to assume that all data present can be safely implemented?

Regardless of what iNES was ever supposed to be, it is what it needs to be and that is to carry all of the necessary cartridge information that would influence its emulation.

I care whether a ROM is UNROM or UOROM (Mapper 2 btw) because UOROM uses an extra bit when mapping ROM to 8000. I consider checking to see whether a ROM is either 128kB or 256kB a sloppy way of checking a mapper's board. To be more precise I'm more interested in mappers that have a lot of boards like MMC3.

http://wiki.nesdev.com/w/index.php/TxROM

_________________
http://www.jamesturner.de/


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

All times are UTC - 7 hours


Who is online

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