ROM Registration Data Specification

[HatCat]

The main reason I'm summarizing a little documentation given about this is because it illustrates the ambiguities caused by GoodN64. Many people compare the naming conventions provided by GoodN64 to Nintendo's official release information about the corresponding games, and doing this introduces some confusion.

The "ROM registration data specifications" refer to the documentation of the second half of the master ROM file header. The header of every N64 ROM image file is 64 bytes, so the second half of this data containing the registration data is the range of addresses 0x20 to 0x3F. Unlike the first half of the header (range of addresses 0x00 to 0x1F), the registration data section has no effect on N64 execution. In fact, in public domain N64 applications, in general all of these bytes are set to null. These specifications were designed to apply to official publications of N64 games.

1. Addresses 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32, and 0x33 constitute a string that defines the "game title" field. Since the official game title and any subtitles included are provided for marketing purposes, the version here that is constrained to no more than 20 characters long should also resemble the complete game title in some optimal way for that same purpose. The customized string that GoodN64 marks as the "good name" has nothing to do with the official name or the version here.
2. Addresses 0x34, 0x35, 0x36, 0x37, and 0x38 are all fixed to the null byte character for every N64 game. Additionally, 0x39 and 0x3A are also reserved addresses and fixed to the zero value.
3. Addresses 0x3B, 0x3C, 0x3D, and 0x3E constitute a 4-byte string that defines the "game code" field. The developer of the game does not choose this setting; the game code must be requested and approved by Nintendo's product administration. The fourth character of the "game code" field, the "destination code", is stored in address 0x3E. This program/language symbol is not 100% of the time the same territory indicator specified by GoodN64. Its known values that may have been assigned to the release are as follows.
   • 65 0x41 'A' (not documented, generic NTSC?)
   • 66 0x42 'B' "Brazilian"
   • 67 0x43 'C' "Chinese"
   • 68 0x44 'D' "German"
   • 69 0x45 'E' "North America"
   • 70 0x46 'F' "French"
   • 71 0x47 'G': Gateway 64 (NTSC)
   • 72 0x48 'H' "Dutch"
   • 73 0x49 'I' "Italian"
   • 74 0x4A 'J' "Japanese"
   • 75 0x4B 'K' "Korean"
   • 76 0x4C 'L': Gateway 64 (PAL)
   • 78 0x4E 'N' "Canadian"
   • 80 0x50 'P' "European (basic spec.)"
   • 83 0x53 'S' "Spanish"
   • 85 0x55 'U' "Australian"
   • 87 0x57 'W' "Scandinavian"
   • 88 0x58 'X' "Others"
   • 89 0x59 'Y' "Others"
   • 90 0x5A 'Z' "Others"
4. Address 0x3F is used to store a character that identifies the "mask ROM version" field. Together, the mask ROM version and "submission version" (which refers indirectly to the EEPROM) fields constitute the "ROM version" field, but only the mask ROM version is defined in the registration data. The ROM version is of the format [MASK ROM VERSION].[SUBMISSION VERSION], not the artificial (V1.[MASK ROM VERSION]) syntax that GoodN64 uses.
5. The only character codes accepted by Nintendo to be used to define the registration data are those from the space character (032 0x20 %00100000) to the tilde character (126 0x7E %01101110), but the null byte may be used by Nintendo after software submission.

Anyway, it's not like any of these labels are trademarked or whatever, and this is stuff easy to figure out. For that reason this little summary shouldn't violate anything, but the point is that the italicized text in this post refers to contradictions via the inaccuracies in GoodN64's naming conventions.

[Lithium]

I found this thread on google

Very useful info