Having seen the various limitations of the iNES format, but not wishing to introduce a new format like UNIF that does not have the full support of the emulation community, I propose a hybrid format. It uses the 16 byte iNES header with only the control bytes 6 and 7 changed. Byte 6 is devoted solely to the memory controller hardware, essentially what the game uses. In some cases, that and the PRG and CHR bytes are all the programmer needs to emulate the game correctly. Note all games with no CHR rom have 8KB of CHR RAM unless the mapper dictates otherwise. In other cases, byte 7 can be used to determine a submapping system. Also, in my system, the mapper numbers make sense, observe:
00 - NROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
01 - Nintendo MMC1 (note 512KB of PRG ROM is SUROM)
0 - SLROM or SGROM (No Save RAM)
1 - SKROM or SNROM (8KB Save RAM)
2 - SJROM (8KB Work RAM)
3 - SOROM (8KB Save RAM + 8KB Work RAM)
4 - NES EVENT (Nintendo World Championships)
02 - Nintendo MMC2 (PNROM)
03 - Nintendo MMC3
0 - TLROM or TGROM (No Save RAM)
1 - TKROM or TNROM (8KB Save RAM)
2 - TSROM (8KB Work RAM)
3 - TQROM (8KB CHR-RAM + CHR-ROM)
4 - TVROM (4-Screen Mirroring)
5 - TLSROM
6 - NES-QJ ('161 submapper)
7 - Super Mario Bros. + Tetris + Nintendo World Cup mapper
04 - reserved*
05 - Nintendo MMC5
0 - ELROM (No Save RAM)
1 - EKROM (8KB Save RAM)
2 - ETROM (8KB Save RAM + 8KB Work RAM)
3 - EWROM (32KB Save RAM)
06 - Nintendo MMC6 (HKROM)
07 - AOROM
08 - BNROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
09 - CNROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
0A - CPROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
0B - GNROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
0C - UOROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
0D - Tengen RAMBO-1
0E - AVE Nina-001 (Impossible Mission II)
0 - Horizontal Mirroring
1 - Vertical Mirroring
0F - AVE Nina-06
0 - Horizontal Mirroring
1 - Vertical Mirroring
10 - Maxi-15
11 - Codemasters/Camerica BF9096 (Quattro)
0 - Horizontal Mirroring
1 - Vertical Mirroring
12 - Codemasters/Camerica BF9097 (Firehawk)
13 - Color Dreams/Wisdom Tree
0 - Horizontal Mirroring
1 - Vertical Mirroring
14 - Active Enterprises
15 - Caltron/Myriad 6-in-1
FE - Tengen 80042 (Afterburner)*
FF - JSROM* (Batman: Return of the Joker)*
Now, this system may be more properly be called iNES limited, as its sole purpose is to emulate released NES games. It has some flexibility and there is room for expansion. It only emulates what needs to be emulated. Why should mirroring be set on MMC carts when the MMC sets the mirroring? Why should W-RAM be emulated when it isn't present? Why should board hacks be emulated with another mapper instead of with a modification to the current mapper? Its not like the functionality is drastically changed. It alo ensures that emulators do not have to keep databases for games that require special hacks or the like. It also eliminates the superflous trainer bit in iNES. It also eliminates the split byte method of signifying a mapper. Importantly, it keeps both the 16-byte header, which is easy to deal with. It also keeps roms to their full size regardless of how empty the pages are.
This system makes very little provision for Famicom games. It is designed to emulate NES games, about which much is known. It does not delve into the murky world of Japanese Famicom games. However, there is room for expansion, as mapper $04 is reserved for what would be the Nintendo MMC4 in a comprehensive Famicom mapping system. Also, the last two mappers refer to Namco and Sunsoft hardware and would be better off placed in a proper squence. With these mappers you can emulate any commercial NES game in existence. An emulator can advertise that it fully supports each mapper to be considered complete.
Edit: Main Mappers should be in bold.
I like this idea. iNES seems to work well enough, except for its redundant/lacking mapper descriptions, which this addresses nicely. Would the $1A at the beginning also be updated?
On the subject of rom formats, I always thought it would be a nice feature to keep battery-backed RAM within the rom file itself, so you don't have to copy .sav's from one emulator's folder to another. Am I the only one who would like this?
Great Hierophant wrote:
00 - NROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
[...]
09 - CNROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
Is this really necessary? Isn't an NROM just a CNROM with 8 KB of PRG?
Quote:
05 - Nintendo MMC5
0 - ELROM (No Save RAM)
1 - EKROM (8KB Save RAM)
2 - ETROM (8KB Save RAM + 8KB Work RAM)
3 - EWROM (32KB Save RAM)
That doesn't stand for "External Work ROM", does it? Or have I been playing around on gbadev.org too much?
Quote:
Why should mirroring be set on MMC carts when the MMC sets the mirroring?
Because some boards have solder pads for H, V, or mapper controlled.
[quote]Is this really necessary? Isn't an NROM just a CNROM with 8 KB of PRG? [/quote]
Correct, it wouldn't affect emulation at all. An NROM board could use BNROM, CNROM, GNROM or UOROM and still work properly. I keep it separate here because I don't want to rock the ship too much.
[quote]
Because some boards have solder pads for H, V, or mapper controlled.[/quote]
As far as I know, with MMC carts, the only boards with solder pads for mirroring selection are TEROM and TFROM. If one of the nine games that use these boards has solder on the H or V pad, then I wil include it. Otherwise, there is no need for it.
By the way, the default mirroring on the NES is horizontal, isn't it?
abonetochew wrote:
On the subject of rom formats, I always thought it would be a nice feature to keep battery-backed RAM within the rom file itself, so you don't have to copy .sav's from one emulator's folder to another. Am I the only one who would like this?
I've been thinking the exact same thing, cause that's how the real games work. If we're gonna make a new format (again) then lets include it!
But I'm not so sure about a re-implementation of mapper numbers. What's wrong with board names?
Nessie wrote:
I've been thinking the exact same thing, cause that's how the real games work. If we're gonna make a new format (again) then lets include it!
Well, that would be a problem if (like me) you tend to keep stuff on CD-ROMs. Those ROMs really would be read-only.
I rarely had a problem between emulators, just having them all point to the same /SAV/ directory for saves (when it's allowed).
But it would make sense to allow that for emulating something like a Game Action Replay (though having pre-programmed SRAM seems like an abomination to me, heheh).
Great Hierophant wrote:
By the way, the default mirroring on the NES is horizontal, isn't it?
"Default mirroring" depends entirely on the mapper. Some mappers start out in horizontal on reset; others in vertical.
Memblers wrote:
But it would make sense to allow [storing SRAM state in the ROM image] for emulating something like a Game Action Replay (though having pre-programmed SRAM seems like an abomination to me, heheh).
If an SRAM cart is an abomination, then the Famicom Disk System is just as much an abomination.
tepples wrote:
If an SRAM cart is an abomination, then the Famicom Disk System is just as much an abomination.
Problem is when it's like the GAR and battery-backed, when the battery loses power the cart is dead (reset routine and everything is in RAM). Only a modified NES (like CopyNES) can make it work again.
I agree with Memblers, appending SRAM to carts is not a good idea. Bad enough that some carts with f*cked-up mappers don't set the battery backed RAM bit correctly as it is. However, even then it wouldn't be as bad as the Famicom Disk System images, which embed their save information somewhere on the disk. Good luck getting a fresh copy of Metroid, Hikari Shinwa: Partuena no Kagami, Zelda no Densetsu or Castlevania.
The mapper numbers are just a substitute for the boards. Can anyone explain to me why BNROM is #34 and GNROM is #66? Why are there gaps? Why should pirate crap be assigned low numbers, rather than high numbers we can safely forget about? It just looks better. The original mapper numbers were assigned willy-nilly years ago by different people at different times with far less knowledge of the hardware than we have today.
the entire ines format is hacked together
I could piece together a better system alltogether that doesn't discriminate against Famicom carts... theres no reason why the NES scene should leave it out, such a thought is ludicrous!
The only reason I can see the Famicom games are left out of unif is because noone has them all, and has been willing to open them all up to see what boards they use.
And every company has their own board types, it's not like NES where they (mostly) used Nintendo boards.
So we have roms that work on iNES format with emu hacks, but the info to convert them to a more descriptive format is missing.
Right. It's not a problem with the UNIF format itself, but it's a problem with the lack of proper information in order to make them work with UNIF properly, instead of with ugly hacks to iNES.
As for this "iNES Advanced" format, I'm against it. UNIF is by far more semantically correct; from what I could gather, the main difference between iNES and iNES-A is that iNES-A assigns TWO arbitrarily-chosen numbers to a board, rather than just ONE.
Furthermore, do we really need a *third* format? We're having a hard enough time getting a *second* format accepted, let alone a *third* as well.
And seeing as iNES and iNES-A are mutually incompatible, we'd *still* have to wait for emulators to roll out support for the new format. Granted, it wouldn't be as difficult to update an iNES-only emulator to support iNES-A as it would be to make it support UNIF, but, they'd still have to update their mapper number databases and mapper emulation cores to accomodate it... just like with UNIF.
Two mappers numbers may be more accurate; but outright *naming the board* is dead-on accurate. If we're going to go through the trouble to get everyone's emulator upgraded to support a new format, why take only one or two steps in the right direction (with iNES-A) when we could be taking *ten* steps (with UNIF)?
With that said, I'll chime in on the issue of keeping SRAM inside the ROM itself: that might be feasable, but, if implemented, it should by no means be made mandatory: as someone mentioned, it won't work if the ROM is on a read-only medium (such as a CD-ROM); it also won't work- at least not very well- if the ROM is stored inside a compressed archive, e.g. a .zip file.
We could expand the actual iNES format, rather than a new one. In fact, UNIF is by far the most accurate ROM image packaging, bringing everything that really matters in a comprehensive way. Let's avoid this "spinning" and go support UNIF without taking out the "grandpa" iNES format.
iNes was not very far off the mark. Most of what it lacked was due to the too-common assumptions and generalizations made. UNIF is one way to focus on what needs to be emulated. But the UNIF format is barely documented and has no place yet for Famicom boards. What is the difference to an emulator between AMROM and AOROM; UNROM and UOROM; NES-MH and GNROM? If you emulate the latter board in each set, you can run the games that use the former boards. The sizes of the ROMs can tell anyone in the know the particular board type. That is why emulators can do perfectly well with mappers 7, 2 and 66 respectively. For most mapper 1 boards, the SxROM series, there is no real difference in the functionality of each board, only what is on it. Mapper 1 removes the difficulty of unecessary emulating many, many boards.
By the way, mapper 3 needs a correction. Even though no board containing a Nintendo MMC3 has hardwired mirroring, boards using Tengen's stripped down Mimic-1 chip do. Therefore:
03 - Nintendo MMC3
0 - TLROM or TGROM (No Save RAM)
1 - TKROM or TNROM (8KB Save RAM)
2 - TSROM (8KB Work RAM)
3 - TQROM (8KB CHR-RAM + CHR-ROM)
4 - TVROM (4-Screen Mirroring)
5 - TLSROM
6 - NES-QJ ('161 submapper)
7 - Super Mario Bros. + Tetris + Nintendo World Cup mapper
8 - Horizontal Mirroring (Hardwired only)
9 - Vertical Mirroring (Hardwired only)
Quote:
UNIF is one way to focus on what needs to be emulated. But the UNIF format is barely documented and has no place yet for Famicom boards. What is the difference to an emulator between AMROM and AOROM;
A few questions. First, why do you say UNIF is barely documented? Why do you say it has no place for Famicom boards? I don't think either of these statements is true. Also, your question "What is the difference to an emulator..." doesn't address one of the main design decidsions behind UNIF. While iNES exists only to allow for an emulator to work, UNIF exists to document and archive the cartridge. When all of the copies of Zelda have rotted into dust, hopefully somewhere will exist a UNIF version of the ROM complete with the manual, scan of the label and box etc.
The situation as I see it is this:
Nobody is totally happy with iNES. Not everybody is happy with any of the proposed extensions to iNES.
Nobody (as far as I know) has come up with legitimate technical problems with UNIF that can't be easily fixed. It's only problem is that it has been abandoned, which doesn't have to be the case.
UNIF is clearly better than iNES for everyone except the casual gamer who just want to play games. If we as a develpment community want a better situation, we need to make it happen and not just sit around and wait for the UNIF Fairy to fix everthing. We need to create a database to support a real iNES to UNIF conversion tool, and stop supporting a format we hate. Stop making emulators that read iNES without either converting or complaining, and start making development tools that can natively create UNIF files.
</rant>
teaguecl wrote:
...a UNIF version of the ROM complete with the manual, scan of the label and box etc.
to my recollection, UNIF (the current version anyway) doesn't offer any real support for such things. I had proposed (on the old board) some modifications to the format that, among other things, would. I don't remember whether anyone really seemed to care much. maybe I'll post it again sometime.
teaguecl wrote:
UNIF is clearly better than iNES for everyone except the casual gamer who just want to play games.
Does that include ROM hackers? The corpus of ROM hacking information and utilities out there are dependent on iNES, due to the fact that a given bit of data will be at the same file offset in any iNES file, but not in UNIF. I had come up with a couple file formats that would help mitigate these problems (a patching format to replace IPS, and an alternative form of UNIF that would allow chunk data to be stored external to the UNIF file itself), but, like my UNIF modification proposal, didn't seem to garner much attention when I posted about them (on the old board).
Maybe I should fix them up and post about them again.
If you want to redo a new header format, include board names or iNes mapper numbers, but PLEASE not a new set of mapper number. This would be awfull to have two different set of mappers numbers ! Everyone will mix up MMC3 (4 that will be 3) with CNROM (3), etc... Every mapper will have two different numbers ! That'll be awfull.
Inculding sram in the ROM file is an interessting idea, but that won't be pratice to download sram files, you'll have to download the whole (and illegal) rom.
I prefer to keep read-only data and read-write data separated as a matter of general principle. Do you really want an emulator with a bug in it to be able to scribble all over your ROMs? It's bad enough with FDS where this can't be helped due to the nature of the format.
Actually, I wish emulators would implement FDS saving in the form of a diff-like file, rather than by directly overwriting the disk image.
If all you want to do is extend iNES to recognize mappers better, you might as well just start adding the board name to the end of the ROM (after all ROM banks). Some ROMs already have trash there (some store the game name there), but if a valid board name isn't found at the end of the ROM, the emulator could simply fall back to the regular iNES/CRC recognition routine
so the tagged ROMs would work as usual anyway. (Unless there's actually a board named vimm.net
)
I have given up on trying to make the iNES format work properly so I've built a database with all 'good' dumps in GoddNes and their correct hardware info (PAL/NTSC, board name, mirroring, PRG size, etc). In a future version of Nessie, whenever you load a ROM, the iNES header will be completely ignored if the ROM is found in the database.
Thing is, I don't have more than 35-40 carts to check with myself, and the UNIF cart list was rather incomplete, so I had to guess many of the boards
Maybe we all could go together and build a more complete list of carts and boards, perhaps Famicom games could be included as well?
Vystrix Nexoth wrote:
teaguecl wrote:
...a UNIF version of the ROM complete with the manual, scan of the label and box etc.
to my recollection, UNIF (the current version anyway) doesn't offer any real support for such things. I had proposed (on the old board) some modifications to the format that, among other things, would. I don't remember whether anyone really seemed to care much. maybe I'll post it again sometime.
as i remember the unif format is like html tags, you just added the info as new tags and the tags are ignored by stuff that does't recognise them, and the improvements to the format are just posted to a further format number
i've always thought, splitting prg/chr roms would be the best way, like pasofami or whatever. then, you have a text file with all the things needed to identify it, developer, ines mapper number, publisher, prg/chr rom sizes, # of players, etc. which also allows for easy categorization within emulators. i proposed this and stopped it, i called it the "split game pak" format in olafnes.
teaguecl wrote:
Nobody (as far as I know) has come up with legitimate technical problems with UNIF that can't be easily fixed.
Other than that a chunked format makes distribution of ROM patches harder?
Quote:
We need to create a database to support a real iNES to UNIF conversion tool, and stop supporting a format we hate.
How are we going to get our hands on every known Game Pak in order to get the right board name for each PRG/CHR MD5 pair?
Olaf: The "split" format you describe is almost exactly what MAME does.
> chunked format makes distribution of ROM patches harder?
You could just line up PRG0-9 + CHR0-9 and run an ordinary IPS on the resulting data.
Of course, this only works until you wanna patch anything other than the PRG/CHR data.