Hey guys.
A while ago, Tennessee asked me to be the maintainer of UNIF so I am happily hosting the standard at both my personal site (http://codef00.com/unif_cur.txt) and at the libunif google code project (https://code.google.com/p/libunif/downloads/list).
Over time, it has become apparent that UNIF has some shortcomings (http://wiki.nesdev.com/w/index.php/UNIF#Shortcomings). While I know that UNIF isn't quite as widely adopted as some might have hoped, I do think it is worth updating the standard to at least address some of the issues it has in case people want to support it.
So here's what I've got in mind so far:
* NULL terminated text fields will be UTF-8, not ASCII. This is 100% backwards compatible, and allows the original name to be placed in the NAME block. It also, allows PCB's with non-US characters in them to be used correctly in the MAPR field. Almost all of the time, whatever is reading the image doesn't need to be UTF-8 aware, it can just do an ordinary memcmp on the byte string. Of course, it should be displayed as unicode so the user sees the real name .
* There is a single UNIF image in the GoodNES DB which has the "WRTR" block (Korean Igo (Unl) [U][!].unf). This was created by uCON64. I am undecided about whether or not to make it official. My gut says no since the spec already says "skip non-understood blocks". I don't like images having proprietary blocks, but such is life.
* VROR will be more specific. I think the intended interpretation was "if VROR is present, ignore any CHR-ROM blocks and instead provide CHR-RAM".
* VROR's byte value will specify how much CHR-RAM to provide. I am thinking that amount of CHR-RAM will be
* I want to add a new SYST, block meaning "SYSTEM". This would be 1 byte big and allow specifying "NES", "Playchoice 10", "Vs. System", etc.
* I think it worth have a "LANG" block which would contain an IETF language tag, such as "en-US" and so forth.
* A cool feature I am toying with (I am unsure if it would be worth while), would be to have a new "XLAT" block. This block could be specified 0 or more times. And would allow the image to specify that it is the same as another game, but differs in language. For example the UNIF image for castlevania 3 might have an "XLAT" block which has something like this.
or something to that effect. Would be interesting to better deal with multi-lingual collections, but may not provide much actual value in practice (would the emulator search your entire rom collection for the translation? that would be a big time waster). So I could go either way with this one.
* I am open to suggestions on how to better address the CTRL and BATR blocks.
* I am also (hesitantly) considering an "INES" block, which would 16 bytes and contain the "known good' iNES 2.0 header. Even though UNIF was designed as a "superior" replacement to INES, it is clear the INES is here to stay, so the standard may as well embrace that offer a means to store that type of information. Though I am very hesitant to include this type of block, since it would perhaps encourage (lazy) people to ignore a lot of the other blocks :-/
* Finally, it seems that there should be some blocks to specify PRG-RAM, though I haven't put much thought into the details of this.
Thoughts?
A while ago, Tennessee asked me to be the maintainer of UNIF so I am happily hosting the standard at both my personal site (http://codef00.com/unif_cur.txt) and at the libunif google code project (https://code.google.com/p/libunif/downloads/list).
Over time, it has become apparent that UNIF has some shortcomings (http://wiki.nesdev.com/w/index.php/UNIF#Shortcomings). While I know that UNIF isn't quite as widely adopted as some might have hoped, I do think it is worth updating the standard to at least address some of the issues it has in case people want to support it.
So here's what I've got in mind so far:
* NULL terminated text fields will be UTF-8, not ASCII. This is 100% backwards compatible, and allows the original name to be placed in the NAME block. It also, allows PCB's with non-US characters in them to be used correctly in the MAPR field. Almost all of the time, whatever is reading the image doesn't need to be UTF-8 aware, it can just do an ordinary memcmp on the byte string. Of course, it should be displayed as unicode so the user sees the real name .
* There is a single UNIF image in the GoodNES DB which has the "WRTR" block (Korean Igo (Unl) [U][!].unf). This was created by uCON64. I am undecided about whether or not to make it official. My gut says no since the spec already says "skip non-understood blocks". I don't like images having proprietary blocks, but such is life.
* VROR will be more specific. I think the intended interpretation was "if VROR is present, ignore any CHR-ROM blocks and instead provide CHR-RAM".
* VROR's byte value will specify how much CHR-RAM to provide. I am thinking that amount of CHR-RAM will be
Code:
(2 ^ value)
. With the special case of 0 meaning "8K" since most (all?) UNIF images out there have a 0 in this block.* I want to add a new SYST, block meaning "SYSTEM". This would be 1 byte big and allow specifying "NES", "Playchoice 10", "Vs. System", etc.
* I think it worth have a "LANG" block which would contain an IETF language tag, such as "en-US" and so forth.
* A cool feature I am toying with (I am unsure if it would be worth while), would be to have a new "XLAT" block. This block could be specified 0 or more times. And would allow the image to specify that it is the same as another game, but differs in language. For example the UNIF image for castlevania 3 might have an "XLAT" block which has something like this.
Code:
struct XLAT {
char lang[10] = "ja"
char name[] = "Akumajou Densetsu"
}
char lang[10] = "ja"
char name[] = "Akumajou Densetsu"
}
or something to that effect. Would be interesting to better deal with multi-lingual collections, but may not provide much actual value in practice (would the emulator search your entire rom collection for the translation? that would be a big time waster). So I could go either way with this one.
* I am open to suggestions on how to better address the CTRL and BATR blocks.
* I am also (hesitantly) considering an "INES" block, which would 16 bytes and contain the "known good' iNES 2.0 header. Even though UNIF was designed as a "superior" replacement to INES, it is clear the INES is here to stay, so the standard may as well embrace that offer a means to store that type of information. Though I am very hesitant to include this type of block, since it would perhaps encourage (lazy) people to ignore a lot of the other blocks :-/
* Finally, it seems that there should be some blocks to specify PRG-RAM, though I haven't put much thought into the details of this.
Thoughts?