It is currently Tue Dec 12, 2017 7:15 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
PostPosted: Tue Jan 22, 2013 9:10 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6509
Location: Seattle
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.

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

Quote:
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.

Quote:
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.


Top
 Profile  
 
PostPosted: Wed Jan 23, 2013 7:27 am 
Offline

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

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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).


Top
 Profile  
 
PostPosted: Wed Jan 23, 2013 9:42 am 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
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?

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Wed Jan 23, 2013 10:03 am 
Offline

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

Quote:
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.

Quote:
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.

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


Top
 Profile  
 
PostPosted: Wed Jan 23, 2013 12:32 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6509
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Fri Jan 25, 2013 2:31 am 
Offline
User avatar

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

_________________
.


Top
 Profile  
 
PostPosted: Fri Jan 25, 2013 10:53 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
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.


Top
 Profile  
 
PostPosted: Fri Jan 25, 2013 2:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19334
Location: NE Indiana, USA (NTSC)
I thought 00 + garbage in bytes 12-15 also meant corrupted, except that the corruption starts with one of the letters ABCPQRS.


Top
 Profile  
 
PostPosted: Fri Jan 25, 2013 8:42 pm 
Offline
User avatar

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

_________________
.


Top
 Profile  
 
PostPosted: Fri Jan 25, 2013 10:15 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6509
Location: Seattle
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?


Top
 Profile  
 
PostPosted: Sun Oct 09, 2016 12:51 pm 
Offline

Joined: Mon Nov 11, 2013 2:55 pm
Posts: 22
Location: Minsk, Belarus
Quote:
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:
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).


Top
 Profile  
 
PostPosted: Sun Oct 09, 2016 2:22 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 750
Location: New York, NY
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?


Top
 Profile  
 
PostPosted: Sun Oct 09, 2016 2:23 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6509
Location: Seattle
The different NES PAL things are different CICs only.


Top
 Profile  
 
PostPosted: Sun Oct 09, 2016 9:27 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
VEG wrote:
Quote:
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.


Top
 Profile  
 
PostPosted: Sun Oct 09, 2016 9:47 pm 
Offline
Formerly ~J-@D!~
User avatar

Joined: Sun Mar 12, 2006 12:36 am
Posts: 445
Location: Rive nord de Montréal
Myask wrote:
VEG wrote:
Quote:
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.


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: MLX and 6 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