• Describes patch data in a semantically-rich way, thereby allowing a patch to be applied to either an iNES or a UNIF ROM file, or indeed any other NES ROM file format if supported by the patcher.
• Can record extensive meta-data, such as the author's name, website address, commentary, the title of the hack, and other such things. This meta-data uses UTF-8 encoding to accomodate those who don't speak English, and can also record a language code, so if the author wishes to give meta-data in multiple languages, he/she can, in which case a patcher could select which one to view based on the user's system settings.
• Accomodates ROM expansion more elegantly, by allowing for instructions which insert, delete, or rearrange the contents of PRG-ROM or CHR-ROM, rather than just overwriting data.
• Includes optional checksums to help ensure that the correct file is being patched.
• Allows for variants, whereby essentially multiple patches can be present in the file, plus allowing for some patch data to be common to all variants. This allows for a patch that can be applied to multiple versions of a given game; for example, a hack of Final Fantasy II that can be applied to either the original Famicom ROM or to an English translation thereof, with patch data common to both not having to be defined twice.

unsigned long int address;
address = fgetc(patchfile) | (fgetc(patchfile)<<8) | (fgetc(patchfile)<<16);

Originally posted by TheMonster

---

I know Playstation hacking is fairly non-existent, but that could change...

---

• Devise independent- but related- formats for each system, e.g. USRIF (Universal SuperNES ROMhack Interchange Format) for SuperNES games, which would presumably have the same foundation as UNRIF (block format/methods, meta-data, variations, etc) but replace PDAT/CDAT/PCRC/CCRC/MAPR/MIRR with chunks appropriate for the nuances of the Super NES. Other such formats could make other changes necessary to accomodate the system, e.g. by expanding block addressing from 24-bit to 32-bit if necessary.
• Extend UNRIF to define a console name inside the format itself, and have META and VARY be common to all formats, and with other chunks specific to a particular system. This is essentially the same as the first, except patches for different systems would presumably have the same filename extension and the distinction would be made inside the patch itself.

Originally posted by Geiger

---

One other suggestion is that you may wish to consider using Unicode instead of UTF8. Unicode is supported on most operating systems in one form or another. And Microsoft, at least, is being a bit heavy-handed about its use nowadays.

Basically, I am suggesting this as a "future proof" feature. If not a required part of the standard format, perhaps one of the remaining 64 bits could designate that the patch uses Unicode instead of UTF8.

---T.Geiger

---

• Unlike UTF-16, UTF-8 will not have any 00 bytes in the course of normal text (except to represent the Unicode character U+0000, a character which is expressly forbidden from meta-data in the UNRIF spec), so a program can easily scan for the end of a tag by looking for a 00 byte. UTF-16, on the other hand, will have almost every other byte be a 00 byte, for Latin-alphabet text.
• UTF-8 is more compact than UTF-16 when representing Latin-alphabet text (which is used by English, French, German, Spanish, Swedish, etc), which I presume will be the most commonly-used writing system for meta-data.

Originally posted by HyperHacker

---

I like the metadata idea and being able to select things, but really, this has two major problems. One, it's becoming ridiculously complicated. Two, system-specific patch formats suck hard.

---

• To apply the patch to an iNES ROM, you assume the PRG is 16KB x whatever is set in the 5th byte of the iNES header, and then you apply the PRG data by adding 0x10 to each address, and CHR data by adding 0x10 + PRG size to each address. For UNIF ROMs, you scan the file looking for chunks (skipping over unrecognized ones by reading the length field (which is 32-bit unsigned, little-endian) and skipping over that many bytes), and if you find a "PRG0" chunk, apply the PRG patch to the stuff therein, and if you find a "CHR0" chunk, apply the CHR patch to the stuff therein.
• Over here is PRG data. Over here is CHR data. Deal with it.

• U+0000..U+007F (ASCII: A-Z, a-z, 0-9, and everyday punctuation): UTF-8 = 1 byte, UTF-16 = 2 bytes.
• U+0080..U+07FF (Latin accented characters, Greek, Cyrillic, Hebrew, Arabic, and others): UTF-8 = 2 bytes, UTF-16 = 2 bytes.
• U+0800..U+FFFF (many, but primarily Japanese/Chinese/Korean): UTF-8 = 3 bytes, UTF-16 = 2 bytes.
• U+10000..U+10FFFF: UTF-8 = 4 bytes, UTF-16 = 4 bytes.