The wiki has recently moved; please report any issues in Discord. Pardon the dust.
Phantasy Star II/Notes
The notes are for the american version. Offsets are different in the japanese version (checked).
Graphics Storage
Basic Compression
The game uses one basic compression scheme, for storing some of the arts, as well as other data (such maps). Here's its description :
First, the data is split in 32 bytes chunks. Then, for each chunk:
- N (byte) : it's a counter. If $FF, the compression is over.
- repeat N times:
- V (byte) : the value that will be decoded
- M (long) : a mask indicating the locations in the current 32 byte chunk where to put this value
- At the end of the loop, some locations in the chunks may not have got a value. If so, they are given in raster order after at this point.
- Go to first stage.
An example from the game : the font is located at 0x29EB8
01 : N = 1
we repeat 1 time :
BB : the value
FF88B888 : the mask (=0b11111111100010001011100010001000). The current chunk is :
BBBBBBBB BBBBBBBB BB?????? BB?????? BB??BBBB BB?????? BB?????? BB??????
Since the loop is over, all subsequent bytes are values for each ?? in the preceding (there are 16 of them) :
11 11 11 16 66 66 16 16 BA AA 16 BA AA 16 BA AB : we get for the 1st chunk :
BBBBBBBB BBBBBBBB BB111111 BB166666 BB16BBBB BB16BAAA BB16BAAA BB16BAAB
02 : N = 2, so
BB, EE008000 : that gives
BBBBBB?? BBBBBB?? ???????? ???????? BB?????? ???????? ???????? ????????
55, 00102277 : now we have
BBBBBB?? BBBBBB?? ??????55 ???????? BB??55?? ????55?? ??555555 ??555555
16 values are left unknown :
B1 15 11 11 B1 66 6B 16 15 B1 61 AB 15 56 B1 15 : so the final value is :
BBBBBBB1 BBBBBB15 1111B155 666B1615 BBB15561 AB155556 B1555555 15555555
Some example of such graphisms (to be completed) :
29EB8 : Font
2AC66 : SEGA logo
6FF22 : intro art (2)
Nemesis compressed graphisms
Some art uses the well-known Nemesis compression scheme. You can use The Sega Compressor to decompress / recompress them.
Some example of such graphisms : see maps storage.
Font storage
Font patterns
The font is made of 192 8x8 patterns (I use the term 'pattern' to denote 8x8 objects stored in VRAM ; a "tile" is made of several patterns, see later), including :
- icons for battle windows, status, check boxes
- two complete alphabet sets, uppercase and lowercase
- some remaining of the japanese version, unused
Encoding
The encoding doesn't follow the pattern ordering. An actual character is in fact a 8x16 tile (2 patterns heigh) ; the upper pattern is always a space and the bottom one is the actual glyph (in order to allow interline space).
The correspondance is stored in a table starting at 0x12BC8. Each entry is 2 bytes, the first being always 0x26 (rank of the space in the font patterns ; this was used in the Japanese font to store the dakuten).
For example, the table starts with :
26 26 : so the character with code 0 is made of 2 stacked spaces,
26 97 : one space on top of the 0x97th font pattern, which represents the digit "0"
etc.
Special codes
- 0xBB : [character1] this code is replaced by the name of a character
- 0xBC : [character2] same thing (allows to have 2 characters names in the same sentence, for texts like "XXX heals YYY"
- 0xBD : [monster] replaced by a monster name
- 0xBE : [technique] replaced by a technique
- 0xBF : [item] replaced by an item name
- 0xC0 : [value] replaced by a numeric value
- 0xC1 : carriage return
- 0xC2 : [clear] clear current window
- 0xC3 : [wait] wait for a button to be pressed
- 0xC4 : [end] end of text
Interface
The basic interface system (blue windows and checkboxes with a red flashing cursor) is quite annoying to modify (for example with the aim to enlarge or rearrange windows, to allow longer words).
Windows
The windows information is stored as a table located at 0x13760.
Each entry is 8 bytes long, under the form :
- a word, of the form 0x4000 + y*128 + 2*x, where x and y are the coordinates (in 8x8 units) of the top-left corner of the window
- a long, which is an offset to the representation of the content of the window (see later)
- a byte, which is the width (in 8 units) of the window - 1 (including borders)
- a byte, which is the height (in 8 units) of the window - 1 (including borders)
The first entry of the table has no use as far as I can tell.
The offset to the representation of the window can be located in ROM, for windows whose content is always the same, or in RAM, for windows whose content varies (for example, character selection windows, item or technique selection).
Example : the main menu window has id 1. Its description starts at 0x13768 :
4082 00013B08 08 0A
0x4082 = 0x4000 + 1*128 + 1*2, so the window is located at (1, 1) with 8x8 units, that is to say at (8, 8) in pixels units. Its width is 9 x 8 = 72 pixels, and its height is 11 x 8 = 88 pixels, and the content of the window is located at ROM 0x13B08.
At 0x13B08, we find :
B9 B9 B9 B9 B9 B9 B9 ======= (upper border) B4 B5 2F 3A 2B 33 26 []ITEM ([] = checkbox) 26 26 26 26 26 26 26 (spaces to separate lines) B4 B5 39 3A 27 3A 2B []STATE 26 26 26 26 26 26 26 B4 B5 3A 2B 29 2E 26 []TECH 26 26 26 26 26 26 26 B4 B5 39 3A 38 34 2D []STRNG 26 26 26 26 26 26 26 B4 B5 2B 37 36 26 26 []EQP BE BE BE BE BE BE BE ======= (lower border)
Notes on RAM window : basic layout is stored in ROM (often, the checkboxes). Finding the address in ROM requires looking into the asm.
Menu
Editing a menu not only requires to edit the window attributes described above, but also the location of the flashing red rectangle (cursor). Sadly, these locations are hardcoded, that means you have to look into the code.
For example, the location of the cursor for the main menu described above is hardcoded at address 0xF7E0 by the lines:
move.w #$90,d1 move.w #$90,d2 bra.w setup_checkboxes
the position is given by $80 + actual position, here the actual position is (16, 16).
Some windowd with their ids and notes
(list to be completed)