ROM usage

000000-007FFF : Most of the game engine
010000-01xxxx : Raw name table data
020000-03FFFF : Compressed tile data

Memory usage (general)

C700 : Records for background objects, 64 bytes each
CE00 : Work buffer where name table data for background objects is plotted

Memory usage (decompression)

C190.b : Run length count
C191.b : Number of bitplanes to decompress (4 to 0)
C192.b : Run type (copy literal data or repeat)
C193.w : Destination address in VRAM
C195.w : Offset in $8000-$BFFF to read compressed data
C1A0   : Work buffer used to decompress graphics

Decompression overview

The Phantasy Star decompression routine is used here. Tiles to decompress are described by a record and records can be grouped together. I think compression runs can cross group boundaries as the decompression routine saves the RLE count and uses it again for the next group.

There is a table at $08BB that contains $44 pointers to a group of records in the 09xx-0Bxx range. Each group consists of a length byte and then N number of records following it. The first byte of the record is set to $FF to act like an end marker. All entries describe objects that are rendered into the background layer and isn't related to sprites.

An example of how this data is parsed for index $00:

- $08BB entry #$00 contains the pointer $0941
- $0941 contains "10 02 00 4D 00 80 04 20 5A 00 AB 08 60 CA C1 AC FF"
- The first byte, $10, is the length of the record group (16 following bytes)
- The record group is copied to the decompression work buffer at C1A0 onward (I think approx 36 bytes?)

Each record is 5 bytes:

+$00.b : ROM bank # (00-0F, where FF is end-of-record marker)
+$01.w : VRAM address
+$03.w : ROM bank offset in $8000-$FFFF range

Once a record has been processed (tile data decompressed to VRAM) the entire work buffer is shifted back by 5 bytes and the process repeats until the $FF marker is found. Most record groups have one entry, but a few have multiple entries.

Functions of interest:

$07E4 : Tile decompression routine, inputs are parameters in C19x (copies of parameters used during decompression) and C1Ax (current record out of a group)
$08A9 : Routine that looks up data to decompress from an index in A
$0893 : Decompression setup, the earlier code falls into this when processing multiple records
$4E3D : Routine that plots a background object into the working buffer.
$049F : Routine that copies a lot of data from ROM into the name table work buffer at CE00+

Background object rendering

$4DC6 is the start of the rendering routine. The object record pointed to by IX is rendered into a left frame buffer, right frame buffer, or both. The latter is the case for objects far enough in the background that they don't need stereo separation. The order of rendering is left then right.

In 2D mode only the left buffer is used. For example if you set 2D mode then patch out the left frame rendering then nothing is displayed on the background layer. This does not affect player to background collisions which are handled separately from rendering.

The code path at $4E2D is only for objects that are moving vertically upwards off-screen, such as the jets that fly up in stage 1.

Record format

Each one is 64 bytes. Some of the data is:

$20 : Flags
      Bit 1 is set if the object goes into the left frame buffer.
      Bit 2 is set if the object goes into the right frame buffer.
      Both bits are set if the object is in both buffers.
$22 : Loaded with either $23 or $24 depending on which rendering pass and buffer the object goes in
$23 : Parameter for left frame buffer
$24 : Parameter for right frame buffer
$26-29 : Parameters for the left frame buffer
$2C-2F : Parameters for the right frame buffer
$2A : Width of object in bytes (e.g. 16 bytes if it is 8 tiles wide)
$2B : Height of the object in rows
$36 : Bank number associated with object.



Return to top
0.121s