Updated UNIF - NESdev BBS

Updated UNIF
by tepples on 2006-07-18 (#15481)

In this post, mattmatteh wrote:

i dont see the point in updating the ines file format. it seems like this was a problem before and unif was created to solve that. it didnt, there are stilll alot of messed up ines formats out there. i think we need to push the unif format and get it over with. and if unif is lacking something then lets talk about adding to that.

UNIF is still missing the following, as I understand it:

A defined method of "soft patching" for translations, conversions, and other hacks, to replace part of a given chunk with some other data.
A way to express the "mapper" (which I define as the overall behavior of a set of cartridge boards that behave similarly) when the board name is unknown, the board name changes per game (common for Konami carts) or the board is found to have no name (common for some Famicom carts and pirate carts).
Support in auditing tools such as GoodNES.
Support in emulators that run on handheld devices, such as PocketNES for GBA, PocketNES for Windows Mobile, and nesDS.

by Quietust on 2006-07-18 (#15482)

From a technical standpoint, UNIF is also incapable of expressing the logical size of each PRG/CHR block - for example, while SMB3 is 256/128, the logical size is how the MMC3 addresses it - 512/256.
The only games that really rely on this sort of behavior are Action 52 and a few pirate multicarts, where the board has room to populate up to 4 ROMs but one (in the middle) is left empty.

by tepples on 2006-07-18 (#15484)

Quietust wrote:
From a technical standpoint, UNIF is also incapable of expressing the logical size of each PRG/CHR block - for example, while SMB3 is 256/128, the logical size is how the MMC3 addresses it - 512/256.

That's supposed to be associated to the board name. Any ROM whose board name matches /NES-T[A-Z]+ROM/ has a 512 KB logical PRG and a 256 KB logical CHR.

Quote:
The only games that really rely on this sort of behavior are Action 52 and a few pirate multicarts, where the board has room to populate up to 4 ROMs but one (in the middle) is left empty.

Then there should be multiple ROM segments. For instance, PRG0, PRG1, and PRG3 chunks might be present, and if PRG2 is absent, the handler associated with the board name should decide what to do.

by Quietust on 2006-07-18 (#15486)

tepples wrote:
Quote:
The only games that really rely on this sort of behavior are Action 52 and a few pirate multicarts, where the board has room to populate up to 4 ROMs but one (in the middle) is left empty.

Then there should be multiple ROM segments. For instance, PRG0, PRG1, and PRG3 chunks might be present, and if PRG2 is absent, the handler associated with the board name should decide what to do.

The trouble is, that adds a considerable amount of complexity to emulators, as it requires them to address PRG/CHR not only by banks, but by chips as well, making it considerably more difficult to share any code between iNES and UNIF mapper code (or even between two different UNIF boardspecs which happen to share the same basic mapper, such as the MMC3).

by mattmatteh on 2006-07-18 (#15490)

well my knowledge of all the nes games is limited. but i like the unif format better for the chunks that is has, easier to work with. i was thinking that new chunks could be add/used instead of the board name to overcome these problems. incase of 2 or more chunks with conflicting data then i would assume the later takes precedence or the emulator would refuse to load it. is it possible to come up with new chunks? if necessary have an ines, INES, chuck with the current header information. or have a mapper section, MMC, that would have the mappter name. these are some of the ideas i had. not sure if they make sence as i said earlier my knowledge fof all the games is limited.

i thought boodgod was working a rom database to repair roms? i dont have windows so i can not use goodNES and its closed source. so the goodNES is meaningless to me.

matt

by blargg on 2006-07-19 (#15497)

Quote:
i thought boodgod was working a rom database to repair roms? i dont have windows so i can not use goodNES and its closed source. so the goodNES is meaningless to me.

Incorrect! GoodNES is primarily a map between PRG+CHR CRC-32 checksums and game names, stored in a text file (as far as I can tell, since I don't have a Windows machine either). Anything can use this text databse; I even did a search-and-replace to convert it to a C-language array of strings and checksums so it'd be directly accessible without any parsing.

by mattmatteh on 2006-07-19 (#15498)

oh thanks. i did grab the windows download and look at but didnt see the text file. ill have to try again.

matt

by tepples on 2006-07-19 (#15501)

Quietust wrote:
The trouble is, that adds a considerable amount of complexity to emulators, as it requires them to address PRG/CHR not only by banks, but by chips as well, making it considerably more difficult to share any code between iNES and UNIF mapper code (or even between two different UNIF boardspecs which happen to share the same basic mapper, such as the MMC3).

That's easy: build a lookup table of all PRG bank values from 0 to 255 that map from logical banks to physical banks. In boards with a smaller ROM than the maximum the mapper can address, the higher ones would point down to the lower ones. (For a 256 KB PRG in an MMC3, the table would be 0..31 repeated 8 times.) In multi-chip boards, all the bank values on the missing chip 2 would point to the corresponding locations in chip 3 or wherever.

by proxy on 2011-03-08 (#75274)

I hate to necro this thread, but recently Tennessee Carmel-Veilleux has asked that I become the maintainer of UNIF (since I created the first implementation of UNIF in libunif found at http://code.google.com/p/libunif/). So, I just wanted to let everyone know that I will be hosting the latest version of the standard at http://codef00.com/unif_cur.txt for as long as I own the domain.

Likewise, while I know that iNES 2.0 is probably the goto ROM standard for NES, since I will be maintaining UNIF, I am happy to discuss any improvements that can be made to the UNIF standard.

Thanks