It is currently Sat Dec 16, 2017 4:24 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Fri Dec 17, 2004 12:53 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 634
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)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 17, 2004 2:57 pm 
Offline
User avatar

Joined: Thu Oct 21, 2004 4:02 pm
Posts: 210
Location: San Diego
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>


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 17, 2004 7:07 pm 
Offline
User avatar

Joined: Sat Dec 04, 2004 8:45 pm
Posts: 3
Location: somewhere between anima and animus
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 18, 2004 12:06 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7317
Location: Chexbres, VD, Switzerland
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.

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


Top
 Profile  
 
 Post subject:
PostPosted: 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.


Top
  
 
 Post subject:
PostPosted: Sat Dec 18, 2004 1:02 pm 
Offline

Joined: Mon Sep 20, 2004 11:13 am
Posts: 134
Location: Sweden
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 19, 2004 4:52 am 
Offline

Joined: Mon Sep 20, 2004 6:47 am
Posts: 48
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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 02, 2005 10:01 pm 
Offline

Joined: Sun Jan 02, 2005 9:51 pm
Posts: 3
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 02, 2005 11:41 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 03, 2005 12:52 am 
Offline

Joined: Mon Sep 20, 2004 11:13 am
Posts: 134
Location: Sweden
> 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. :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group