NES 2.0 "Official" Specification

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 "Official" Specification

Post by lidnariq »

WedNESday wrote: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?
Yes. The only bit not yet cleared up is submappers. And maybe allocating a bit in 'TV system' for games that targeted the Dendy, if any are found. For example, Nestopia has implemented all the field extensions (PRG, CHR, PRGRAM) for disambiguating boards.
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.
... You seem to think saying that has any influence on whether there are images out there that don't have all the information necessary to disambiguate it? Your only choice is to either distribute a database to promote iNES images to NES2 images or to reject iNES images that are not unambiguous. (Fortunately, most of them are unambiguous)
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.
There is absolutely no difference between a 128KiB game on UNROM vs on UOROM. A 256KiB game cannot exist on UNROM. The latch exists either way. The only difference is whether the ROM has an A17 line to be connected to. It is clear how the size of PRG disambiguates the board. It is only "sloppy" if you think it is meaningful to talk about how UxROM is actually a subset of mapper 78 or something.
To be more precise I'm more interested in mappers that have a lot of boards like MMC3.
The point of NES2 never was to make a "compressed UNIF". It will only lead to frustration if you continue to think of it that way. TKSROM and TLSROM are mapper 118. TQROM is mapper 119. NesCartDB has no instantiations of TEROM and TFROM using hardwired mirroring, but when we find one it will already have a submapper earmarked for that purpose. The rest are honestly functionally equivalent.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 "Official" Specification

Post by tepples »

WedNESday wrote: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.
You think wrong. I'm under the impression that memory sizes are exactly what Nintendo used to decide which board to use when manufacturing a game. Look at all the SxROM and TxROM boards that differ only in memory size. For example, MMC1 + PRG ROM over 256 KiB + 8 KiB CHR RAM + 8 KiB PRG RAM = SUROM.
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?
bsnes includes a "purify" tool that scans ROMs and corrects their headers. (In the case of Super NES ROMs, "correcting" involves stripping the copier header entirely.) A similar tool for NES emulation could scan a collection of iNES ROMs, possibly using a database of commercial releases prior to 1997 as lidnariq mentioned, and convert them to the equivalent NES 2.0 header.
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?
As far as I can tell, it's been a stable spec for several years, and even implemented in a few emulators.
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.
Which in turn is also all of the necessary cartridge information that would influence its reproduction, apart from label graphics. Tetris by Tengen is CNROM unless you don't consider Tengen's clone board to be CNROM. Battle Kid 1 is UOROM unless you don't consider the ReproPak board to be UOROM.
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.
Then Nintendo was sloppy.
To be more precise I'm more interested in mappers that have a lot of boards like MMC3.
If you look at the TxROM page on the wiki, you'll find that apart from TxSROM and TQROM, the only difference between most of them and TSROM/TLROM is the maximum supported ROM size.
lidnariq wrote:It is only "sloppy" if you think it is meaningful to talk about how UxROM is actually a subset of mapper 78 or something.
Or, for a more extreme example, how AMROM, ANROM, AOROM, BNROM, CNROM, NROM, UNROM, and UOROM have been retroactively made subsets by multicart mapper 28. I'm aware of one FPGA implementation of the NES that uses the mapper 28 code path to emulate mappers 0, 2, 3, 7, and 34 (CHR RAM variant).
WedNESday
Posts: 1284
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Re: NES 2.0 "Official" Specification

Post by WedNESday »

I not questioning why Nintendo used certains boards for certain games thats obvious. Nintendo wasn't sloppy when choosing which board to use for which game. I don't know what you mean by that.

I am fully aware that a computer program could be written to go back and update all of the 1.0 headers to 2.0 but that would be a big task and of course it would only affect the ROMs of the people who actually use it. Plus what if they use GoodTools to validate the header again the new information would be lost.

Just to clear things up here a bit I asked if the iNES 2.0 header that appears in the wiki was OK to use and it is, cool.

The point that I am trying to make is, I would like to be able to use a bit in the iNES 2.0 header to determine which board/submapper is being used.

Mapper 2 - 256kB Size - Most likely UOROM
Mapper 2 - 128kB Size - Most likely UNROM

This is a method that could be/is employed to determine which board/submapper is being used but I would rather get the information from the header. What about a Mapper 002 game that has 192kB of PRG? I'm not saying that a game like that exists but it would break any code that check the size of a ROM to detect board. Whats more what would happen if said ROM did use UOROM and it tried to switch to a non-existent bank?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 "Official" Specification

Post by tepples »

WedNESday wrote:I not questioning why Nintendo used certains boards for certain games thats obvious. Nintendo wasn't sloppy when choosing which board to use for which game. I don't know what you mean by that.
I'm saying that if something you do is no less sloppy than what Nintendo did in the same circumstances, nobody can reasonably fault you for doing it.
Plus what if they use GoodTools to validate the header again the new information would be lost.
It appears No-Intro is going 2.0, and ideally GoodNES should as well.
I would like to be able to use a bit in the iNES 2.0 header to determine which board/submapper is being used.

Mapper 2 - 256kB Size - Most likely UOROM
Mapper 2 - 128kB Size - Most likely UNROM
In cases where boards differ only in maximum supported ROM size, that bit is the ROM size field. In cases where a submapper is needed to distinguish functionally identical variants, such as VRC4, that bit is the submapper field.
What about a Mapper 002 game that has 192kB of PRG?
A non-power-of-two ROM size would require two ROM chips of different sizes. Among Nintendo discrete boards and Nintendo boards using Nintendo MMCs, there is no existing UxROM board with more than one such ROM. The only game with non-power-of-two PRG ROM that I know of is Action 52, and that's because it uses three PRG ROM chips each 512 KiB in size. Currently, 192 KiB of PRG on mapper 2 is "undefined behavior", and a header auditing tool should emit a diagnostic. If such a game would be released, which is unlikely because 256 KiB and larger flash is already very cheap, then the definition of these mappers would need to be updated to show how that mapper is being used in practice. I'd be willing to propose one precise definition for sums of two powers of two (3n^2 or 5n^2)
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 "Official" Specification

Post by lidnariq »

tepples wrote:A non-power-of-two ROM size would require two ROM chips of different sizes. Among Nintendo discrete boards and Nintendo boards using Nintendo MMCs, there is no existing UxROM board with more than one such ROM. The only game with non-power-of-two PRG ROM that I know of is Action 52, and that's because it uses three PRG ROM chips each 512 KiB in size.
In practice, the only hardware with non-powers-of-2 sizes we've ever seen are Vs System (Vs Gumshoe), the NROM-368 proposal, "Korean Igo", and large multicarts. (The other iNES images are hacks and translations that depend on specific emulator implementations, and the correct parsing is not known)

The package cost was simply too much larger than the mask ROM cost until the SNES hit 10mbit games.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: NES 2.0 "Official" Specification

Post by zzo38 »

A few suggestions:

Call the bit3 and bit2 of flags byte 1, the version bits. If the version bits are 00, it is standard iNES format. If the version bits are 10, it is NES 2.0 format, and all CRC32 checks for improper headers and so on should be disabled. If the version bits are 01 or 11, then treat it as if flags byte 1 is entirely zero.

For trainers: If there is a trainer set, treat it as follows:
  • Before hardware reset (I think one of the pins tristates on reset, so before that).
  • Disable rendering, audio, input, etc, and speed up to maximum emulation speed.
  • Hard write protect any battery RAM if a save file exists; if there is no save file, instead force write protect to be turned off.
  • Starting from $7000 and ending at $71FF, write the trainer data into PRG memory, with four clock cycles in between each write.
  • Turn off hard write protect of battery RAM.
  • Re-enable rendering, audio, input, etc, and reset to normal emulation speed.
  • Now do normal hardware reset.
  • If reads from $7000-$71FF are open bus, instead read the trainer data.
(Free Hero Mesh - FOSS puzzle game engine)
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: NES 2.0 "Official" Specification

Post by Quietust »

zzo38 wrote:Call the bit3 and bit2 of flags byte 1, the version bits. If the version bits are 00, it is standard iNES format. If the version bits are 10, it is NES 2.0 format, and all CRC32 checks for improper headers and so on should be disabled. If the version bits are 01 or 11, then treat it as if flags byte 1 is entirely zero.
This was actually the idea behind using those 2 bits in the first place - 00 means it's a normal ROM image, 01 means it's DiskDude!-corrupted (and should thus ignore that byte entirely), 10 means it's NES 2.0, and 11 means it's possibly something newer.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 "Official" Specification

Post by tepples »

I thought 00 + garbage in bytes 12-15 also meant corrupted, except that the corruption starts with one of the letters ABCPQRS.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: NES 2.0 "Official" Specification

Post by zzo38 »

Quietust wrote:
zzo38 wrote:Call the bit3 and bit2 of flags byte 1, the version bits. If the version bits are 00, it is standard iNES format. If the version bits are 10, it is NES 2.0 format, and all CRC32 checks for improper headers and so on should be disabled. If the version bits are 01 or 11, then treat it as if flags byte 1 is entirely zero.
This was actually the idea behind using those 2 bits in the first place - 00 means it's a normal ROM image, 01 means it's DiskDude!-corrupted (and should thus ignore that byte entirely), 10 means it's NES 2.0, and 11 means it's possibly something newer.
See below. (Further extensions probably can just use the currently unused bytes and bits of the header, and I thought this is how it was supposed to be designed?)
tepples wrote:I thought 00 + garbage in bytes 12-15 also meant corrupted, except that the corruption starts with one of the letters ABCPQRS.
I think I have checked and it never does start with ABCPQRS, but it does sometimes start with letters having bit2 and bit3 both set.

I do have a further proposal: Assign a bit in byte 12 (TV system) for mapper customization data added at the end of the file (after the 128-byte title; this means that the title must also be present and 128 bytes long if the mapper customization data is used). Anything defined in the mapper customization overrides anything that is defined by the mapper number and submapper number, although not necessarily everything is going to be overridden.
(Free Hero Mesh - FOSS puzzle game engine)
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 "Official" Specification

Post by lidnariq »

zzo38 wrote:I do have a further proposal: Assign a bit in byte 12 (TV system) for mapper customization data added at the end of the file (after the 128-byte title; this means that the title must also be present and 128 bytes long if the mapper customization data is used). Anything defined in the mapper customization overrides anything that is defined by the mapper number and submapper number, although not necessarily everything is going to be overridden.
To what end?
VEG
Posts: 53
Joined: Mon Nov 11, 2013 2:55 pm
Location: Minsk, Belarus

Re: NES 2.0 "Official" Specification

Post by VEG »

Byte 12:
7 0
---------
xxxx xxBP

P: This is a PAL ROM. When set, indicates PAL mode.
B: When set, indicates this ROM works on both PAL and NTSC machines.
Some of the Codemasters games actually will adjust the game depending
on if it detects you running on a PAL or NTSC machine - it adjusts the
timing of the game, and fixes the music.

Not many games would have this B flag set.

x: These bits are not used yet. They shall be maintained clear.
I propose to add the bit D here.

Code: Select all

Byte 12:
7       0
---------
xxxx xDBP
It would be very nice for the Dendy mode. Several emulators support this mode now and it would be nice to have an ability to tell these emulators to use this mode for some ROM's. For example, I would like to set this bit for my Unchained Nostalgia demo.

If an emulator supports the Dendy mode, it will use this flag. If it doesn't support this mode, it will use the mode depending on P flag (PAL or NTSC).
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: NES 2.0 "Official" Specification

Post by zeroone »

While we are on the topic, Nestopia's Cart DB refers to the following systems:

Dendy
Famicom
NES-NTSC
NES-PAL
NES-PAL-A
NES-PAL-B

What are those 3 different PAL types and how do they affect emulation?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 "Official" Specification

Post by lidnariq »

The different NES PAL things are different CICs only.
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: NES 2.0 "Official" Specification

Post by Myask »

VEG wrote:
Byte 12:
7 0
---------
xxxx xxBP

P: This is a PAL ROM. When set, indicates PAL mode.
B: When set, indicates this ROM works on both PAL and NTSC machines.
Some of the Codemasters games actually will adjust the game depending
on if it detects you running on a PAL or NTSC machine - it adjusts the
timing of the game, and fixes the music.
Still think that NTSC should have its own bit instead of this extensibility-poor "both" here. A Dendy bit would be fine too.
User avatar
Jarhmander
Formerly ~J-@D!~
Posts: 568
Joined: Sun Mar 12, 2006 12:36 am
Location: Rive nord de Montréal

Re: NES 2.0 "Official" Specification

Post by Jarhmander »

Myask wrote:
VEG wrote:
Byte 12:
7 0
---------
xxxx xxBP

P: This is a PAL ROM. When set, indicates PAL mode.
B: When set, indicates this ROM works on both PAL and NTSC machines.
Some of the Codemasters games actually will adjust the game depending
on if it detects you running on a PAL or NTSC machine - it adjusts the
timing of the game, and fixes the music.
Still think that NTSC should have its own bit instead of this extensibility-poor "both" here. A Dendy bit would be fine too.
Strange, I interpreted it as NTSC when it's clear.
((λ (x) (x x)) (λ (x) (x x)))
Post Reply