Page 4 of 6

Posted: Sun Jan 03, 2010 1:56 pm
by tepples
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

Posted: Sun Jan 03, 2010 3:57 pm
by Zepper
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.

Posted: Tue May 25, 2010 3:52 am
by etabeta
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...

Posted: Fri Jun 04, 2010 10:43 pm
by etabeta
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.

Re: NES 2.0 "Official" Specification

Posted: Wed Aug 22, 2012 4:10 pm
by nocash
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)?

Re: NES 2.0 "Official" Specification

Posted: Wed Aug 22, 2012 4:27 pm
by tepples
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.)

Re: NES 2.0 "Official" Specification

Posted: Fri Aug 24, 2012 4:08 pm
by zzo38
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).

Re: NES 2.0 "Official" Specification

Posted: Fri Aug 24, 2012 5:00 pm
by lidnariq
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.

Re: NES 2.0 "Official" Specification

Posted: Tue Jan 22, 2013 1:28 pm
by WedNESday
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?

Re: NES 2.0 "Official" Specification

Posted: Tue Jan 22, 2013 2:12 pm
by rainwarrior
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.

Re: NES 2.0 "Official" Specification

Posted: Tue Jan 22, 2013 2:18 pm
by WedNESday
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.

Re: NES 2.0 "Official" Specification

Posted: Tue Jan 22, 2013 2:25 pm
by 3gengames
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.

Re: NES 2.0 "Official" Specification

Posted: Tue Jan 22, 2013 2:31 pm
by WedNESday
3gengames wrote:Who cares about the iNES 1 ROMS?
We all do when they contain incomplete board/submapper information.

Re: NES 2.0 "Official" Specification

Posted: Tue Jan 22, 2013 3:04 pm
by lidnariq
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.
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}.
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.
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.
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.

Re: NES 2.0 "Official" Specification

Posted: Tue Jan 22, 2013 3:21 pm
by WedNESday
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