Dump and rebuild dialog

[VariantXYZ]

[VariantXYZ]

1:5D28 is the start of the character tileset,
1:51EB actually sets up the call to load the tiles from it based on input characters

[VariantXYZ]

Text is copied into DE00 where it's eventually propagated through a ton of indirect branches/copies into WRAM and finally drawn.

This happens in 00:2082... which is of course copying it from somewhere else in RAM.

The routine that actually loads from ROM is 00:0426.

[VariantXYZ]

Never mind, it copies the entire text bank into WRAM apparently... which is crazy.

Starting at 7D:6BB2, it copies 0x027C characters to 0xD000.

[VariantXYZ]

01:57D7 is part of the routine that sets up the copy to WRAM...

There seems to be a table with 5 bytes of the form, the first set of text is at 79:4F03.

[Bank (relative to offset):1] ,[Source Address, relative to offset:2], [Size to copy:2]

This is based off another table, with the first text being at 4030 (03 0F, which gets added to 4000 later, for 4f03).

[VariantXYZ]

C0A5 is 'Currently Drawing'
C0A6 is some type of state, 01 when in a text box (1A if the box is still open, 12 otherwise)
C0A7 is another state, going from 02 -> 03 between when text is drawing and when it completes

Starting to think this is a scripting system where all strings are loaded as part of the script process.

[VariantXYZ]

This game operates similar to Link's Awakening, so using that as a reference, there may be a convenient dialog table like this: https://github.com/zladx/LADX-Disassembly/blob/main/src/data/dialogs/dialog_banks.asm

somewhere that we can setup automation to dump.

[VariantXYZ]

79:4000 contains a set of offsets (from 0x4000) to structures of the form

[Bank - 0x79:1][Source Address - 0x4000:2, Little Endian][Length:2, Big Endian]

These tables are used to copy data into 0xD000 which are then pulled in and eventually call DrawCharacter which eventually calls LoadTiles.

This is not all text, however, and I'm not sure how it actually gets selected.

[VariantXYZ]

Using simple dialogs to test, banks may be different, but 'events'/'scripts' are run based on CBC0 which point to the address of 'commands' to run.

Commands are in the form of [Command Byte:1][Parameters]([00?]).

For text, this is:

[0x82][Resource Index:2, Little Endian][00]

For 0x79, the table starting at 0x4000 of 2 byte pointers to structures of the form:

[Bank - 0x79:1][Source Address - 0x4000:2, Little Endian][Length:2, Big Endian]

which define which commands get written to 3:D000 and their necessary resources (including actual text).

The function 1A:4096 uses a 2 byte relative address stored at D001 (Little Endian) and the index provided by the command to generate a pointer to the actual text:

de (text) = [3:D001] + [1A:77EB] + ([[1A:77EB] + [3:D001] + [SP+8] << 2])
0xD2CB = 0x1B5 + 0xD000 + [0xD000 + 0x1B5 + (6 << 2)]

(SP+8 points to the command in question, which is pulled from CBC0)

With that we can parse bank 0x79 and dump the tables and command sets, and the associated text resources.

Banks 80 through FF seem empty, so we can probably take advantage of the space there.

[VariantXYZ]

1A:4022 sets the next command (called at 1A:7619). Looks like it gets parsed at 1A:762D.

D000 (the command set) is formatted as:

Header: [Unknown byte:1][Offset from start to resources:2]
Table of 2 byte offsets to start of 'scripts'

[VariantXYZ]

Command '2' draws text, and takes in Location:1 and ResourceOffset:1 as parameters.

[VariantXYZ]

Might make more sense to just write bytes out and naively take any 'known' command (since we really only care about 2 anyway) and parse it as a string for now.