Sega Ages 2500 Series Vol. 17: Phantasy Star generation:2/Notes

Most data below are little-endian.

Compression

CUE found out the coding algorithm. It's a Lempel-Ziv related one, called Lempel-Ziv Renau.

Structure of files :

• Bytes $0000 to $000a : header
  • 2 bytes : signature, always "CM"
  • 4 bytes: decoded data length, low endian
  • 4 bytes: encoded data length, low endian

• From $000a : ENCODED_DATA

• Then FLAGS. Flags are read bit per bit :
  • if bit = 0, then put one byte from ENCODED_DATA and put into DECODED_STREAM
  • if bit = 1, then the corresponding half-word in ENCODED_DATA is of the form lllloooooooooooo, where l = length and o = offset. Copy then 'length + 3' bytes from DECODED_STREAM[current_position - offset + 1] to DECODED_STREAM[curent_position].

• Fill the file with $00, up to have a file size dividible by $800.

Files specifications

Graphics files (SGGG)

They are just 256 colors palette indexed bitmap files.

• bytes $0 to $3 : 'SGGG' (identifier)
• bytes $4 to $7 : always 1, usage unknown
• bytes $8 to $9 : width (Little Endian)
• bytes $a to $b : height (LE)
• bytes $c to $f : unknown

• bytes $10 to $410 : palette. Each color is 32b RGBA. Alpha max seems to be $80 (and most colors are alpha max). Colors are stored in a weird way though :
  • colors $0 to $7
  • colors $10 to $17
  • colors $8 to $f
  • colors $18 to 1f
  • and so on...

• from bytes $410 : bitmap. The picture seems cut in 512×512 blocks in scan order, each of which described row per row, from top to bottom.

For example, a 640×448 bitmap is cut in 2 rects, one with pixels (0 - 511, 0 - 447) and the other (512 - 639, 0 - 447). No bitmap actually need more than 2 rects.

• some files may contain other palettes after the bitmap.

Font file

The font file is file 0002 in MAPDATA.DAT archive. It's a SGGG file (see above) with the following characteristics :

• its size is 512×512
• its palette contains 64 times the 4 same colors : $FFFFFF00, $FFFFFF3A, $FFFFFF5F, $FFFFFF7F. They are all white colors, with varying alpha, for antialiasing purposes when drawing the character
• the bitmap file is actually made of 4 512×512 layers ; each byte in the bitmap part of the SGGG codes 4 pixels, one for each layer :
  • bits 0-1 code a 4 colour pixel in layer 0
  • bits 2-3 code a 4 colour pixel in layer 1
  • bits 4-5 code a 4 colour pixel in layer 2
  • bits 6-7 code a 4 colour pixel in layer 3

We can thus obtain those 4 characters sheets :

(todo : insert them)

Maps files

They are all located in MAPDATA.DAT archive file.

A map is made of several layers, from top to bottom. The layer is made of tiles (always 32×32), found in SGGG files. To know which tileset is used for a given layer can be found in the SLPM_625.53 file.

The last layer is the collision map. The tileset file associated is always MAPDATA.DAT\0112.

Map file specification

• 4 bytes : number of planes, excluding the collision map plane
• 4 bytes : width (in tiles)
• 4 bytes : height (in tiles)
• 4 bytes : unknown (always 07000000)
• 16 bytes : unknown (always 01000000 00000000 00000000 00000000)

• from pos 32 : layers info
  • 1 byte : tileset id (a same tileset can be shared between several layers)
  • 1 byte : blend mode

Usually 0 (classical blend with a unique alpha value for the entire layer). When set to 1, blend multiplying RGB value by the alpha value, then add RGB values with the bottom layer.

• • 1 byte : alpha (on a base 100)
  • 1 byte : unknown. Generally 100, can be greater (e.g. in file 0176)
  • 12 bytes : unknown (generally 0s)

• layer data

Layer is parsed from top row to bottom row, each row from left to right. Two bytes per tile, the two most significant bits code flipping.

• just before the collision layer : Treasure boxes data
  • 4 bytes : number of boxes, then for each box :
  • 4 bytes : unknown (8 for boxes)
  • 4 bytes : x position (in pixels, not tiles)
  • 4 bytes : y position
  • 2 bytes : unknown (0 or 1)
  • 2 bytes : unknown. likely event id (each box in a map has a different number, starting from 0)
  • 12 bytes : unknown (generally 0s)

• after collision layer : lift data
  • 4 bytes : number of lifts, then for each
  • 4 bytes : id ?
  • 2 bytes : x position (in pixels)
  • 2 bytes : y position
  • 2 bytes : width
  • 2 bytes : height