iNES Advanced

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Great Hierophant
Posts: 769
Joined: Tue Nov 23, 2004 9:35 pm

Post by Great Hierophant » Fri Dec 17, 2004 12:53 pm

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)

User avatar
teaguecl
Posts: 210
Joined: Thu Oct 21, 2004 4:02 pm
Location: San Diego

Post by teaguecl » Fri Dec 17, 2004 2:57 pm

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>

Vystrix Nexoth
Posts: 3
Joined: Sat Dec 04, 2004 8:45 pm
Location: somewhere between anima and animus

Post by Vystrix Nexoth » Fri Dec 17, 2004 7:07 pm

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.

User avatar
Bregalad
Posts: 8008
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Sat Dec 18, 2004 12:06 pm

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.
Useless, lumbering half-wits don't scare us.

AWJ

Post by AWJ » Sat Dec 18, 2004 12:52 pm

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.

Nessie
Posts: 134
Joined: Mon Sep 20, 2004 11:13 am
Location: Sweden
Contact:

Post by Nessie » Sat Dec 18, 2004 1:02 pm

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?

RoboNes
Posts: 48
Joined: Mon Sep 20, 2004 6:47 am

Post by RoboNes » Sun Dec 19, 2004 4:52 am

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

olaf
Posts: 3
Joined: Sun Jan 02, 2005 9:51 pm
Contact:

Post by olaf » Sun Jan 02, 2005 10:01 pm

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.

tepples
Posts: 22284
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sun Jan 02, 2005 11:41 pm

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?
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.

Nessie
Posts: 134
Joined: Mon Sep 20, 2004 11:13 am
Location: Sweden
Contact:

Post by Nessie » Mon Jan 03, 2005 12:52 am

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

Post Reply