I completed my initial "official" spec for the new addition. This week I will start in on a few of the basic submapper things.
Code:
NES 2.0 File Addition Specification
-----------------------------------
Version 1.00
09/18/06
Written by K.Horton
Thanks to Quietust for ideas and proofing and help
----
This is the tentative addition to the standard .NES file format that
most emulators use. This addition is designed to disambiguate certain
ROMs that currently can only be discerned via a CRC-32 or similar hash
check. Naturally, this causes problems for new ROMs that are not in the
database, but need special handling.
There are four goals for this specification.
1) Retain 100% backwards compatibility with existing emulators/ROMs/etc.
(*this includes "dirty ROMs" with crap such as "diskdude!!!" in the header
and other atrocities*)
2) The format must be "future proof".
3) The changes made must be VERY CAREFULLY documented and make sense.
4) Said changes must make sense from both a hardware and software
standpoint.
* * *
The standard iNES specification is presented below:
0-3: string "NES"<EOF>
4: byte Number of 16K byte program ROM pages
5: byte Number of 8K character ROM pages (0 indicates CHR RAM)
6: bitfield flags byte 0
7: bitfield flags byte 1
8-15: byte These bytes are not used, and should be 00h.
Flags byte 0:
7 0
---------
NNNN FTBM
N: Lower 4 bits of the mapper number
F: Four screen mode. 0 = no, 1 = yes. (When set, the M bit has no effect)
T: Trainer. 0 = no trainer present, 1 = 512 byte trainer at 7000-71FFh
B: SRAM at 6000-7FFFh battery backed. 0= no, 1 = yes
M: Mirroring. 0 = horizontal, 1 = vertical.
Flags byte 1:
7 0
---------
NNNN xxPV
N: Upper 4 bits of the mapper number
P: Playchoice 10. When set, this is a PC-10 game
V: Vs. Unisystem. When set, this is a Vs. game
x: these bits are not used.
* * *
For NES 2.0, none of the above will be changing, except for the two unused
bits on flags byte 1.
To indicate that this is a NES 2.0 file, bit 2 will be clear, and bit 3 will
be set. i.e.
7 0
---------
NNNN 10PV
Same as above, but the 1 and 0 pattern will denote an NES 2.0 file. This
neatly gets around the "diskdude!!!" problem, because those headers do not
have the correct bits set on this byte, and will thus be treated as a
regular iNES file.
That is the "how" of determining whether we are dealing with a valid NES 2.0
file. Now that that is done, the desired aspects of such a thing need to
be considered. I have tested over 4000 ROMs and have dumped at least a
thousand more, and reverse engineered probably 60-70 different mappers.
This has given me a front row seat into the shortcomings of the original,
and a good idea of where additional information is needed.
* * *
The new things we need to know are thusly:
1) Vs. Unisystem
The Vs. Unisystem is one of the two Nintendo arcade machine series produced
which use "mostly NES/famicom" hardware. These games will run fine on
emulators if a little extra things are stored in the header.
Nintendo wanted to make life difficult for arcade operators when it came to
copy protection. Three main schemes were devised. (See the "Vs. system byte"
description below for a detailed analysis)
2) PRG ROM in excess of 2Mbytes, CHR ROM in excess of 1Mbyte
This has already occured, and has been causing trouble for some ROMs. So
far, the hack has been to set PRG ROM to 00h to indicate 4Mbytes of ROM
(since FFh is 16K short of 4Mbytes), and in the case of exceeding the
2Mbyte-8K CHR barrier, ROMs have been allocating the CHR in the PRG space,
and the emulator has to sort this out. Very messy.
3) "Sub-mappers"
Some of the allocated mappers are actually multiple mappers with 1 number.
Examples include mapper 34 (Nina/BNROM), mapper 83 (two styles of CHR ROM
banking), mapper 1 (various ROM/RAM hacks), mapper 16 (EEPROM/WRAM/light pen/
etc).
Currently, the only fix for this is to CRC the games and then hack the mapper
if the CRC or other hash matches. This of course fails if the game is not
in the database.
4) Mapper numbers
Face it, we're running out of mapper numbers. 16 seemed like it would be
enough, but they were quickly exhausted. Then 256 mappers seemed like a
vast space to work on. But now, we are getting near the end of the line,
and running out of mapper numbers. I have personally assigned at least 50
or 60 of them, which is almost 1/4th of the total mapper space.
5) WRAM
Not all carts that support WRAM support 8K of it. Some support less,
some support more, and some even have EEPROM! Heck, some carts even
battery backed the stupid CHR RAM. This last one was a very recent
find and goes to show that a workable extention needs to reasonably
cover all possible bases.
* * *
The proposed solution:
Byte 8:
7 0
---------
SSSS xxxM
S: Sub-mapper number.
This specifies the submapper for this ROM. If no submapper mode is
needed, set this nybble to 0000b.
M: Mapper number extension.
CAUTION: DO NOT USE THIS BIT YET. There are still some existing
numbers left in the current iNES mapper space. (Around 30-40 or so by
my last count). The other three bits marked with "x" are also slated
to be used if more than 512 mappers are required. This would allow
support for 4096 mappers all together. This should hold us until the
next iceage. I repeat: do not designate mappers above 256 yet.
--
Byte 9:
7 0
---------
CCCC PPPP
C: 4 more CHR ROM size bits
P: 4 more PRG ROM size bits
These combine with the existing 8 bits of each to form 12 bits total
for the number of PRG and CHR banks... this is enough for 64Mbytes-16K
of PRG data and 32Mbytes-8K of CHR data.
--
For the following two bytes, this table defines the size of the RAM
segments:
Each Nybble:
------------
0 - no RAM of this type is present.
1 - 128 bytes of RAM
2 - 256 bytes of RAM
3 - 512 bytes of RAM
4 - 1K of RAM
5 - 2K of RAM
6 - 4K of RAM
7 - 8K of RAM
8 - 16K of RAM
9 - 32K of RAM
10 - 64K of RAM
11 - 128K of RAM
12 - 256K of RAM
13 - 512K of RAM
14 - 1M of RAM
15 - reserved, do not use
Byte 10:
7 0
---------
pppp PPPP
p: Quantity of PRG RAM which is battery backed (or serial EEPROM, see below)
P: Quantity of PRG RAM which is NOT battery backed
--
Byte 11:
7 0
---------
cccc CCCC
c: Quantity of CHR RAM which is battery backed (yes it exists! see below)
C: Quantity of CHR RAM which is NOT battery backed
--
A note about serial EEPROMs and battery backed CHR RAM...
Some mapper 16 (Bandai) games use serial EEPROMs to store the game data,
rather than a battery backed SRAM. These can be as small as 128 bytes or
as large as 512 bytes. They tended to use 24C01 (128 bytes) 24C02 (256
bytes) or another semicustom chip I cannot find a workalike for. The
interface for the 24Cxx parts is I^2E which is a Philips specification.
The workalike chip is very similar, but the address and data are clocked
in backwards from the I^2C parts.
As for battery backed CHR RAM, the Racermate cartridge has 64K of CHR RAM
total: 32K is battery backed, and 32K of it is not. They store all the
stats and such in it. Why you would do such a thing, I do not have a
clue... but they did! I traced out the circuit myself and couldn't
believe it.
--
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.
byte 13:
7 0
---------
MMMM PPPP
This byte is reserved for the Vs. Unisystem only. If this is not a Vs.
Unisystem ROM, then this byte shall be all 0's.
P: PPU. There are 13 Vs. PPUs that can be found on the games:
0 - RP2C03B (bog standard RGB palette)
1 - RP2C03G (similar pallete to above, might have 1 changed colour)
2 - PR2C04-0001 (scrambled palette + new colours)
3 - RP2C04-0002 (same as above, different scrambling, diff new colours)
4 - RP2C04-0003 (similar to above)
5 - RP2C04-0004 (similar to above)
6 - RC2C03B (bog standard palette, seems identical to RP2C03B)
7 - RC2C03C (similar to above, but with 1 changed colour or so)
8 - RC2C05-01 (all five of these have the normal palette...
9 - RC2C05-02 (...but with different bits returned on 2002)
10 - RC2C05-03
11 - RC2C05-04
12 - RC2C05-05
13 - not defined (do not use these)
14 - not defined
15 - not defined
I have dumped the palettes from ALL of these PPUs, and have exact bit for
bit copies of them. The last 5 PPUs (RC2C05) have the standard NES
palette in them, however they return a specific word in the lower 5 bits
of 2002h, and registers 2000h and 2001h are flipped around. I'm fairly
certain that these are all the PPU's that exist. I have a good cross
section of games now.
M: Vs. mode:
0 - Normal- no special mode(s)
1 - RBI Baseball
2 - TKO Boxing
3 - Super Xevious
4 - ...
This section is a tad bare right now... I'm still trying to figure out
exactly how to flesh this out. This should be a good start, however.
If anyone is interested in the things nintendo did to make your life
difficult as an arcade operator, here it is:
a) Different PPUs. There are 13 different PPU chips made that you
can find on Vs. arcade boards.
b) Different controller pinouts. Some games came with new control panels
you had to install with the game. This was pretty basic stuff and just
remapped a few of the buttons.
c) Atari/Namco/Tengen came up with at least three different protection chips
which map in the 5000-5FFFh area that the game checks. If the chip
does not return the correct data, the game hangs or fails to start.
What about games that use $6000-7FFF but are not battery backed?
WedNESday wrote:
What about games that use $6000-7FFF but are not battery backed?
That's what the "Battery" bit is for in the header. You clear said bit. This exists in the traditional iNES header.
I really the "RAM size" bits are a bad idea. To know how to handle the RAM, you need to know the board's wiring anyway, except for the standard case of 8kB RAM at $6000. So the RAM size should be fully determined by the sub-mapper.
For instance, how would you handle contradictions between the sub-mapper and the RAM size bits? Having the same information in two different places in the file sounds like a bad idea to me. Which information source is the more trustworthy of the two?...
Bananmos wrote:
Which information source is the more trustworthy of the two?...
The one that was defined for the 2.0 version. The other just remains there for compatibility reasons. If old information contradicts new information, go with the newer one.
tokumaru wrote:
Bananmos wrote:
Which information source is the more trustworthy of the two?...
The one that was defined for the 2.0 version. The other just remains there for compatibility reasons. If old information contradicts new information, go with the newer one.
Actually,
both of those fields are new.
One argument I have in favor of indicating both is that it allows reading the RAM sizes without having to look up the mapper+submapper - if you want to, say, filter your ROMs by the amount of save RAM they use, it would be rather annoying to have to look up all of the mappers and submappers every single time (not to mention requiring the program itself to be updated every time a new mapper/submapper is allocated).
Besides, there could potentially be places where separate submappers for different RAM sizes would not be optimal - the mapper logic might not differ substantially, or there might not be room for enough submappers to distinguish every variant.
You see it as redundant and a potential for contradictions. I see it as an additional useful way of presenting information and the ability to override values (in this case, I would say that the RAM counts override the submapper, since the submapper can distinguish
far more than RAM sizes).
If nothing else, please provide a version number somewhere in the spec. That is the one thing Marat failed to include that led to all the problems we have now. An emu MUST know which revision it is looking at. What happens if some special-case cartridge comes up where the info in this revision isn't sufficient? Extendibility requires a method to know whether or not the extension should be acknowledged by the emulator. Yes, the two bits in the eighth byte are good enough (in at least most cases, which is about all you can expect anymore) to distinguish this revision from the previous one, but how do we distinguish this revision from the next one (assuming there is)? I did not see anything in the spec that would allow for this possibility.
If INES originally had a version number, we wouldn't have to search the header for DiskDuede or anything before acknowledging the eighth byte - if it was version 0, the second flags byte would have been disregarded, while version 1 would have allowed the upper four bits to be used, and version 2 the lower 2 bits (VS and PC10). An emu who only knew version 0 would give a warning ("Image may require a feature I don't know about. Proceed anyawy?") if it saw a version 1 or 2 image. Problem solved. But alas, those days cannot be relived, but at least we can try to avoid a similar problem in the future (assuming this standard goes anywhere).
One more thing. If a game has battery-backed RAM and non-battery-backed RAM, how does an emulator know which segment should be loaded first (e.g. is it bank 0 or bank 1 that gets saved)?
Banamnos looks like thinking the exact opposite as I do.
Anyway, most people seems to have adopted the submapper idea, so I don't have to do anything agains it, but I think submappers are only needed on a few rare mappers. They aren't needed on standard cards, because the SRAM size bits tells us everything.
A few improvements need to be done, because I think dvdmth is right. Also I'm sad that my region idea wasn't taken in account.
Quietust wrote:
Actually, both of those fields are new.
Oh yeah! My bad! Sorry! =)
Imagine a file format consisting of the signature, a version number, then data that's version-specific. At some point, a new version is created that completely changes the format of the data after the version. For all intents and purposes, it's a new file format. Since iNES only has 16 bytes in the header, that's about the only approach you can take with a version number.
If iNES were a block-oriented format, you could just add your new information as a new block type that would be ignored by older programs. Presumably it would only add to the information about the file. With the 16 byte header of iNES, the only way to add new information without removing the old is to define more of the unused bytes.
In other words, I'm not imagining scenarios where a version number would help.
A related idea that I can imagine uses for are some mapper+submapper combinations making use of otherwise-unused bytes. This also relates to the 4-bit fields that specify various memory sizes. I think their value might be understood by rewinding a bit in the extension of iNES. Think of taking the current iNES and adding a new sub-mapper field. You'd find that many variants were simply specifying different memory sizes, and probably end up with lots of similar-but-subtly-different code in various mappers that decodes these fields.
Rather than do this, you have dedicated memory size fields to go along with the sub-mapper bits. This makes the meaning of each more consistent, leaving the sub-mapper bits for unique features of the main mapper number. The issue of memory size being insufficient because it could be wired different ways would be handled with a sub-mapper bit, since this is truely unique information.
The issue of potential inconsistent information is an important one to consider. In this case, the mapper itself defines what additional fields are even relevant. There's no way around this, as even the most basic options like "WRAM is battery-backed" and "H/V mirroring" don't apply to some boards. So the memory sizes are meaningful only in the context of a particular mapper. I'd think that one important guideline for consistency would be to avoid using the sub-mapper field if one of the memory size fields were sufficient.
blargg wrote:
Imagine a file format consisting of the signature, a version number, then data that's version-specific. At some point, a new version is created that completely changes the format of the data after the version. For all intents and purposes, it's a new file format. Since iNES only has 16 bytes in the header, that's about the only approach you can take with a version number.
<snip>
A related idea that I can imagine uses for are some mapper+submapper combinations making use of otherwise-unused bytes. This also relates to the 4-bit fields that specify various memory sizes. I think their value might be understood by rewinding a bit in the extension of iNES. Think of taking the current iNES and adding a new sub-mapper field. You'd find that many variants were simply specifying different memory sizes, and probably end up with lots of similar-but-subtly-different code in various mappers that decodes these fields.
Rather than do this, you have dedicated memory size fields to go along with the sub-mapper bits. This makes the meaning of each more consistent, leaving the sub-mapper bits for unique features of the main mapper number. The issue of memory size being insufficient because it could be wired different ways would be handled with a sub-mapper bit, since this is truely unique information.
The issue of potential inconsistent information is an important one to consider. In this case, the mapper itself defines what additional fields are even relevant. There's no way around this, as even the most basic options like "WRAM is battery-backed" and "H/V mirroring" don't apply to some boards. So the memory sizes are meaningful only in the context of a particular mapper. I'd think that one important guideline for consistency would be to avoid using the sub-mapper field if one of the memory size fields were sufficient.
Yeah, I should've stressed that before about the submappers... they are pretty much a "last resort". MMC5 is a good example of where the WRAM sizes are very useful- there are at least 4 kinds of MMC5 WRAM setups, while the MMC5 part itself does not change. Here are a few I know of:
0K (no RAM at all)
8K (battery backed, or not battery backed)
16K (8K battery backed, 8K not battery backed)
32K (battery backed or not)
This is the ideal problem the WRAM size fields were designed to solve.
As for the sub-mapper info, as Blargg explains, it's for hardware hookup differences that you may not be able to suss out with the information given in the header, such as the afore-mentioned mapper 16 and mapper 83 stuff.
blargg wrote:
If iNES were a block-oriented format, you could just add your new information as a new block type that would be ignored by older programs. Presumably it would only add to the information about the file. With the 16 byte header of iNES, the only way to add new information without removing the old is to define more of the unused bytes.
Or to define a footer that always occurs 16 + nPRGBanks*16384 + nCHRBanks*8192 bytes into the file. Make this footer block-oriented, and you have my iNIF suggestion.
I've thrown together a Windows app to edit .NES headers with 'NES 2.0' support:
http://www.qmtpro.com/~nes/nes2edit.exe
Quietust wrote:
I've thrown together a Windows app to edit .NES headers with 'NES 2.0' support:
http://www.qmtpro.com/~nes/nes2edit.exeAnd with this, I have started implementing it in the FPGA NES. I will have some more substantial submapper setups soon. I have "large ROM" support so far added, and I ripped out and re-did my loading routines to follow the spec. Once finished, I will have a GoodNES style tool that will fix all the broken ROM headers for all current ROMs, and full documentation on the submappers and such. Stay tuned.
Oh, I really thank you for listening to other people ideas....
Bregalad wrote:
Oh, I really thank you for listening to other people ideas....
Ditto.
tokumaru wrote:
Bregalad wrote:
Oh, I really thank you for listening to other people ideas....
Ditto.
I assume both of your replies are sarcastic... as such, I went through the previous thread about it and I'm kind of at a loss as to why there's the hostility.
As for Bregalad, I am having a hard time figuring out exactly what you are complaining about. Going through the previous thread....
(from the previous thread)
Bregalad wrote:
- Why don't put a bit that tells if the cartridge is american on japanese ? Both are NTSC and there isn't much difference in emulation issues, but I guess it would still be cool to have that.
Something like 3 bits :
000 -> Japan, NTSC
001 -> America, NTSC
010 -> Europe, PAL
011 -> (Australia ?), PAL
100 -> Pirate/Homebrew/Unlicenced, NTSC
110 -> Pirate/Homebrew/Unlicenced, PAL
111 -> Pirate/Homebrew/Unlicenced, support both video standards
There are a couple reasons why I don't want to include this stuff at this time (it IS possible to add it later).
1) There are games which were released in the US and Japan (and possibly other places) with the exact same ROM data.
2) Some games (such as those made by Codemasters) only have 1 ROM, and are designed to self-detect PAL/NTSC mode, and autoswitch.
3) For many of the ROMs out there, most people cannot difinitively say where they really came from.
4) We already have a sorting system in place (albeit it's not perfect, but it does exist) as found in GoodNES.
5) We don't really know exactly what regions existed for NES games even today. This is lockout chip controlled more than anything
6) This information is not needed to run the games. The only info we really need to know is PAL/NTSC, and autodetect. Everything else is not required to run the game.
At this time, there's just not enough information about this stuff for me to feel good about it... I'm sorry that your idea didn't make it into the final draft of the spec, but I just didn't feel there was a rock solid foundation for it yet. This could very well change in the future.
As for tokumaru, I see absolutely no followups to the proposal I originally posted. Did I miss something I shouldn't have?
That's true, I didn't say anything about your proposal. In fact I think it is really good, you seem to have put a lot of work into this. What bothered me was the fact that soon Quietust put together that tool supporting your format, as if it was already some kind of "truth".
I felt that there were many opinions that didn't get the attention they deserved. I wish I could actively work on this, but since I'm not an emulator author, I'm not as familiar with the problems of iNES as other people are. I guess I can only watch how this goes now.
I appreciate your effort on posting such a complete description of a new format, really, but as soon as you did, everything that was said before was completely left aside.
I'm not really upset at anyone, I just want to see a good, backwards-compatible format being adopted. I wish there was a better involvement of the whole community, that's all.
tokumaru wrote:
I wish there was a better involvement of the whole community, that's all.
There was plenty of "community involvement" back in
this thread, but, as you can see, nothing actually came out of it until kevtris posted a detailed proposal halfway through page 5. A few concerns were voiced (most of which were not actual problems, but just desires for out-of-scope data), and the format received a few minor updates. Personally, I'm glad kevtris has decided on this format, and that's why I wrote the header editor for it - without his initiative,
nothing would have ever happened and the thread would have just died, like all of the other "new file format" discussions that have arisen in the past.
Previous 'new file format' threads all suffer from one thing - wanting
perfection and arguing over the best way to attain it. Perfection, unfortunately,
cannot be attained. We could argue (and, let's face it, we have been) for
years on how to devise the perfect file format, but we've never gotten anywhere. "NES 2.0" addresses all of the important problems with emulation - size limits, mapper limitations, ambiguity in mapper numbers (especially some Famicom ones, where one number can be up to 5 different configurations), varying RAM sizes, and special details for VS Unisystem stuff which would otherwise require checksum lookups.
Implementing a brand new file format won't work, since everybody will have to keep two copies of every ROM (so they can actually use them in the many emulators which don't support the new format), and nobody wants to do that - this is part of the reason why UNIF failed. With "NES 2.0", an older emulator could read and run it just fine using its CRC checks to get everything to work, while newer emulators updated ones can use the extended header to handle everything without having to resort to checksum-specific hacks.
It's not perfect, it doesn't have everything, but it
works - it's backwards-compatible (so users can just patch their ROMs and keep using them in most old emulators), it fixes the frequent headaches, and at least two people (kevtris and myself) are actively
implementing support for it. With a working header editor, people can actually create "NES 2.0" ROM images and simplify the process of adding support to their emulators, and soon kevtris and/or myself will be releasing a tool to patch
all ROMs in the GoodNES set (or, better yet, getting Cowering to add the functionality to GoodNES itself), removing the primary barrier to the new format's acceptance - widespread availability of ROMs, the
main factor which caused UNIF to fail (due to resistance to making mass conversion utilities, insisting that every game be redumped before it be released in the new format).
if a conversion tool is to me made, is it possible to have it platform independent, maybe coded in C? i am unable to use the good tools.
matt
I say we add a bit for game sucks/game doesn't suck...
No, but seriously, I'm completely an outsider looking in in that I don't write emulators. The only time I use the ines header is when I'm making repros I haven't made before.
It does seem to me that this format defines the technical specs well. If more is added, it becomes commentary that is somewhat useless to the ines purpose. It seems to me that that the region/pirate commentary is where it belongs when it's placed in the rom's file name.
To me the question should not be what other stuff can be crammed in here, but are there any important technical specs left out in Kevtris's proposition?
I would do things totally different if the new format weren't built for backwards compatability, but I think this specification plugs the holes while leaving a little tar to plug future holes. (can't wait till we find a board with battery backed up prg ram...)
Really thanks Kevtris, and really thanks Quintest for christening it in!
kevtris wrote:
At this time, there's just not enough information about this stuff for me to feel good about it... I'm sorry that your idea didn't make it into the final draft of the spec, but I just didn't feel there was a rock solid foundation for it yet. This could very well change in the future.
Anyone can write an iNES 2.0 spec. The people that tackle the issues and make concrete, realistic proposals and then write actual implementations of them are the ones that lead. Anyone with the skills and desire can do it; nobody has any special status here except that granted voluntarily and individually. All that's happened so far is Quietust has made an experimental program to edit the headers, and Kevtris is making
hardware that parses the format. It's the doing that ultimately gives us progress, not talking.
tokumaru wrote:
I appreciate your [Kevtris'] effort on posting such a complete description of a new format, really, but as soon as you did, everything that was said before was completely left aside.
I'd say that he filled a need with something concrete and useful enough to be acceptable. It's also based on a lot more experience (i.e. thousands of cartridges) than probably any of us has, which gives it more authority, at least in my mind. The reason the previous attempts didn't work is that people placed no limit on their proposals. There's no way to come to a consensus when people keep adding more things to the table.
sevast wrote:
(can't wait till we find a board with battery backed up prg ram...)
Given Quietust's tendency call SRAM "PRG RAM" in the wiki, that would appear to include the common games
The Legend of Zelda (U) and
Final Fantasy (U). And even in the more literal sense, where the entire program is stored in a RAM and the battery is the only thing keeping it from becoming a paperweight, that's the case in the early version of Datel's Game Action Replay accessory.
I agree with Tokumaru all the way. Kevtris has done though work and has come up with a solid definition as opposed to us wich just keep sending ideas in the air.
However, since that, while Kevtris has worked hard on testing one thousand of cartridge, his format is totally closed for any suggetion, and it doesn't seem that any external idea was even considered to be added/modified.
After all this format is at least above decent so I cannot complain, but still, I think something a bit better could have come up if more trough from more different people would be brough on it.
As for region check, effectivly, the main problem is that the number of exact regions isn't known, but for me different PAL regions isn't really much important (England and Germany regions doesn't have the same cards I think, because all England cards have a 'A' written on them (as far as I know), and all Germany ones a 'B' (that is all cards I have so far, exept import ones)).
At least, there is different between Japanese and American NTSC machines, on the controllers, on the expension sound wich is lacking in the states, and I've heard the RAW PCM is lacking to, but this info is probably wrong/corrupted because of Battletoads. Also, not all Japanese famicoms support short-looped noise mode.
And I really doubt the exact same ROM is found in Japan and America, because the copyrights that would come up on the screen are totally different. It is always written "Licenced by Nintendo" in America, but most japanese games that aren't by Ninendo most likely don't mention the big N at all in teir title or credits. The release dates are often different, and the copright is more long in the states (typically, a simple "(C) 1987 Capcom" in japan will become like "(C) 1989 Capcom USA co. LTD, Licenced by Nintendo of American Inc.".
Also, I don't like the current country system in the ROM name, because most names are annoyingly long. Almost everyone prefer have their rom named "FF3.nes" rather than "Final Fantasy III (J) - [T-Eng Dejap]" or something like that.
blargg wrote:
kevtris wrote:
At this time, there's just not enough information about this stuff for me to feel good about it... I'm sorry that your idea didn't make it into the final draft of the spec, but I just didn't feel there was a rock solid foundation for it yet. This could very well change in the future.
Anyone can write an iNES 2.0 spec. The people that tackle the issues and make concrete, realistic proposals and then write actual implementations of them are the ones that lead. Anyone with the skills and desire can do it; nobody has any special status here except that granted voluntarily and individually. All that's happened so far is Quietust has made an experimental program to edit the headers, and Kevtris is making
hardware that parses the format. It's the doing that ultimately gives us progress, not talking.
True. Talk is cheap, implementation is what really matters. Props to Kevtris and Quietust for the work, but I am sure they already know they are awesome in that regard.
I've put together an alternative to the unstructure discussion threads and added items for most of the points I found as I re-read this thread and the previous:
http://nesdevwiki.ath.cx/index.php/Talk:INES
"Put your money where your mouth is" and flesh out/add more issues to the page. We can reply to each issue and eventually come to a more shared understanding of them. Just don't ramble on, since that kills productivity. Sheesh, I'm sounding like upper management now!
Bregalad wrote:
As for region check, effectivly, the main problem is that the number of exact regions isn't known, but for me different PAL regions isn't really much important (England and Germany regions doesn't have the same cards I think, because all England cards have a 'A' written on them (as far as I know), and all Germany ones a 'B' (that is all cards I have so far, exept import ones)).
The only difference between regions which actually affects emulation is timing - 60fps (NTSC) and 50fps (PAL). Special cases like France (SECAM) and Brazil (PAL-60) don't really affect emulation, just possibly the palette (and even there, the difference would be very slight).
Bregalad wrote:
At least, there is different between Japanese and American NTSC machines, on the controllers, on the expension sound wich is lacking in the states, and I've heard the RAW PCM is lacking to, but this info is probably wrong/corrupted because of Battletoads. Also, not all Japanese famicoms support short-looped noise mode.
These differences are irrelevant, since they only affect
some machines within the region, and using such a machine would affect
all games played on it. This sort of thing would only make sense as a user-configurable option in the emulator (and, even then, it doesn't make much sense to begin with). RAW PCM is fully supported on the Famicom, and only the oldest of the oldest units would lack looped noise.
Bregalad wrote:
And I really doubt the exact same ROM is found in Japan and America, because the copyrights that would come up on the screen are totally different. It is always written "Licenced by Nintendo" in America, but most japanese games that aren't by Ninendo most likely don't mention the big N at all in teir title or credits. The release dates are often different, and the copright is more long in the states (typically, a simple "(C) 1987 Capcom" in japan will become like "(C) 1989 Capcom USA co. LTD, Licenced by Nintendo of American Inc.".
There are plenty of counterexamples to this - with Super Mario Bros, Excitebike, Duck Hunt, Gyromite, Stack-Up, and plenty of other games, the ROM on the USA cartridge is 100% identical to the corresponding Famicom game.
Bregalad wrote:
Also, I don't like the current country system in the ROM name, because most names are annoyingly long. Almost everyone prefer have their rom named "FF3.nes" rather than "Final Fantasy III (J) - [T-Eng Dejap]" or something like that.
If it's
really desired, it can be tacked on in "NES 3.0" in a backwards-compatible way, but for now, it's not really needed. Besides, the "current country system" is dictated
only by ROM auditing tools (i.e. GoodNES), so either complain to Cowering about it or just tell it to not rename your ROMs.
Bregalad wrote:
However, since that, while Kevtris has worked hard on testing one thousand of cartridge, his format is totally closed for any suggetion, and it doesn't seem that any external idea was even considered to be added/modified.
But it has everything needed for proper emulation. Except for like with Squeedo and the PIC's CPU code, but that's to be expected (I guess an emulator could load it seperately, if anyone ever emulates it).
The 16-byte header is pretty cramped anyways, there's over 500 bytes of room for the future with the using the trainer for info idea I mentioned in the other thread. Since it'll inherit NES 2.0's extensions for good emulation, all that extra space could be used for the nice-to-have-but-not-absolutely-necessary things.
I'd still like a comment from kev on how external ROM data would be stored, such as PIC code in Squeedo, or the ROM stored in the speech chip in some Jaleco Famicom games. (if anyone will ever make the effort of manually extracting the ROM like in the CIC chip's case, rather than just record the samples)
I see three alternatives:
1) The data is stored among the PRG bank, as the last bank(s). Code in an emulator/FPGA console front-end/file processing tool supporting the mapper knows how many of the PRG banks belong to the external ROM, and will handle this properly. Code not supporting the mapper will just see an odd PRG size.
2) As above, but the data is stored among the CHR banks.
3) The data is stored after the PRG and CHR banks, where the file would normally have ended. As in the abovementioned cases, code that recognizes the mapper will handle this properly.
Any of this alternatives would do, but I'd like some thoughts on which of these would be the best one.
Do you plan to support any of the Jaleco games with external sample ROM on your FPGA console, btw?
Bananmos wrote:
I'd still like a comment from kev on how external ROM data would be stored, such as PIC code in Squeedo, or the ROM stored in the speech chip in some Jaleco Famicom games. (if anyone will ever make the effort of manually extracting the ROM like in the CIC chip's case, rather than just record the samples)
I see three alternatives:
1) The data is stored among the PRG bank, as the last bank(s). Code in an emulator/FPGA console front-end/file processing tool supporting the mapper knows how many of the PRG banks belong to the external ROM, and will handle this properly. Code not supporting the mapper will just see an odd PRG size.
2) As above, but the data is stored among the CHR banks.
3) The data is stored after the PRG and CHR banks, where the file would normally have ended. As in the abovementioned cases, code that recognizes the mapper will handle this properly.
Any of this alternatives would do, but I'd like some thoughts on which of these would be the best one.
Do you plan to support any of the Jaleco games with external sample ROM on your FPGA console, btw?
#3 would probably work best - Playchoice-10 ROMs already do exactly this, dropping the Z80 code immediately after the CHR ROM data. In the unlikely (hell, impossible) event that a PC10 ROM have additional non-PC10 data appended, it would, of course, have to come after the PC10 data.
As for the Jaleco sound sample chip, there's 2 ways of getting accurate data: 1. decap the chip and read the ROM (quite difficult), or 2. put together a device to manually clock the chip, record what's on the audio output pin after each clock (could be done by kevtris's 3-in-1 tester with some modifications), and then convert that waveform back to what the chip is supposed to store internally. To my knowledge, neither has been done - all we have is a ~44kHz WAV file of all 16 samples for the Baseball game.
Memblers wrote:
The 16-byte header is pretty cramped anyways, there's over 500 bytes of room for the future with the using the trainer for info idea I mentioned in the other thread.
I read up on the trainer and apparently it's located at $7000-$71FF, so using it for extra space wouldn't be a good idea since it would affect the game on pre-iNES 2.0 emulators. On the other hand, maybe most emulators ignore it.
It's not the emulator that ignores it but the game that ignores it. Except for Low G Man, which relies on open bus in $4018-$7FFF, most games seem to be able to tolerate an 8 KiB PRG RAM at $6000 loaded with arbitrary data loaded into $7000-$71FF, as long as the trainer doesn't overwrite the existing content of the battery-backed RAM. The game's checksum routines will just see it as invalid data and destroy it.
Quietust wrote:
[...] all we have is a ~44kHz WAV file of all 16 samples for the Baseball game.
All games known to use samples have been recorded.
related thread:
http://nesdev.com/bbs/viewtopic.php?t=762
the samples:
http://home.planet.nl/~haps/crap/famicomsamples.html
Just an update:
I've been hard at work on the NES 2.0 headers the last 2 or 3 days. So far, I have processed around 1400 ROMs out of 3200. Out of those 1400, only 17 have NES 2.0 headers. I did fix *a ton* of bad headers though. I've fixed probably 70 or 80 bad headers! Mirroring being wrong topped the list of problems, followed by a few incorrect mapper assignments which caused scrambled CHR or crashes later on in the game.
I am concentrating on the discrete mappers so far, and got most of them done, so I am now getting into the harder stuff such as MMC3 and MMC5.
I hope to have something to show for the effort in a week or less. Tomorrow I'm moving to my new house, and the internet is SUPPOSED to be turned on there (hehe) so the transition should be pretty smooth. I may disappear for a bit however if the internet doesn't work for some reason.
hap wrote:
Quietust wrote:
[...] all we have is a ~44kHz WAV file of all 16 samples for the Baseball game.
All games known to use samples have been recorded.
related thread:
http://nesdev.com/bbs/viewtopic.php?t=762the samples:
http://home.planet.nl/~haps/crap/famicomsamples.htmlmoepro90.zip is making the mistake.
Please replace "11.wav" and "12.wav."
"11.wav" - > "pitcher koutai(new pitcher)"
"12.wav" -> "daida(pinch-hit)"
Is FAMILY KID Mapper134?
It works well by Mapper4.
If it has the information on this Mapper, please let me know.
This cart is made in Thailand.
NES mapper assignment table:
http://nestopia.netfast.org
Pongba wrote:
Is FAMILY KID Mapper134?
It works well by Mapper4.
If it has the information on this Mapper, please let me know.
This cart is made in Thailand.
NES mapper assignment table:
http://nestopia.netfast.orgYes, it is mapper 134. There's actually TWO games on the cart, but it is wired to only allow you to play one! I guess they figured the other game was buggy or something? I dunno. If you dump it as MMC3, it will play the one game. If dumped as mapper 134, and a dipswitch is set, it will show a menu and let you select 1 of 2 games. (Incidentally, this is a good example of a "metamapper"- a mapper that works "on top of" an MMC3. This metamapper controls the upper address lines from the MMC3 and to the ROM, so it can restrict how much ROM the MMC3 "sees", and thus you can put multiple games on one cart of varying sizes without wasting space.)
kevtris wrote:
Yes, it is mapper 134. There's actually TWO games on the cart, but it is wired to only allow you to play one! I guess they figured the other game was buggy or something? I dunno. If you dump it as MMC3, it will play the one game. If dumped as mapper 134, and a dipswitch is set, it will show a menu and let you select 1 of 2 games. (Incidentally, this is a good example of a "metamapper"- a mapper that works "on top of" an MMC3. This metamapper controls the upper address lines from the MMC3 and to the ROM, so it can restrict how much ROM the MMC3 "sees", and thus you can put multiple games on one cart of varying sizes without wasting space.)
Thank you very much
Are dipswitch which you say four jumpers on PCB?
The way of Dump is not known. It and Emulator which supports mapper 134 do not exist.
By the way, this Cart is strange.
If this Cart is used by Original Famicom, only FAMILY KID will work.
However, if this Cart is used by TwinFamicom (Sharp), "2-in-1menu" will display ???
Also when it Dump by Mapper4, "2-in-1 menu" displays.
*Bump*
Any news/comments?
85cocoa wrote:
*Bump*
Any news/comments?
Yes, I completed most of the work. But it looks like another goodNES was released recently that fixes headers. grrrr
I dunno if I want to go thru and fix everything AGAIN. Hopefully it won't be too hard to integrate and track changes between them.
Tonight, I dumped all the EPROMs from my Vs boards and I netted around 17 Vs ROMs from that. The NES 2.0 Vs. byte is working very nicely for this. I have them all set up now and I'm hammering out the changes and stuff on my FPGA to match.
I don't have much to show off just yet but I am still working on it.
Quote:
But it looks like another goodNES was released recently that fixes headers. I dunno if I want to go thru and fix everything AGAIN. Hopefully it won't be too hard to integrate and track changes between them.
Run program which saves headers from all your .nes files. Run GoodNES on all your .nes files. Run program to save
these modified headers. Compare saved headers from both. I take it GoodNES does not allow access to its database of "correct" headers? Also, why does a new release of GoodNES matter at all with regard to your corrections that use the proposed iNES 2.0 extensions?
blargg wrote:
Why does a new release of GoodNES matter at all with regard to your corrections that use the proposed iNES 2.0 extensions?
Because then everybody will be using GoodNES to get
incorrectly "fixed" headers (and
removing any NES 2.0 data), making it significantly more difficult for NES 2.0 to gain a foothold unless kevtris manages to get the functionality built into the next GoodNES release.
A thing that might be cool to see inbedded in a new header format, would be a small game-banner, just like the NintendoDS/GameCube games has.
An icon that could be a part of the boxart, the game logo/whatever. Might perhaps be cool in emulators, to present the game with it's banner instead of the filename (or in combination).
oRBIT2002 wrote:
A thing that might be cool to see inbedded in a new header format, would be a small game-banner, just like the NintendoDS/GameCube games has.
An icon that could be a part of the boxart, the game logo/whatever. Might perhaps be cool in emulators, to present the game with it's banner instead of the filename (or in combination).
even better would be boxart and manual embeded
That's UNIF. With UNIF you can put all kinds of crap with the ROM. But the deal with iNES 2.0 is compatibility with the previous iNES format, not the "perfect" header/format.
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
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.
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...
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.
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=9221And 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)?
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.)
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).
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.
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?
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.
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.
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.
3gengames wrote:
Who cares about the iNES 1 ROMS?
We all do when they contain incomplete board/submapper information.
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.
http://wiki.nesdev.com/w/index.php/NES_2.0Under 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
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.
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).
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?
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)
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.
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.
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.
I thought 00 + garbage in bytes 12-15 also meant corrupted, except that the corruption starts with one of the letters ABCPQRS.
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.
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?
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).
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?
The different NES PAL things are different CICs only.
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.
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.
My interpretation (with the proposed Dendy flag):
Code:
Byte 12:
7 0
---------
xxxx xDBP
0000 0000 - NTSC only
0000 0001 - PAL only
0000 0010 - Supports NTSC and PAL, but NTSC is preferred
0000 0011 - Supports NTSC and PAL, but PAL is preferred
0000 0100 - Dendy only, but if Dendy mode isn't available in the emulator, use NTSC
0000 0101 - Dendy only, but if Dendy mode isn't available in the emulator, use PAL
0000 0110 - Supports Dendy, NTSC and PAL. Dendy mode is preferred, but if Dendy mode isn't available in the emulator, it will use NTSC
0000 0111 - Supports Dendy, NTSC and PAL. Dendy mode is preferred, but if Dendy mode isn't available in the emulator, it will use PAL
It's simple and almost all cases are covered. The only drawback that I can see is that we can't indicate that the ROM supports, for example, Dendy and NTSC modes only. But I don't know why it may be needed.
IMHO, the bit B is not a very useful flag. I doubt if it is used by any emulator.
Myask wrote:
Still think that NTSC should have its own bit instead of this extensibility-poor "both" here. A Dendy bit would be fine too.
The idea to have some kind of mask of which systems are supported in this ROM is nice. So, it will be bits N for NTSC, P for PAL, and D for Dendy. As the result we will be able to set only P and D, or N and D, or N and P, or all of them. Also we have to have a way to tell the emulator which mode is preferred. For example, Unchained Nostalgia supports PAL, NTSC and Dendy, but Dendy mode is preferred, and if it is not supported, NTSC mode is preferred.
We have to take into account how B and P bits are treated by modern emulators. As far as I understand, they use NTSC when bit P is clear, and PAL when bit P is set. Am I right? How modern emulators treat the B bit? If they ignore this bit, maybe it is possible to change the meaning of this bit.
NSF spec:
Quote:
$07A 1 BYTE PAL/NTSC bits
bit 0: if clear, this is an NTSC tune
bit 0: if set, this is a PAL tune
bit 1: if set, this is a dual PAL/NTSC tune
bits 2-7: not used. they *must* be 0
NSFe spec:
Quote:
$0006 1 BYTE PAL/NTSC bits
bit 0: if clear, this is an NTSC tune
bit 0: if set, this is a PAL tune
bit 1: if set, this is a dual PAL/NTSC tune
bits 2-7: not used. they *must* be 0
So, this byte is similar everywhere and new extension will be applicable to these formats also =)
NSFe has an additional regn section for Dendy support now:
https://wiki.nesdev.com/w/index.php/NSFe#regnBut I believe that we could extend the byte which describes which systems are supported and preferred in the NES, NSF and NSFe. Everywhere in the same way.
My old proposition (with the Dendy flag):
Code:
Byte 12:
7 0
---------
xxxx xDBP
0000 0000 - NTSC only
0000 0001 - PAL only
0000 0010 - Supports NTSC and PAL, but NTSC is preferred
0000 0011 - Supports NTSC and PAL, but PAL is preferred
0000 0100 - Dendy only, but if Dendy mode isn't available in the emulator, use NTSC
0000 0101 - Dendy only, but if Dendy mode isn't available in the emulator, use PAL
0000 0110 - Supports Dendy, NTSC and PAL. Dendy mode is preferred, but if Dendy mode isn't available in the emulator, it will use NTSC
0000 0111 - Supports Dendy, NTSC and PAL. Dendy mode is preferred, but if Dendy mode isn't available in the emulator, it will use PAL
It's simple and almost all cases are covered. But still, it has a drawback: you can't state that a ROM supports Dendy and NTSC only, and can't choose a preferred system separately from the list of supported systems.
So, I have an improved proposition. Let's divide the byte into two nibbles. One part describes which systems are supported, the other one describes which system is preferred.
Code:
Byte 12:
7 0
---------
xdpn xxBP
If higher nibble is 0, use legacy interpretation:
0000 0000 - NTSC only
0000 0001 - PAL only
0000 0010 - Supports NTSC and PAL, but NTSC is preferred
0000 0011 - Supports NTSC and PAL, but PAL is preferred
Otherwise, higher nibble describes supported systems:
d - Dendy
p - PAL
n - NTSC
Lower nibble (bits BP) describes preferred system:
00 - NTSC (a legacy emulator will use NTSC)
01 - PAL (a legacy emulator will use PAL)
10 - Dendy (a legacy emulator will use NTSC, and it is good, because Dendy is closer to NTSC)
If the lower nibble chooses the system which is not marked as a supported system in the higher nibble, fallback to the legacy behavior. Bits 2,3 and 7 should be ignored by emulators, and should be 0 in ROMs.
It seems, that the latter proposition has no drawbacks. It should work perfectly in legacy and in new emulators which support the new NES specification.
Let's extend meaning of this byte in the NES, NSF and NSFe formats! A lot of emulators support Dendy, but this mode can't be utilized in convenient way for ROMs which were designed for Dendy. We really need this extension.
Also I'm curious, why NES 2.0 devotes byte 12 for the TV System while the original iNES 1.0 devotes byte 9 for the same purpose?
