Metal Slader Glory/ROM map

From Data Crystal
< Metal Slader Glory
Revision as of 17:22, 24 November 2018 by FCC (talk | contribs)
Jump to navigation Jump to search

Chip tiny.png The following article is a ROM map for Metal Slader Glory.

ROM

Note for template.png
Note:
Size = EntryNumber Template:X 3 - 1
* 0x001CC5 to 0x003D5B (02096) = Primary pointer table for the entire game's dialogue. Pointer entries are three bytes each. Text is scattered around the ROM haphazardly. Length bits in the address pointer are zeroed out for every entry. The byte 00 is used as a delimeter.
* 0x003D5C to 0x005F57 (021FB) = Primary pointer table for dictionary. Pointer entries are three bytes each. Text is scattered around the ROM in small patches. 
* 0x05485C to 0x07400E (-----) = Dialogue region.

Pointer structure

Although typically for SNES games, this game uses three byte pointers; however, this game adopts a space saving measure by storing a dialogue entry's length within a pointer. The dialogue's pointers have the length bits zeroed out because it uses a delimeter. The dictionary's pointers use the bit, because 0x00 is a valid CHR tile value.

Address layout (in bits)

The Stardust Crusaders translation uses the length bits to use the translation's expanded ROM space. This is only for the dialogue. The dictionary needs these bits.

a

, b = length bytes

x

, y , z = Address bytes

a1 a2 

x1 x2 x3 x4 x5 x6 y1 y2 y3 y4 y5 y6 y7 y8 b1 b2 b3 z1 z2 z3 z4 z5


Length   = 		-  -  - 

a1 a2 b1 b2 b3

Address  = 
     
     Original:
     cccccccc =  0  0  0  0  0 

x1 x2 x3

     dddddddd = x4 x5 x6 

z1 z2 z3 z4 z5

     eeeeeeee = y1 y2 y3 y4 y5 y6 y7 y8


     Translation:
     cccccccc =  0  0  0 

a1 a2 x1 x2 x3

     dddddddd = x4 x5 x6 

z1 z2 z3 z4 z5

     eeeeeeee = y1 y2 y3 y4 y5 y6 y7 y8


     Final PC address = cccccccc dddddddd eeeeeeee

Dictionary

The dictionary stores dictionary entries for the dialogue to use. It uses bytes that correspond to the CHR, expect for control codes. Control codes start with 0x00 ([BLACK 1] in the CHR).

Hex values

The dictionary values are stored sequential by pointer. The dictionary byte values go from 0x00 to 0x7F then jumps from 0x8080 to 0x8EF5. The 0x7F pointer entry would correspond to 0x7F in hex. The 0x80 pointer entry would correspond to 0x8080, and the 0x81 pointer entry would correspond to 0x8081. For translations, use the first byte range for your most used characters to save space.

Character codes

Character codes display character's names in the dialogue. Here's some examples from the English translation:

<e no="32" PrimaryAddress="0x548D0" Byte_Length="0x0E">[BLACK 1][!?]Tadashi:[BLACK 1]%[BLACK 1]5</e>
<e no="33" PrimaryAddress="0x548DE" Byte_Length="0x0C">[BLACK 1][!!]Elina:[BLACK 1]%[???1]”</e>
<e no="34" PrimaryAddress="0x548EA" Byte_Length="0x0C">[BLACK 1][!!]Azusa:[BLACK 1]%[BLACK 2]M</e>
<e no="35" PrimaryAddress="0x548F6" Byte_Length="0x0D">[BLACK 1]?Charmy:[BLACK 1]%[TILE 09][!!]</e>
<e no="36" PrimaryAddress="0x54903" Byte_Length="0x0A">[BLACK 1][???3]Gen:[BLACK 1]%%[???3]</e>

The format is as so:

0x00 • BYTE_FOR_TEXT_LENGTH • TEXT • 0x00 • CODE
  • The 0x00s are constants.
  • The second byte is for the length of the speaker's name entry. "Tadashi:" is eight character's long and the "[!?]" is 0x08 in the CHR. For some reason, the translation doesn't include the space in these entries and instead has a space in the script each and every time these character codes are used. Seems like a waste of space.
  • The code entry needs further research, although it deals with the character's speech pitch and pattern and maybe other things as well.