0x9F091 - '1996 RADICAL DREAMERS PRESENTS' 0x9F10C - start of intro japanese text 0x9F1E3 - start of intro text after book opens up 0x9FC73 - start of in-game text in the kanji graphics, every 7F and every gap between FC and 40 are left blank, i assume because these values are system codes of some sort and would not work if used for a kanji. 01 is for subtrings - text for these start at E600 & stop at ECC1 - pointers for these start at E400 & end at E5FF... to get a location from on of these pointers, switch the low byte with the high byte, and add E600 to it. there are also some string entries at E200. so, what's at ECC2? there's some free space from 5A20 to 5FFF. if you want you can use it for substrings, but you'd have to see if the pointers are signed magnitude for the jumps. i don't think this is possible, actually, because you'd have to jump back more than 0x8000 bytes in order to get to it, which is more than signed jumping will allow with 16 bits. 02 ? 03 increases speed (any invalid kanji lookup results in a repeat display of the previous character in the buffer) the kanji thing seems more like a bytewise thing rather than a table lookup.. . it can access a range of things. STUB FORMAT: 00000 000 0000 0000 0000 0000 \ / \ / \ / \ / \ / | \ / \ / | (b) \ / \ / (a) \ / \ / | | (c) (d) (a) 5 BITS tells how many bytes are between the end of this stub end the beginning of the next stub. (b) 3 BITS add four to this number to see how many bytes will be read from the substring jump (if any - see c). (c) 8 BITS low byte of jump. if this and the next byte are both 00, there will be no jump. (d) 8 BITS high byte of jump. shift this number left 8 bits, then add it to (c), then (unknown) to get the number of bytes jumped. subtract these two bytes from the start of the stub, then continue printing from the end of the stub. the strings do not recurse - if a stub is found inside a stub jump, it will simply skip the stub entry and pretend it was a 00 stub. F9 : spacer byte (i don't know what it does really or when to use it over the other types i've seen). the next two numbers are usually 00 00. as far as i can tell, it's something the rom needs to check up on every so often (around every 0x10 bytes or so) or else it'll lock up. the next two bytes can either have 00 00, which is a blank 'do nothing' kind of filler, or contain two bytes of data which can fetch a substring, or perhaps do other things. the high 5 bits of this byte tell how many bytes there are till the next stub, counting from after the end of the current 3-byte stub. REMAINING BITS: 2 = unknown 1 = unknown 0 = unknown ie: F8 = 11111 000 = skip 0x1F bytes, ... FC = 11111 100 = skip 0x1F bytes, ... 6C = 01101 100 = skip 0x0D bytes, ... F9 = 11111 001 = skip 0x1F bytes, ... (karana" jump - 0x9FCBF) 0C = 00001 100 = skip 0x01 bytes, ... 78 = 01111 000 = skip 0x0F bytes, ... D9 = 11011 001 = 0x1B 63 : low byte decreased to 62: an extra character (hiragana ku) appeared before the normal link. there was a waitpad, but the next bit of text continued on the same line. this is because it's jumping to one less position (instead of 9F39D, it's 9F39C) and returning to one position earlier. increased to 64: one less character of the link was displayed. there was a delay after the link, but no waitpad. none on the next place it shoulda been, either. it's jumping one place after where it normally would (absolute, not relative). there's a delay because the new last substring byte it's reading is a delay byte, which takes the byte after it as an argument. so, the code for isn't recognised; it's become an argument for the delay. BITWISE EXAM OF MIDDLE BYTE - F9 xx 0A ($9FCBF): control (0x00) - 0000 0000 - 9F408 - 8B7 bytes back - OK BIT 0 (0x01) - 0000 0001 - 9F407 - 8B8 bytes back - OK BIT 1 (0x02) - 0000 0010 - 9F406 - 8B9 bytes back - OK BIT 2 (0x04) - 0000 0100 - 9F404 - 8BB? bytes back - ? BIT 3 (0x08) - 0000 1000 - 9F3FD - 8C2 bytes back - normal+4 - one number on this line is incorrect BITWISE EXAM OF LAST BYTE - F9 00 xx ($9FCBF): control (0x00) - 0000 0000 - BIT 0 (0x01) - 0000 0001 - BIT 1 (0x02) - 0000 0010 - BIT 2 (0x04) - 0000 0100 - BIT 3 (0x08) - 0000 1000 - F9 FF 01 ($9FCBF): F9 00 02 ($9FCBF): 0A : high byte $9F0E1: F9 2F 00 - 11111 001 0010 1111 0000 0000 jump back to $9F0C2 & print 5 bytes - 0x1F bytes back $9FCBF: F9 63 0A - 11111 001 0110 0011 0000 1010 jump back to $9F39D & print 5 bytes - 0x922 bytes backward changed 0A to 09, jumped to 9F498 - FB bytes after 9F39D changed 0A to 0B, jumped to 9F2A5 - F8 bytes before 9F39D changed 0A to 0C, jumped to 9F1AB - FA bytes before 9F2A5 changed 0A to 0D, jumped to 9xxxx - ?? unrecognisable "Dll" changed 63 to 62, jumped to 9F39E - 1 byte after 9F39D changed 63 to 00, jumped to 9F408 - 6B bytes after 9F39D changed 63 to 64, jumped to 9F39C - 1 byte before 9F39D $9FCE5: 78 21 00 - 01111 000 0010 0001 0000 0000 jump back to ??? & print out ??? bytes $9FCF7: 00 66 00 - 00000 000 0110 0110 0000 0000 jump back to $9FC8B & print out 7w/stub, 4w/o but after two bytes in that substring, there's a stub! wtf? 0x6c bytes backwards $9FCFA: D9 65 00 - 11011 001 0110 0101 0000 0000 jump back to $9FC93 & print out 5 bytes there 0x67 bytes backwards $9FD18: F8 B0 0C - 11111 000 1011 0000 0000 1100 jump back to ??? & print out 4 bytes 0A13=¤«¤é 0A=delay 0B=short delay 0C=unused (?) 12=delay 13=waitpad 1F=line break F90000=? FC0000=? 6C0000=? 8F97 -> BDF7 - subtract 2E60 i got bfa4