nesdev.com

if its only once then a convert utility would probably work better anyway. and use a script or util to change many roms in a folder.

matt

This just makes the value a bit more difficult to read. If a person is too lazy to to form a byte out of 2 nibbles this does not justify a new file format.


A second identifier can prevent this. If this ID is not present (wich would be the case if crap was written in those 8 bytes), the emulator should just consider this an old format iNES file, and ignore those 8 bytes, just as it is today.


It makes no sense to come up with a format that is so similar to iNES. The point here is not that iNES is good. The only reason we're trying to expand iNES (as opposed to comming up with something new) is compatibility. If we were to come up with something new (and kill compatibility altogether), I'm sure it could be better than iNES or the format you proposed.


Again, laziness from the part of the programmer does not justify a new format.

Bregalad, your summary is a good idea. Helps get people on the same page of the debate.


I do agree that a .nes file is not just a ROM, rather a virtual NES cartridge. This isn't a technical reason for having SRAM inside the file, more a common-sense reason.


What if a person wants to keep all umpteen-thousand games on a CD-ROM and their save states on the hard drive? Or keep the game files on a directory for which they have read-only access, in order to prevent rogue programs from wiping out their game collection? Or they want to avoid having their backup program re-copy entire game files every time they play, rather than just the smaller save state file?


That ends the debate about save states in game files in my mind: due to this reason alone, it is just not viable.


All I see is a mere rearrangement of bytes, with even less room for expandability. What the heck is the gain over iNES?


Would a Wii in November do?

Exactly. It's like he just doesn't like to mess with nibbles. Even though this is a thing that the emulator author has to do only once...


I don't need a revolution, nor a Wii. Or a PS3. Or an XBOX 360. The PS2 I have at home is already too much. 3D sucks (words from a guy who is trying to make a "3D" raycaster for the NES! O.o).

Wii sucks. Honestly, I enjoy the NES. ^_^;;..

About the "new" format, well...
The iNES seems deprecated because of arcaic times of emulation, do you remember? Yes, lots of "l33t" offering iNES ROM images and "signing them" right in the header. The most (un)famous is DiskDude junk that makes a lot of ROMs to fail when loaded in an emulator.

Now, you CANNOT suggest an "updated" iNES thing by cruching it. Plus, any format must need free space to be expanded somewhat. You should discuss what information is REALLY required to get the game EMULATED or RUNNING into a NES. This is the point, which UNIF seems to choose the 2nd option...

_________________
Zepper
RockNES developer

If emulator finds 16th byte of iNES header is non-zero, clear 8th through 16th bytes to zero before parsing. Problem solved?

You mean 15th byte, right ?
Anyway, the current iNES specification DOES SAY all bytes 8-15 must be zeros. All ROMs having something in there aren't valid iNES ROMs, so they won't be valid on a updated iNES either.
However, a converting/fixing tool like good NES could fix all the ROMs with junk in their header. However, this shouldn't have anything to do with the FORMAT itself.

EDIT : About recent console, I don't need any PS3/XBC360/Wii either. 3D sucks, except if it is really well done. The only 3D graphics I ever loved are in Final Fantasy X. (Dragon Quest VIII is also have fair landscapes and characters, but it still hurt eyes a bit).
And I'm against 3D in the NES more than anything else. However, I'm very pro 2D (or 3D isometric) recent games, even if there is REALLY a few titles here.

_________________
Life is complex: it has both real and imaginary components.

Byte 15 is the 16th one, because 0 is the 1st. I think that blargg meant "clear 9th through 16th bytes" though, since the 8th byte is byte 7 and it is used by iNES.

Firstly, then information is better provided and easier to read. I know that someone has said that programmer laziness is no need for a new header, I disagree. I do agree that no extra information is needed other than to run the ROM (i.e. checksums, ROM name etc). As for there being no room for expansion, iNES has never needed those eight extra bytes, and they were just abused. With the given format, what more could we possibly need?



As far as the mapper/board number goes, can we stop talking about why this format will be no good and actually start brainstorming. We will stick with the mapper numbers or move on to boards instead?

_________________
http://www.jamesturner.de/

0..255 is not enough to some multigame carts with maximum capacity... Anyway, mostly maximum number is 256, so at least it needs to hold hi bit of each PRG and CHR banks number along with common flags or something... But easier way is to assign 2byte values to bank numbers...

Mirroring is better to represent with two bits:

00 - one-page mirroring
01 - Vertical mirroring
10 - Horizontal mirroring
11 - Four screen mirroring...

But actually there is hardware mapper mirroring so all this bits is unnecessary... So probably there is need one another bit, if it 1, then hardware used and first two ignored, else selected as above...



One more thin you should do before brainstorming. Rearraging mappers information... It needs collecting all mappers info such banking registers, irq handlers, mirrorings and memory ranges... Then you will probably find out that many mappers is duplicated or just have smal difference between each others, but many mappers contain two or three emulated hardware board in one... First should be merged, other ones should be splitted. I'm trying to do something, but anyway I've made many dupes for mappers and boards.

I don't think more mirroring bits than iNES are needed. There is no problem with mirroring support now. The only mappers that use one-screen mirroring are mapper-controlled, there is NEVER hardwired one-screen mirroring, because the fact that you couldn't switch between both nametable banks for all 4 nametables mapped in PPU would loose all the interest of this mirroring mode.
The H/V mirroring bit is only here for harwired mirroring mappers, and ignored for all other mappers. The four-screen bit is here for several MMC3 games that use 4-screen mirroring. I don't think there is more than a couple of game, tough.

Again, the structure of iNES WON'T BE CHANGED for reasons that already have been mentionned : Noone (from "Joe Gamer" to myself) will care about any new format. Only a update of iNES would be of any pratical use. It is a simple of this.

_________________
Life is complex: it has both real and imaginary components.

I was waiting awhile before I brought this up, but I had an idea for a slightly modified .NES header format myself.

I have gone through over 4000 ROMs, doing various testing on my FPGA NES console now, and I believe I'm in a fairly good position to recommend some changes.

The goals of my changes are thus:

1) retain absolute backwards compatibility (for existing ROMs)

2) this format must be "future proof"

3) the changes I make must be carefully documented and must make sense.

4) The changes must make "sense" from both a hardware and software standpoint.

This thread has kind of made me post my ideas early before I've had a chance to fully revise and pull together exactly what I want to do, but you should be able to get a good idea for what I wanted to do.

So, without further ado...

As mentioned before, the format will be retained as it is. For a recap, here is the existing format:

byte 0-3: 'NES<eof>'
byte 4: # of PRG pages
byte 5: # of CHR pages
byte 6: flags byte 0
byte 7: flags byte 1
byte 8-15: not used

There are two free bits on flags byte 1.

I propose the following:

D3 set and D2 clear of flags byte 1 will indicate that this is an extended header. DiskDude! in the header will have D2 set and D3 clear, so this will prevent interference with those old dirty ROMs. (thanks to Q for this suggestion)

If D3/D2 are not set and clear respectively, this is not a "Version 2" header. This should be a pretty definitive way to prevent confusion. Again, if the emulator does not support the extended header, the game loads like normal and the emulator is none the wiser.

Now that we know this is an extended ROM, the following things were concidered as problem areas for .NES

1) Vs. Unisystem.

The Vs. Unisystem has no less than 11 different PPUs and various protection schemes on some of the Namco/Atari games (such as RBI baseball). Some way has to be found to accomodate this.

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. The only way to sort this mess is to use CRC checks in the emulator. This of course is messy, since when a new ROM comes along that isn't in the CRC table, things break.

4) mapper numbers.

Face it, we're running out of mapper numbers. 256 was alot at the start (heck, 16 even was alot to begin with!) but we're filling the space up.

5) WRAM.

Not all carts that support WRAM support 8K of it. Some support less, some support more, and some even have EEPROM!

So, after testing nearly every ROM in goodNES, those are the trouble areas I have found.

The proposed solution is thus:



Well, that in a nutshell is my proposal. It has been extensively thought out, future proofed, and carefully designed to fit in with existing emulators and ROMs. In fact, these additions would probably only affect around 5% of the existing ROMs, but they would banish CRC and mapper hacks forever.

I propose making a "fixup" program for existing ROMs which need it, and CAREFULLY documenting all the updates needed in 1 central location so that the existing mapper issues cannot occur again.

Also on the mappers issue, I have made an absolutely comprehensive mapper guide vs. mapper number which I will be posting to my page at some point. It lists every single implemented mapper number, where it can be found, and what it is composed of. Everything on it has been tested and revised, since it was produced when I made the FPGA NES.

And as such, the extra mapper bits should NOT be used until we run out of existing mapper numbers to prevent confusion and needless trouble.

_________________
/* this is a comment */

Here's my Vs. byte proposal. I still need to figure out what to do about the dual Vs. games such as Baseball... I will probably allocate a bit or two on the flags byte for those... anyways, here is what I have.



(thanks Q for the corrections/additions)

_________________
/* this is a comment */

Wow ! Your new format looks pretty decent.
However, I've some minor problems with it :

- What on earth are those PPU types ? I've never heard of that. Normally, a NES game should work with all PPU revisions, huh ?

- Why CHR-RAM could be battery backed ? I don't see much interest with that. What game could have any use of this ? To save space, a game would write all its save to the CHRRAM ? That make no sense to me, while technically possible.

- Why CHR-RAM/SRAM size could be less than 8kb (exept 0kb) ? I doubt any 128-byte RAM chips are used in any NES game. I think less bits would do for the RAM size.

- More info on what exactly "submappers" would look like would be welcome.

- 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

Emulators could just look the middle bit to know if they must emulate PAL or NTSC, or have a more complex system to emulate all regions... ?

Other than this, it looks great.

EDIT : Totally outtopic, but I'm very curious to know wich games use EEPROM instead of RAM+Battery to hold saves. Wich mapper support that ? Are those licenced games or only pirate games ?

_________________
Life is complex: it has both real and imaginary components.

Excellent proposal. If everyone else agrees and once all the details are in place, I'd like to get started right away.


Probably, but there might differences we don't know yet. Besides, knowing the PPU type is a must if we want to display the VS games in correct colors.


Then what about the Bandai mapper 16/157 EEPROMS? Mapper 16 may have a 24C01 (128x8 bits) or a 24C02 (256x8 bits). Mapper 157 (Datach Joint System) may have both a 24C01 and a 24C02 (384x8 bits). MMC6 has 1k RAM only and some unlicensed carts may also have less than 8k.


A few examples on how it could be laid out:

mapper 4 sub-mappers: MMC3A, MMC3B, MMC3C, MMC6, MIMIC-1, NAMCOT 108/109/119
mapper 33 sub-mappers: TC0190, TC0350
mapper 69 sub-mappers: FME-7, SUNSOFT5A, SUNSOFT5B