***MENU HALFWIDTH HACKS***
  file: 1
  0601ff78 (7F78): 7C 08 -> 7C 04
    - seems to take care of pretty much everything?
  
***MENU 8-BIT ENCODING HACK***
in "1":
  NOP the following:
    ; 16-bit char: fetch second byte
    ;0x00007CC4: 0x01DC	mov.b	@(r0,r13),r1
    ;0x00007CC6: 0x4918	shll8	r9
    ;0x00007CC8: 0x611C	extu.b	r1,r1
    ;0x00007CCA: 0x291B	or	r1,r9
    ;0x00007CCC: 0x7D01	add	#0x01,r13
    ; check whether to draw full or halfwidth
    ;0x00007CCE: 0x915F	mov.w	@(0x0C2,pc),r1	; 0x00007D90 (0x7FFF)
    ;0x00007CD0: 0x3916	cmp/hi	r1,r9
    ; branch if rawchar < 0x8000 (halfwidth)
    ;0x00007CD2: 0x8B01	bf	0x00007CD8
    - this method treats all text as 8-bit fullwidth, except for the "Lv"
      indicator (see below), which will be printed using the halfwidth font
      - when printing halfwidth text, the game automatically converts the input
        ASCII numbers to their actual indices in ASCII.FNT; I'm hoping it does
        the same for ":" and "/"
  modify 7F00: 00 00 81 97 -> 00 00 00 40
    - the game does not directly store the halfwidth "Lv" string used on
      the main menu and status screen, but instead special-cases character
      8197 (sjis "@") as a placeholder indicating this string should be drawn.
      since we're not using 16-bit encoding anymore, this changes the
      special character to 0040 (ascii "@")
  ------- don't do this one: we'll update this manually when the translated
    strings are imported
    modify 1921A: 81 97 25 32 64 00 -> 04 25 32 64 00 00
    - this updates the printstring for character levels to accommodate the
      change above ("%s＠%2d" -> "%s@%2d\x00")
      
***TITLE SCREEN HALFWIDTH HACKS***
(this uses an identical copy of the code from the overworld menus)
file: 0
  0601cf88 (4F88): 7C 08 -> 7C 04

***TITLE SCREEN 8-BIT ENCODING HACK***
(this uses an identical copy of the code from the overworld menus)
in "0":
  NOP the following:
    ; 16-bit char: fetch second byte
    0x00004CD4: 0x01DC	mov.b	@(r0,r13),r1
    0x00004CD6: 0x4918	shll8	r9
    0x00004CD8: 0x611C	extu.b	r1,r1
    0x00004CDA: 0x291B	or	r1,r9
    0x00004CDC: 0x7D01	add	#0x01,r13
    ; check whether to draw full or halfwidth
    0x00004CDE: 0x915F	mov.w	@(0x0C2,pc),r1	; 0x00004DA0 (0x7FFF)
    0x00004CE0: 0x3916	cmp/hi	r1,r9
    ; branch if rawchar < 0x8000 (halfwidth)
    0x00004CE2: 0x8B01	bf	0x00004CE8
  modify 4F10: 00 00 81 97 -> 00 00 00 40
    
***DIALOGUE HALFWIDTH HACKS***
  file: 1
  06028f6c (10f6c): E5 11 -> E5 09
    - change spacing between characters
  06028f9e (10f9e): 00 09 -> E5 11
    - fix interdependency between char spacing and height
  06028f5c (10f5c): E1 0F -> E1 1E (probably)
    - modify max characters per line
    
***DIALOGUE 8-BIT ENCODING HACK***
NOP the following in "1":
  ;0x00010F44: 0x4418	shll8	r4
  ;0x00010F46: 0x7201	add	#0x01,r2
  ;0x00010F4C: 0x72FF	add	#0xFF,r2
  ;0x00010F4E: 0x6120	mov.b	@r2,r1
  ;0x00010F52: 0x611C	extu.b	r1,r1
  ;0x00010F54: 0x341C	add	r1,r4

***BATTLE HALFWIDTH HACKS***
  file: 2
  0603DEB2 (25EB2): EB FF -> EB F7
    - magic descriptions, battle messages?
  0603e1d4 (261D4): EB FF -> EB F7
    - enemy names
  0603F3BE (273BE): EC FF -> EC F7
    - halves width of many static labels ("attack", "defend", etc.)
    - double "secondary spacing offset"?
    - why doesn't game like changing other spacing value? recycled init
      variables?
  0603f560 (27560): E1 FF -> E1 F7
    - character names on menu
      
***BATTLE 8-BIT ENCODING HACK***
in "2":
  NOP these:
    ; check if first read byte >= 0x80?
    ;0x0001BD44: 0x9143	mov.w	@(0x08A,pc),r1	; 0x0001BDCE (0x0080)
    ;0x0001BD46: 0x2149	and	r4,r1
    ;0x0001BD48: 0x2118	tst	r1,r1
    ; branch if >= 0x80, and shift byte to high position
    ;0x0001BD4A: 0x8F04	bf/s	0x0001BD56
    ;0x0001BD4C: 0x4418	shll8	r4
    ; if byte is < 0x80, it's assumed to be a space character (0x20), which for
    ; some reason are stored as 1-byte sequences instead of 2 bytes like
    ; everything else
    ; this code expands them to the proper 2-byte sequence, 0x2020
    ;0x0001BD4E: 0xE020	mov	#0x20,r0
    ;0x0001BD50: 0x240B	or	r0,r4
    ;0x0001BD52: 0xA003	bra	0x0001BD5C
    ; return value: 0x02
    ;0x0001BD54: 0xE902	mov	#0x02,r9
    ; get next character
    ;0x0001BD56: 0x6150	mov.b	@r5,r1
    ;0x0001BD58: 0x611C	extu.b	r1,r1
    ;0x0001BD5A: 0x241B	or	r1,r4
  and change these:
    1bf88: 71 02 -> 71 01
      - advance 1 byte instead of 2 when reading characters
    1c026: 78 02 -> 78 01
      - advance 1 byte instead of 2??
        not sure if this is necessary
  disable the weird shortcut optimization the game uses to look up characters
  from KANJI.FNT by making these replacements:
    ; hardcode number of characters to check to the size of the KANJI.FNT
    ; index (in bytes).
    ; this would search way past the end of the index, but that's OK since our
    ; changes guarantee all characters will be matched in the first 256
    ; entries.
    ; we can get away without an unsigned extension since the size of the index
    ; is 0C48
    0x0001BD9C: 0x6771 -> 0xD70D  mov.l @(0x038,pc),r7	; 0x0001BDD4 (0x06086248) 
    0x0001BD9E: 0x677D -> 0x6772	mov.l	@r7,r7
    0x0001BDA0: 0x0377 -> 0x6771	mov.w	@r7,r7
    ...
    ; hardcode the "base lookup index offset" is 00
    0x0001BDAC: 0x4621 -> 0xE600	mov #00,r6
    ...
    ; ensure the "base index address" is 0x002f2000
    0x0001BDBA: 0x6513 -> 0x351C  mov r1, r5
  adjust the widths of the text textures.
  this (a) allows longer strings to be displayed, and (b) prevents the game
    from crashing by overflowing its decompression buffers when long strings
    are displayed
    - for the latter, an increase of 2 characters is usually enough
    - 
060332FC (1b2fc) = generate battle string (full-width?)
the following specify widths for various battle strings:
*******************************************************************************
  magic descriptions, maybe other stuff
  increase these to at least 0x16
    0x00025EB8: 0xE712	mov	#0x12,r7
    0x00025EEA: 0xE712	mov	#0x12,r7
    0x00025F1C: 0xE712	mov	#0x12,r7
  
  0x000273C4: 0x67B3	mov	r11,r7     ; 2-character labels ("fight", etc.)?
    - this is tied to something else -- change this instead:
      0x000273C4: 0x67B3 -> 0xE704	mov	#04,r7
    - init to 060d6770
      - width = 060d6844
      - the offending call to 1b2fc is at 27494
        - r7 from r11
    - pointer after init: 06099e30
  0x000273F8: 0x67B3	mov	r11,r7      ; 2-character labels ("escape", etc.)?
      0x000273F8: 0x67B3 -> 0xE704	mov	#04,r7
  0x0002742A: 0x67B3	mov	r11,r7
      0x0002742A: 0x67B3 -> 0xE708	mov	#08,r7
  0x0002745C: 0x67B3	mov	r11,r7
      0x0002745C: 0x67B3 -> 0xE708	mov	#08,r7
  0x0002748E: 0x67B3	mov	r11,r7
      0x0002748E: 0x67B3 -> 0xE708	mov	#08,r7
  0x000274C0: 0xE704	mov	#0x04,r7    ; ?
  0x000274F0: 0xE705	mov	#0x05,r7
  0x00027566: 0x6723	mov	r2,r7
    - derived from the result of an earlier function; something dynamically
      generated, like magic descriptions?
  0x000275C4: 0xE70F	mov	#0x0F,r7
    - spell names on magic selection menu
  0x00027610: 0xE70F	mov	#0x0F,r7

  0x000261DA: 0xE712	mov	#0x12,r7
  0x0002620E: 0xE712	mov	#0x12,r7
  0x00026278: 0xE70B	mov	#0x0B,r7
  0x000262C2: 0xE726	mov	#0x26,r7
  0x0002632E: 0xE712	mov	#0x12,r7
  0x00026360: 0xE712	mov	#0x12,r7
  0x000263B0: 0xE708	mov	#0x08,r7
  0x000263DE: 0xE708	mov	#0x08,r7
  0x00026418: 0x67C3	mov	r12,r7
      0x00026418: 0x67C3 -> 0xE704	mov	#04,r7
    - from 0x0002639E: 0xEC02	mov	#0x02,r12
  
  0x00028586: 0xE704	mov	#0x04,r7
*******************************************************************************
  ***** old, don't use this -- causes problems
    and NOP this:
      0x0001B4D6: 0x4B01	shlr	r11
        - doubles size of the buffers used to decompress font characters;
          without this, long strings can overflow and crash the game
        - !!! this shouldn't be necessary once the translated strings are in
          and the texture widths have been updated appropriately; the game
          computes the size of the decompression buffer based on the size of
          the generated texture
        - this may not be necessary depending on how long the translated
          strings are
        - also, may have problems with stuff getting incorrectly overwritten,
          but ???

*** SPELL NAME EXTENSION ***
  * battle: in addition to the below, see 6x8_magic_battle.asm
    - the values below switch to a 6x8 layout
      todo: add a 6x8 font to ASCII.FNT, and set the font offset appropriately
      in 6x8_magic_battle.asm
      might not make a difference anyways)
      - 275C4: e7 0f -> e7 13
        - expand width of texture
      - 275BE: e1 ff -> e1 fd
        - reduce character spacing
      - 1F562: 71 0a -> 71 0e
        - increase amount of padding
      - 1F590: e1 0a -> e1 0e
        - increase amount of padding
  * overworld magic use menu: see 6x8_magic_use_overworld.asm
  * overworld status screen magic list: see 6x8_magic_status.asm
          
*** MISC BATTLE HACKS ***
  fix hardcoded size of が separating stat name from number in level-up stat
    increase messages (original format: {stat}が{amount}あがった
    2:212e9 is the x-offset from {stat} -- increase it to accomodate "increased
    by" or whatever the new message is
    ; x-offset of numbers from "ga"
    0x000212E8: 0x7D3D	add	#0x3D,r13
  increase hardcoded size of "attack" and "defend" dialog boxes to fit
  translated strings
    26BAE: E7 58 -> E7 60
  fix calculation of width of variable-size text windows to accommodate
  halfwidth hack
    regular magic target selection:
      change this:
        0x00023DBE: 0x4021	shar	r0
        0x00023DC0: 0x4008	shll2	r0
        0x00023DC2: 0x4008	shll2	r0
      to this:
        0x00023DBE: 0x4008	shll2	r0
        0x00023DC0: 0x4008	shll2	r0
        0x00023DC2: 0x4021	shar	r0
    union magic target selection:
      change this:
        0x0002457C: 0x4021	shar	r0
        0x0002457E: 0x4008	shll2	r0
        0x00024580: 0x4008	shll2	r0
      to this:
        0x0002457C: 0x4008	shll2	r0
        0x0002457E: 0x4008	shll2	r0
        0x00024580: 0x4021	shar	r0
      




***GENERAL***

  - 002f2000: KANJI.FNT
  - 0 code file: ?
  - 1: loaded to 06018000 on overworld?
  - 2: ?
  - 3: loaded to 002e0000 on overworld?
  - 4: ?
      - 

06033d04 -- print letter

060d843c
060e51c4
    
*** enemy stats ***
PLT.BIN: DC54 = enemy stat table?
  - 0x30-byte structs:
    - hp
    - attack
    - ...

002742b0 = pointer to enemy stat table, e.g. 00281e54
  - stat table = 0x30-byte structs
  - e.g. insect bolas at 00282214
    - this corresponds to e014 in PLT.BIN
  
*** escaping ***
takeaway: freeze 060862fc to 1 to always escape (even if you aren't trying to)
battle -- 060996e0 = battle state struct?
  - 0x00: turn number?
  - 0x14: if nonzero, battle is ending?
    - set to 01 for instant end
06099180 = ? struct
060991a0 = series of structs representing party state??
B696 = mark party members as escaped?
EF50 = called when setting party member action?
  - called at F074?
0608c900 = number of living/active party members?
060862fc is set to 1 if escape will be successful
  - apparently determined by call to 0602b800 (13800) at 06023612 (B612)
    - 13698: decide escape probabilities
      - default: 35%
      - if at least one party member is dead, 70%
      - if at least half the party is dead, 80%
      - if only one party member is alive, 90%
  - lock to 1 to always escape (even if it doesn't look like it)
  - at 060235b2 (b5b2)
  - at 06023618 (b618)

; this is called whenever a player or enemy decides on a "step"???
; r4 = actor num?
0x0000B008: 0x2FE6	mov.l	r14,@-r15
  
*** random encounters ***
takeaway: freeze 0605669c to 0 to disable random encounters
06056788 = ?
  - 56750 + 0x38
  - at 060271cc
280042
282872
060055bc
0605677a
0605692a
060a5200
060af810

0600750c
060077e8

1000 = mapnum?


06056750 = 0x40 byte structs giving each character's stats, etc.?
06056680 = indicators of present party members?

06056b38: pointer to "encounter slot tables"
  - three sections:
    - 0x8 bytes: enemy 1 type?
    - 0x8 bytes: enemy 2 type?
    - 0x10 bytes: nybble pairs indicating range of enemies of the given type
      that can appear in an encounter
      - e.g. 0x24 = 2 to 4 enemies?
      - each byte corresponds to the enemy type given 0x10 bytes earlier
0605669c: 1 = random encounters on, 0 = off
  - read at 0602718e (f18e) every step
060a1130 = encounter rate mitigation level?
  - higher value = lower encounter probabilities
  - code does not allow values higher than 0x32?
  - oh, this is always set to either elie's level or the average party
    level, divided by two
  - set at 060295ae after battle
    - by calling 06050210 = some system call?
06052844 = "encounter safety counter"
  - decrements each step -- random encounters will not occur until it
    reaches zero
  - reset to an apparently random value after battle
    - from 06018344 (344)
      - random number from 0 to 6, plus 5?
    irrelevant:
    - also from 002e4708
      - which gets this number from 25818000 -- CD-ROM registers???
        plus parameter r5
06052848: table for each enemy type giving probability of encounter
  - 1b each, 0x72 in total?
  - higher = greater chance of having an encounter
    - note: not probability of _being present_ in an encounter, probability
      of _the game triggering an encounter in the first place_
      i.e. higher values increase the encounter rate
060528BA = table of 0x68 16-bit "base encounter probabilities"
  - 3a8ba-3a98c
  - basically, every time the player moves a step (the distance moved when a
    directional button is tapped), the game generates a random(?) number and
    uses it as an index into this table. it then generates a random(?) number
    from 1 to 10000, and if it's lower than the value from the table, a random
    encounter occurs
  - this table is organized with lower probabilities first -- the "encounter
    mitigation level" at 060A1130 is subtracted from the randomly chosen
    index, thus reducing the probability of an encounter
  - zeroing all = no encounters, ffff all = always encounter (once safety
    counter at 06052844 has reached zero)
  - probabilities range from 200/10000 to 10000/10000
  - when the game rolls an encounter, it calculates a base index into this
    table given by:
      (((enemy1rate * enemy1count) + (enemy2rate * enemy2count))
        / (min_enemy1_count + min_enemy2_count + actual_total_enemies))
      + 0x34
      - (player_level / 2)
    note that (player_level / 2) is capped at 0x32
    
1:128b4 seems to generate a random number?

enemy hp:
  0607e052 <-- this
    0607e054 = max hp?
      - written at 2:06036590 (1e590)
  0608689e
  060b0700
  060b0704
  
enemy battle struct (ex. 0607e04c?)
  - 4b level?
  - 4b current hp
  - 4b max hp
  - 4b ??? -1
  - 4b ??? -1
  - 4b attack
  
060678b4

x: 7f 80 00 1f
y: fd 00 00 00
z: fa 00 00 00

temp = z
x = x ^ y = 8280001f
x = !x = 7D7FFFE0
T = !(x & 0x02) = 1
rotate T to high bit of y = fe8000000
rotate old low bit of y to temp = 3fc0000f
rotate old low bit of temp to z = fd000000
b = 71 + y = 
rotate: b = bfa00011
c = b ^ temp = 8060001e
x = c
y = y
z = z?

result:

x: 7d 60 00 1f
y: fe 80 00 00
z: fd 00 00 00
return 1f

next time:

x: 7f e0 00 1f
y: ff 40 00 00
z: fe 80 00 00
return 1f

x: 7f 58 00 1f
y: ff a0 00 00
z: ff 40 00 00
return 1f


***OVERWORLD DIALOGUE***


060a111c: text printing x-pos?
  - a111b = y-pos?
    - no?
  - a1113 = y-pos?
    - yes
  - 06052567?
  - initialized at 06028bb2
    - updated at 0602900e
    - read at 06028f5a, 06028f74, 06028fb6
      - 06028f5a: check for x-overflow (15 chars?) and wrap if so?
      - 06028f74: calculate position?
        - 06028f6c: width of character?
      - 06028f96: every 1st char?
        - problem is that the 0x11 from r5 (at 06028f6c) is recycled as
          height of the character (checked at 06028fae)
          - solution: overwrite nop at 06028f9e w/ mov #17,r5 (e5 11)
          - so:
            06028f6d (10f6d): 11 -> 09
            06028f9e (10f9e): 00 09 -> e5 11
            
            - this code is located in "1"
              - 06028f6e = 10f6e
                - load addr = 06018000
                - but not all code!
      - 06028fb8: every 2nd char? 
        - 06028fbc: ?
          - 
          
060185ac: call 06028dac (print or prep character?)
  - 06028dac (10dac):
    - 
    
06028e98 (10e98): read next byte from dialogue text script
  - if byte is >= 0x20, it's assumed to be the first byte of a 2-byte
    printable character
    - jumps to handler at 06028f44 (10F44)
  - if byte is < 0x20, it's a control opcode(?)
    - opcodes 0x0e? to 0x1F don't exist and are simply skipped over?
    - opcode number is used as index into 2b offset table at 10EC0 --
      add offset to table address to get handler to jump to?
      - most opcodes are ignored and just jump back to the "next byte" routine
      - handled opcodes:
        - 00: 10F14
          - end of text
        - 08: 10F1C
          - end current text box, wait for player input
        - 0a: 10F24
          - newline
        - 0c: 10F30
          - ?
        - 0d: 10F3C
          - ?

; fetch 2-byte raw character literal
; shift the first character to the high position
;
; NOP
;0x00010F44: 0x4418	shll8	r4

; pre-emptively move the global text pointer to its next position
;
; NOP
;0x00010F46: 0x7201	add	#0x01,r2

0x00010F48: 0xD041	mov.l	@(0x108,pc),r0	; 0x00011050 (0x0601FA10) 
0x00010F4A: 0x2822	mov.l	r2,@r8

; now move back to the current position and read the low byte of the
; character
;
; NOP
;0x00010F4C: 0x72FF	add	#0xFF,r2
;0x00010F4E: 0x6120	mov.b	@r2,r1

0x00010F50: 0x65E3	mov	r14,r5

;
; NOP
;0x00010F52: 0x611C	extu.b	r1,r1

; combine low and high bytes into a word
;
; NOP
;0x00010F54: 0x341C	add	r1,r4


          
06028f5d: max characters per line before auto-wrapping

change spacing between characters:
  06028f6d (10f6d): 11 -> 09
fix interdependency between char spacing and height:
  06028f9e (10f9e): 00 09 -> E5 11
modify max characters per line:
  06028f5d (10f5d): 0F -> 1E (probably)

related:
  00282827
  0028285b
  0028288f
  06004003 - global frame counter
  060522f3 - 2b?
  06052567 - 2b?
  06056693
  060566a8 = 4b script pointer for text?
    - written at 06023c7a
  060a111f
  060a26c3
  060ffc67
  
  
***BATTLE***
  - 1B96C: primary text drawing routine
  print struct format:
    a0 = pointer to raw string to print
    c0 = decompression buffer pointer???
    c8 = flag? wrapping? 8x8?? 06033ce8
    d4 = width in characters??? (334b6)
    d8 = ?
    dc = spacing (negative)
    e4 = spacing (positive)
    e8 = number of decompression chars????
    ec = ? (1B8F4)
    f0 = x-position?
    fc = ? (1bb58)

06032540: THISISDUMMYSPACE
  - creates a 16-byte buffer used to generate spell name/cost strings
  - copied to ex. 060dae20
  
260D4 -- call that generates battle textures?

0603e0d4: call to 0603f512 that sets up most battle text?
  - but magic descriptions and battle messages are already done??
    
0605F594 (battle): インセクトボラス
  - this name is copied to 060999f0?
      - read at 060551fe (string length finder?)
    - called at 0603f74c
      - do not nop call
    - then calls 060550b8
    - eventually, calls 06033eac (at 0603f814?)
      - this clears existing text off the screen
    - call 06038114
      - ? ret freezes
    - 060551f8 (at 0603f74c)
    - 060550b8 (at 0603f75a)
  - at battle start, all of that (0603f684) is called at 0603e21c
  
  - this whole routine is called at 060340aa at battle start
    - then 06042c04
    - rets from 060336f2
  060551f8 = generic text drawing routine (battle)
06034060 = draw character status boxes?
  - called at 060336f2
  
060340a8: draw battle text?
  - 060551f8: compute string length?
  
06034060
  - from 060334ac
  
060340d6: call 06033fac
  - this is called at 0603f82e
    - part of routine at 06038114?
  - 06033fac: ret for no battle text
  
060334b0: ?

0603f684: draw enemy name? -- called at 0603e21c
  - 0603f6a8: call 06035b88
  - 0603f6c0: call 0605b298 (can loop)
  - 0603f74c: call to 060551f8 to determine string length(?)
  - 0603f75a: ? call 060550b8
    - rts of called routine causes weird behavior
    - nop of call causes odd artifacting
  - 0603f7be: check if only 1 enemy, so no quantity???
  - 0603f814: call 06033eac (clear text?)
  - 0603f82e: call 06038114, probably to draw text
  
06038114: draw some kinds of text???
  - enemy names, end of battle messages (except names and numbers)
  - but not labels, etc.
  - first call: 0603f82e (enemy name)
  - :
    - 06038126: call 060336e8
    - 06038130: call 06033714 (this is called constantly)
    - 06038136: call 06033738
    - 0603813C: call 06033ec0
    - 06038142: call 0603396c
      ------ THIS THIS THIS
    - 06038148: call 06033e94
    
0603e222: call 060328a4
  - ?
  
heh, THISISDUMMYSPACE

  
0603396c: PRINT THE TEXT
  - at time function is called (ex. 0603f512), text printing struct is
    already loaded?
    r4 = pointer?
    - 0603f512 (battle setup?) is part of 0603f384 -- called at 0603e0d4
      - bingo? at 0603f3b6, spacing1 = #17?
  - 060339da: jump to something
    - 060339fe for something
  - 06033984: nop for no text
    - 0603385C
    - doesn't appear to do much?
  - 06033998: prep string for printing by converting from raw encoding
              to printable?
              nop for freeze
    - 06033924: call 06033f5c?
    - part of a loop that does ???
    - r12 = terminator????
    - r11 = ? add a0?
      - e.g. 060d4f34
    - r10 = ? constant(?) address, add charcount * 4 to get ???
      - 060ffb40
    - r9 = character count?
      - 06033f6c: call 06033d04
        - !!!at 06033d5c, r4=8343/イ !!!
        - from r5 (060dfa39)
        - 06033db8: call 06032120
        - 06033d78: read from low work ram (002ff0a8) = 00 28
        - 06033d8c: search loop through part of low work ram??
          - looking for characters??
  - 06033b62 (1bb62): call 06032296 (1a296) -- nop for no text (except numbers)
    - get a character graphic?
    - always called twice, if at all?
      - could this be regular text + generated outline?
  - 06033c2c: nop for no text
  - 06033c34: nop for no text
  
2:1B924 = 06033924
  - diff = 18000
  
OK:
  - 06033c3c (1BC3C): printing characters -- we're looking up spacing info from
    the printing struct?
    part of routine at 0603396C (1B96C)
    r8 = pointer to printing struct (dynamically allocated)
      - r8 + E4 = char spacing 1? (positive)
      - r8 + DC = char spacing 2? (negative)
      - r8 + F0 = x-position?

060d7690 = ????
06033d04 = routine
fails after drawing ？？？？ and before エリー
  - エリー : d7a28
  - call to draw: 06033998?
 - battle won string: copied to e0d70
  - from 060325c4 (1a5c4)
    - read at 0603402e (1c02e) -- that other character check routine
    - read at 06033cd6 (1bcd6) -- that character check routine
    - read at 060551fe (3d1fe) -- strlen
    - read at 06034010 (1c010) -- copy to buffer (ex. 060e0d40)
      - length for purpose of calculating dialogue box size is computed
        at some point after 060340d6
        - copied buffer is read at:
          - 06033d12 (in character printing routine 1bd04)
            - this one?
            - call is at 06033f6c (1bf6c)
              
          - 060551fe
1bdf2: check next character for 1b, 2b, ???

0603396c (1b96c) = function that prints a character string
  - at 0603399c, r14 = pointer to prepped string
example decompression buffer: 060d73d4
  - 0x66 bytes?
  - cleared at 06032110 (1a110) (memclr)
    - called at 06033612 (1b612)

**** 0x0001C026: 0x7802	add	#0x02,r8
  -- should this be 1 instead?
  
06034c08: エリー (name on menu?)
  - the call to 0603f684 (27684) at 0603e21c causes the freeze
    - call to 06038114 (20114) at 0603f82e
      - call to 060336e8 (1b6e8) at 06038126
        - call to 06034060 (1c060) at 060336f2
          - call to 06042c38 (3d1f8 -- strlen) at 060340a4
0605d31c: エリー (?)

5f594
5f5f8

1b4b6: 02 2E -> E2 0B
  - this actually works!!
  - force all generated text textures to be 11 characters wide
  
4601c|単体・炎の攻撃
  - read at 0603402e (1c02e)
  

0603e322 (26322): ???
  - not a print struct init -- this is part of the routine that
    prints battle labels
  
level up stat printing
  06038174 (20174)
    - called at 060392f4 (212f4), in 06039258 (21258)
      - called every frame, but this logic isn't always executed?
        - critical juncture is 06039270
      - called at 06033126, in 060330fc (every frame?)
        - called at 06039b2a, in 06039b1e
          - called at 0603a04e, in 0603a030?
          
2:45d28: ﾌﾚｲ
  - read at 060551fe (strlen)
  - automatically padded and combined with MP cost (14 chars total)
    - prepared string ends up at ex. 060e715c
      - written at 06034018 (1c018)
        - from buffer at ex. 06099b98
        - each party member's spells are loaded to this area in order
          when their turn arises
          - written at 06018086 (zeroing)
          - at 060552d4 (3d2d4)
            - part of 060552c8 (strcpy), called at 0603754a (1f54a)
  - 9e210 = table of 0x78 byte structs??
; call 228dc -- spell name gets read in here
0x00026E16: 0x400B	jsr	@r0

275c4: width of spell name texture in chars (0f)
275BE: negative spacing in spell names (ff)
1F562, 1F590: number of spell name/cost separation chars (0a)
  - 6x8 = 14 chars
    - 275C4: e7 0f -> e7 13
    - 275BE: e1 ff -> e1 fd
    - 1F562: 71 0a -> 71 0e
    - 1F590: e1 0a -> e1 0e
    - assume 6x8 font will start (numbers) at position 0x86 in ASCII.FNT
  - 5x8 = 17 chars
    - crank up width of texture:
      275C4: 0xE70F	mov	#0x0F,r7 -> E7 13 (or so)

; prep string for printing?
; looks up stuff from tables and puts on stack?
; called at 06033998 (1B998)
; this is 060338e0
0x0001B8E0: 0x2F86	mov.l	r8,@-r15
0x0001B8E2: 0x2F96	mov.l	r9,@-r15
0x0001B8E4: 0x2FA6	mov.l	r10,@-r15
0x0001B8E6: 0x2FB6	mov.l	r11,@-r15
0x0001B8E8: 0x2FC6	mov.l	r12,@-r15
0x0001B8EA: 0x2FD6	mov.l	r13,@-r15
0x0001B8EC: 0x2FE6	mov.l	r14,@-r15
0x0001B8EE: 0x4F22	sts.l	pr,@-r15
0x0001B8F0: 0x6EF3	mov	r15,r14
0x0001B8F2: 0x6B43	mov	r4,r11
0x0001B8F4: 0x9034	mov.w	@(0x06C,pc),r0	; 0x0001B960 (0x00EC)
0x0001B8F6: 0x00BE	mov.l	@(r0,r11),r0
0x0001B8F8: 0x8802	cmp/eq	#0x02,r0
0x0001B8FA: 0x8D0A	bt/s	0x0001B912
0x0001B8FC: 0x6A53	mov	r5,r10
0x0001B8FE: 0xE101	mov	#0x01,r1
0x0001B900: 0x2A12	mov.l	r1,@r10
0x0001B902: 0x7A04	add	#0x04,r10
0x0001B904: 0x952D	mov.w	@(0x05E,pc),r5	; 0x0001B962 (0x00A0)
0x0001B906: 0x35BC	add	r11,r5
0x0001B908: 0xD116	mov.l	@(0x05C,pc),r1	; 0x0001B964 (0x06033F5C) 
0x0001B90A: 0x410B	jsr	@r1
0x0001B90C: 0x66A3	mov	r10,r6
0x0001B90E: 0xA01E	bra	0x0001B94E
0x0001B910: 0x6FE3	mov	r14,r15
0x0001B912: 0xE901	mov	#0x01,r9
0x0001B914: 0xDD13	mov.l	@(0x050,pc),r13	; 0x0001B964 (0x06033F5C) 
0x0001B916: 0xDC14	mov.l	@(0x054,pc),r12	; 0x0001B968 (0x80000000) 
0x0001B918: 0x6893	mov	r9,r8
; r9 = charnum
; r10 = ? stack addr
; r11 = ?
; r12 = terminator flag?
; charnum * 4
0x0001B91A: 0x4808	shll2	r8
0x0001B91C: 0x66A3	mov	r10,r6
0x0001B91E: 0x368C	add	r8,r6
0x0001B920: 0x951F	mov.w	@(0x042,pc),r5	; 0x0001B962 (0x00A0)
0x0001B922: 0x35BC	add	r11,r5
; ! 06033924 -- call 1bf5c -- character lookup?
0x0001B924: 0x4D0B	jsr	@r13
0x0001B926: 0x64B3	mov	r11,r4
0x0001B928: 0x60A3	mov	r10,r0
; ex. 060ffb68 + (charnum * 4)
; get character graphic address
0x0001B92A: 0x018E	mov.l	@(r0,r8),r1
0x0001B92C: 0x21C9	and	r12,r1
0x0001B92E: 0x2118	tst	r1,r1
; check for terminator (high bit set?)
0x0001B930: 0x8B02	bf	0x0001B938
0x0001B932: 0x7901	add	#0x01,r9
0x0001B934: 0xAFF1	bra	0x0001B91A
0x0001B936: 0x6893	mov	r9,r8
; done -- all characters ready to draw
; r9 = number of characters + 1?
; r10 = pointer to graphic pointer sequence (-4?)
0x0001B938: 0x6093	mov	r9,r0
; branch if there are no characters
0x0001B93A: 0x8801	cmp/eq	#0x01,r0
0x0001B93C: 0x8D06	bt/s	0x0001B94C
; write number of characters at start of string
0x0001B93E: 0x2A92	mov.l	r9,@r10
0x0001B940: 0x79FF	add	#0xFF,r9
0x0001B942: 0x2A92	mov.l	r9,@r10
; subtract 1 from A0 in print struct??
0x0001B944: 0x900D	mov.w	@(0x01E,pc),r0	; 0x0001B962 (0x00A0)
0x0001B946: 0x01BE	mov.l	@(r0,r11),r1
0x0001B948: 0x71FF	add	#0xFF,r1
0x0001B94A: 0x0B16	mov.l	r1,@(r0,r11)
0x0001B94C: 0x6FE3	mov	r14,r15
0x0001B94E: 0x4F26	lds.l	@r15+,pr
0x0001B950: 0x6EF6	mov.l	@r15+,r14
0x0001B952: 0x6DF6	mov.l	@r15+,r13
0x0001B954: 0x6CF6	mov.l	@r15+,r12
0x0001B956: 0x6BF6	mov.l	@r15+,r11
0x0001B958: 0x6AF6	mov.l	@r15+,r10
0x0001B95A: 0x69F6	mov.l	@r15+,r9
0x0001B95C: 0x000B	rts
0x0001B95E: 0x68F6	mov.l	@r15+,r8

; r5 = pointer to pointer to position in printstring?
0x0001BF5C: 0x2F86	mov.l	r8,@-r15
0x0001BF5E: 0x2F96	mov.l	r9,@-r15
0x0001BF60: 0x2FE6	mov.l	r14,@-r15
0x0001BF62: 0x4F22	sts.l	pr,@-r15
0x0001BF64: 0x6EF3	mov	r15,r14
0x0001BF66: 0x6953	mov	r5,r9
0x0001BF68: 0x6863	mov	r6,r8
0x0001BF6A: 0xD00E	mov.l	@(0x03C,pc),r0	; 0x0001BFA4 (0x06033D04) 
; call 1bd04 -- look up character and get address
0x0001BF6C: 0x400B	jsr	@r0
0x0001BF6E: 0x6592	mov.l	@r9,r5
; check return value
0x0001BF70: 0x8801	cmp/eq	#0x01,r0
; ?????????
0x0001BF72: 0x8D0A	bt/s	0x0001BF8A
0x0001BF74: 0xE101	mov	#0x01,r1
0x0001BF76: 0x3012	cmp/hs	r1,r0
0x0001BF78: 0x8F04	bf/s	0x0001BF84
0x0001BF7A: 0x8802	cmp/eq	#0x02,r0
0x0001BF7C: 0x8909	bt	0x0001BF92
0x0001BF7E: 0x6FE3	mov	r14,r15
0x0001BF80: 0xA00C	bra	0x0001BF9C
0x0001BF82: 0x4F26	lds.l	@r15+,pr
; branch taken when 1bd04 returns 0?
; advance getpos by 2
0x0001BF84: 0x6192	mov.l	@r9,r1
0x0001BF86: 0xA006	bra	0x0001BF96
0x0001BF88: 0x7102	add	#0x02,r1
0x0001BF8A: 0x6282	mov.l	@r8,r2
0x0001BF8C: 0xD106	mov.l	@(0x01C,pc),r1	; 0x0001BFA8 (0x80000000) 
0x0001BF8E: 0x221B	or	r1,r2
0x0001BF90: 0x2822	mov.l	r2,@r8
0x0001BF92: 0x6192	mov.l	@r9,r1
0x0001BF94: 0x7101	add	#0x01,r1
; store new printpos
; to ex. 060d726c?
0x0001BF96: 0x2912	mov.l	r1,@r9
0x0001BF98: 0x6FE3	mov	r14,r15
0x0001BF9A: 0x4F26	lds.l	@r15+,pr
0x0001BF9C: 0x6EF6	mov.l	@r15+,r14
0x0001BF9E: 0x69F6	mov.l	@r15+,r9
0x0001BFA0: 0x000B	rts
0x0001BFA2: 0x68F6	mov.l	@r15+,r8

; read the next raw character for printing
;
; r5 = source character data
;
; return codes:
;   0: indicates 2 bytes were read?
;   1: end of string?
;   2: indicates 1 byte was read?
0x0001BD04: 0x2F86	mov.l	r8,@-r15
0x0001BD06: 0x2F96	mov.l	r9,@-r15
0x0001BD08: 0x2FE6	mov.l	r14,@-r15
0x0001BD0A: 0x4F22	sts.l	pr,@-r15
0x0001BD0C: 0x6EF3	mov	r15,r14
0x0001BD0E: 0x6243	mov	r4,r2
0x0001BD10: 0x6863	mov	r6,r8
; fetch first byte
0x0001BD12: 0x6154	mov.b	@r5+,r1
0x0001BD14: 0x641C	extu.b	r1,r4
0x0001BD16: 0x6043	mov	r4,r0
; branch if byte == 0x0E
0x0001BD18: 0x880E	cmp/eq	#0x0E,r0
0x0001BD1A: 0x8D07	bt/s	0x0001BD2C
; default return value: 0x00
0x0001BD1C: 0xE900	mov	#0x00,r9
; branch if byte is > 0x0E
0x0001BD1E: 0xE10E	mov	#0x0E,r1
0x0001BD20: 0x3416	cmp/hi	r1,r4
0x0001BD22: 0x8906	bt	0x0001BD32
0x0001BD24: 0xD12A	mov.l	@(0x0AC,pc),r1	; 0x0001BDD0 (0x0605FE88) 
0x0001BD26: 0x6112	mov.l	@r1,r1
; branch if the static variable at 0605fe88 is zero
;   -- this is set after battle at 06033a14
0x0001BD28: 0x2118	tst	r1,r1
0x0001BD2A: 0x8B02	bf	0x0001BD32
; first byte is 0x0E, or 0605fe88 is nonzero -- skip printing??
0x0001BD2C: 0x2842	mov.l	r4,@r8
0x0001BD2E: 0xA047	bra	0x0001BDC0
; return value: 0x01
0x0001BD30: 0xE001	mov	#0x01,r0
; check if some value in print struct? is 0x01
; this seems to be set for printing 8x8 text?
0x0001BD32: 0x904B	mov.w	@(0x09A,pc),r0	; 0x0001BDCC (0x00C8)
0x0001BD34: 0x002E	mov.l	@(r0,r2),r0
0x0001BD36: 0x8801	cmp/eq	#0x01,r0
0x0001BD38: 0x8B04	bf	0x0001BD44
; executed if checked value is 0x01 -- skips actual graphic lookup?
0x0001BD3A: 0x4408	shll2	r4
0x0001BD3C: 0x344C	add	r4,r4
0x0001BD3E: 0x2842	mov.l	r4,@r8
0x0001BD40: 0xA03E	bra	0x0001BDC0
; return value: 0x02
0x0001BD42: 0xE002	mov	#0x02,r0
; check if first read byte >= 0x80?
0x0001BD44: 0x9143	mov.w	@(0x08A,pc),r1	; 0x0001BDCE (0x0080)
0x0001BD46: 0x2149	and	r4,r1
0x0001BD48: 0x2118	tst	r1,r1
; branch if >= 0x80, and shift byte to high position
0x0001BD4A: 0x8F04	bf/s	0x0001BD56
0x0001BD4C: 0x4418	shll8	r4
; if byte is < 0x80, it's assumed to be a space character (0x20), which for
; some reason are stored as 1-byte sequences instead of 2 bytes like
; everything else
; this code expands them to the proper 2-byte sequence, 0x2020
0x0001BD4E: 0xE020	mov	#0x20,r0
0x0001BD50: 0x240B	or	r0,r4
0x0001BD52: 0xA003	bra	0x0001BD5C
; return value: 0x02 (1 byte read)
0x0001BD54: 0xE902	mov	#0x02,r9
; get next character
0x0001BD56: 0x6150	mov.b	@r5,r1
0x0001BD58: 0x611C	extu.b	r1,r1
0x0001BD5A: 0x241B	or	r1,r4
; at this point, r4 = raw id of char to print
; now look up its graphic in KANJI.FNT
0x0001BD5C: 0xD11D	mov.l	@(0x078,pc),r1	; 0x0001BDD4 (0x06086248) 
0x0001BD5E: 0x6212	mov.l	@r1,r2
0x0001BD60: 0x6121	mov.w	@r2,r1
0x0001BD62: 0x611D	extu.w	r1,r1
0x0001BD64: 0x6013	mov	r1,r0
0x0001BD66: 0x4001	shlr	r0
0x0001BD68: 0x70FF	add	#0xFF,r0
0x0001BD6A: 0x4008	shll2	r0
0x0001BD6C: 0x300C	add	r0,r0
0x0001BD6E: 0x4008	shll2	r0
0x0001BD70: 0x301C	add	r1,r0
0x0001BD72: 0x6703	mov	r0,r7
0x0001BD74: 0x372C	add	r2,r7
0x0001BD76: 0xE300	mov	#0x00,r3
; the above code uses some crazy backwards method of deriving a pointer
; to 002F2000, the location of KANJI.FNT, and adding D0A8 to it to get
; the location of the footer
; read the number of footer entries
0x0001BD78: 0x012D	mov.w	@(r0,r2),r1
0x0001BD7A: 0x611D	extu.w	r1,r1
; subtract 2
0x0001BD7C: 0x71FE	add	#0xFE,r1
; branch if all entries checked
0x0001BD7E: 0x3313	cmp/ge	r1,r3
0x0001BD80: 0x8D0C	bt/s	0x0001BD9C
0x0001BD82: 0x6673	mov	r7,r6
; get the next entry (r1)
0x0001BD84: 0x6171	mov.w	@r7,r1
0x0001BD86: 0x621D	extu.w	r1,r2
0x0001BD88: 0x72FE	add	#0xFE,r2
0x0001BD8A: 0x7602	add	#0x02,r6
0x0001BD8C: 0x6161	mov.w	@r6,r1
0x0001BD8E: 0x611D	extu.w	r1,r1
; branch if target character is less than the entry
0x0001BD90: 0x3412	cmp/hs	r1,r4
0x0001BD92: 0x8B03	bf	0x0001BD9C
; increment entry number
0x0001BD94: 0x7301	add	#0x01,r3
; branch if we haven't reached the last entry
0x0001BD96: 0x3323	cmp/ge	r2,r3
0x0001BD98: 0x8FF8	bf/s	0x0001BD8C
0x0001BD9A: 0x7602	add	#0x02,r6
;     0x0001BD9C: 0xD70D  mov.l @(0x038,pc),r7	; 0x0001BDD4 (0x06086248) 
;     0x0001BD9E: 0x6772	mov.l	@r7,r7
;     0x0001BDA0: 0x6771	mov.w	@r7,r7
;     ;0x0001BDA2: 0x677D	extu.w	r7,r7
; matching entry found, or failed
; move entry preceding this one to r7
0x0001BD9C: 0x6771	mov.w	@r7,r7
0x0001BD9E: 0x677D	extu.w	r7,r7
; multiply by entry index number
0x0001BDA0: 0x0377	mul.l	r7,r3
; get result
0x0001BDA2: 0x061A	sts	macl,r6
0x0001BDA4: 0x6163	mov	r6,r1
; get highest bit as lowest
0x0001BDA6: 0x4104	rotl	r1
0x0001BDA8: 0x0129	movt	r1
; add to result
0x0001BDAA: 0x361C	add	r1,r6
; divide by 2
;    0x0001BDAC: 0xE600	mov #00,r6
0x0001BDAC: 0x4621	shar	r6
0x0001BDAE: 0xD109	mov.l	@(0x028,pc),r1	; 0x0001BDD4 (0x06086248) 
0x0001BDB0: 0x051A	sts	macl,r5
0x0001BDB2: 0x355C	add	r5,r5
; look up load address of KANJI.FNT from 06086248 (6e248),
; and add result of above operations to it
0x0001BDB4: 0x6112	mov.l	@r1,r1
0x0001BDB6: 0xD008	mov.l	@(0x024,pc),r0	; 0x0001BDD8 (0x06032120) 
; call 1a120 (get compressed character graphic address)
; nop = garbage is drawn
0x0001BDB8: 0x400B	jsr	@r0
;    0x0001BDBA:  0x6513   mov r1, r5
0x0001BDBA: 0x351C	add	r1,r5
; save address (ex. 060ffb6c)
0x0001BDBC: 0x2802	mov.l	r0,@r8
0x0001BDBE: 0x6093	mov	r9,r0
0x0001BDC0: 0x6FE3	mov	r14,r15
0x0001BDC2: 0x4F26	lds.l	@r15+,pr
0x0001BDC4: 0x6EF6	mov.l	@r15+,r14
0x0001BDC6: 0x69F6	mov.l	@r15+,r9
0x0001BDC8: 0x000B	rts
0x0001BDCA: 0x68F6	mov.l	@r15+,r8

; does a linear search of KANJI.FNT for a character?
;
; r4 = target character
; r5 = base address (in KANJI.FNT) at which to start searching??
; r6 = "base offset"
; r7 = max number of chars to check?
;c48 2a read 0603258c write 060d7544 correct 1188
; returns something in r0
0x0001A120: 0x4F12	sts.l	macl,@-r15
0x0001A122: 0x6153	mov	r5,r1
0x0001A124: 0x461A	lds	r6,macl
0x0001A126: 0x255A	xor	r5,r5
; get address of KANJI.FNT (002f2000)
0x0001A128: 0xD009	mov.l	@(0x028,pc),r0	; 0x0001A150 (0x06086248) 
0x0001A12A: 0xD60A	mov.l	@(0x02C,pc),r6	; 0x0001A154 (0x0000FFFF) 
0x0001A12C: 0x6302	mov.l	@r0,r3
; get number of index entries
0x0001A12E: 0x6231	mov.w	@r3,r2
0x0001A130: 0x6063	mov	r6,r0
; get previous entry and next as a long
0x0001A132: 0x6316	mov.l	@r1+,r3
; mask off low word
0x0001A134: 0x2039	and	r3,r0
; branch if this is the target character
0x0001A136: 0x3040	cmp/eq	r4,r0
0x0001A138: 0x8D0E	bt/s	0x0001A158
; check high word
0x0001A13A: 0x4329	shlr16	r3
0x0001A13C: 0x3340	cmp/eq	r4,r3
; branch if target
0x0001A13E: 0x8D14	bt/s	0x0001A16A
0x0001A140: 0x7501	add	#0x01,r5
; loop until max number of entries checked
0x0001A142: 0x3570	cmp/eq	r7,r5
0x0001A144: 0x8FF5	bf/s	0x0001A132
0x0001A146: 0x6063	mov	r6,r0
; character not found: return address of first character in font
0x0001A148: 0x6023	mov	r2,r0
0x0001A14A: 0x000B	rts
0x0001A14C: 0x4F16	lds.l	@r15+,macl

0x0001A14E: 0x0009	nop
0x0001A150: 0x0608	.long	0x06086248	; 0x0001A128
0x0001A152: 0x6248	
0x0001A154: 0x0000	.long	0x0000FFFF	; 0x0001A128
0x0001A156: 0xFFFF	
; character found (low position)
; add base offset to index
0x0001A158: 0x011A	sts	macl,r1
0x0001A15A: 0x351C	add	r1,r5
; multiply by 0x40 (*2 because the computed index is half of the actual,
; and *0x20 for the size of each compressed character)
0x0001A15C: 0x4508	shll2	r5
0x0001A15E: 0x4508	shll2	r5
0x0001A160: 0x4508	shll2	r5
; add sizse of index
0x0001A162: 0x352C	add	r2,r5
0x0001A164: 0x4F16	lds.l	@r15+,macl
0x0001A166: 0x000B	rts
0x0001A168: 0x6053	mov	r5,r0
; character found (high position)
0x0001A16A: 0x75FF	add	#0xFF,r5
0x0001A16C: 0x011A	sts	macl,r1
0x0001A16E: 0x351C	add	r1,r5
0x0001A170: 0x4500	shll	r5
0x0001A172: 0x75FF	add	#0xFF,r5
0x0001A174: 0x4508	shll2	r5
0x0001A176: 0x4508	shll2	r5
0x0001A178: 0x4500	shll	r5
0x0001A17A: 0x352C	add	r2,r5
0x0001A17C: 0x4F16	lds.l	@r15+,macl
0x0001A17E: 0x000B	rts
0x0001A180: 0x6053	mov	r5,r0


***OVERWORLD MENUS***

- 0602C330: システム
  - read at 0603d198
    - called at 0604ab5e (32b5e)
      - is this possibly part of 0604a9c8?
  - also at 0604e878
    - strlen?
  - this gets copied to 060fed78
    - read at 0601fbce
      - something something, 060314ca?
        - works fine when nopped, so no
- 0604a9c8
  - this seems to be called once per printed string?
  - called from 0604a950
    - which is part of 0604a940?, called at 0604a5b6
      - part of 0604a590, called at 06029e1c
  - ret for no text (menu and status)
  - this is at least prepping the text somehow, but probably not printing?
  - r4 = ?
  - r5 = address to copy prepped(?) string to?
  - r6 = address of source string
  - r7 = ?
    - call 0604ce88
    - at 0604ab5e, call 0604d180 (in loop, once per byte(?) in input?)
    - can jump to 0604c860 (34860)
      - at 0604c872, call 0604A870
        - this isn't called for e.g. %3d
        - calls 0604caa0
          - calls 0604e840
            - this copies the source string to r2?
            - e.g. 06031328 to 060fe14b
          - loop??
        - ?
  - after calling 0604a940 at 0604a5b6, r14 = pointer to prepped stuff struct?
    - struct is 88 bytes?
      - 0: pointer to end?
      - 4: ?
      - 8: ?
      - 12: ?
      - 16: pointer to raw string?
- after calling 0604a590 at 0601fbc0, ?
  - r15 = pointer to raw string?
  - ok, and then we go through the same codepoint search?
  - 0601fc28 = check for ??
- 0601fbc4: after call to 0604a590
  - 0601ff20: nop for no full-width text
    - this prints one full-width character?
    - calls 06020034 (8034)
      - 8052: clears memory?
        - nop causes artifacts, but text is still printed
      - 8062: search index of KANJI.FNT for character given by r5,
        then return graphic's address in r0
        - nop causes uniform garbage
        
7CC4 = get raw character when printing menus
  - unlike dialogue, character number is used to determine which font to
    use for printing
    - >= 0x8000 is whole-width?
    - others are half-width??

** 8-bit menu text hack 1:
  originally, the game uses a printing routine that dispatches off the
  value of the first byte read from the character string, where values <= 7F
  are 8-bit halfwidth characters (and are printed as such) and values >= 80
  are the first byte of a 16-bit fullwidth character.
  we intend to print all text as fullwidth (since we've actually reduced it
  to halfwidth), so we simply treat all values as 8-bit fullwidth by nopping
  the following:
; 16-bit char: fetch second byte
;0x00007CC4: 0x01DC	mov.b	@(r0,r13),r1
;0x00007CC6: 0x4918	shll8	r9
;0x00007CC8: 0x611C	extu.b	r1,r1
;0x00007CCA: 0x291B	or	r1,r9
;0x00007CCC: 0x7D01	add	#0x01,r13
; check whether to draw full or halfwidth
;0x00007CCE: 0x915F	mov.w	@(0x0C2,pc),r1	; 0x00007D90 (0x7FFF)
;0x00007CD0: 0x3916	cmp/hi	r1,r9
; branch if rawchar < 0x8000 (halfwidth)
;0x00007CD2: 0x8B01	bf	0x00007CD8
  this will work once KANJI.FNT is updated to use the pseudo-halfwidth font;
  however, special characters from the halfwidth font ("Lv", etc.) will have
  to be represented as well, or the source strings will need to be modified
  appropriately.
  an alternative approach would be to treat everything as halfwidth
  
0604e840: copy a string? (ellie's name on main menu)
  - called at 0604cb62

ff986 = "@"

セニア = 835A　836A　8341
ｾﾆｱ = BE　C6　B1

main menu stuff(?) starts around 1362c (宝箱の鍵)
  - character names immediately precede this
  
0602c330 (14330): システム
  - 0604d198: first read -- part of strlen? copies 1 char at a time
    (to 060fec74)
    - 0604d180: routine -- check for terminator? (r5 = getpos)
      - called at 0604ab5e (calculates string length?)
  - 0604e878: copied to stack (060fed78)
    - 0604e840 (36840): copy routine?
      - called at 0604cb62
  - both of the above are called within 0604a9c8, called at 0604a950
    - in 0604a940, called at (eg.?) 0604a5b6
      - 0604a940: called once per string to print?
      - in 0604a590, called at 0601fbc0
        - 0601fbc0: executed once per fullheight string to print? 
          - 0604a590: r5 = source string pointer?
0601fb90: prints fullheight string?
  - r8 = stack frame?
  - r9 = source address?
  - called from various sources (060314b8, 060314ca, 06031364, 060313be,
    06031270)
    - 0602c576: call 06031484, drawing システム label?
      - at this point, r4 = pointer to システム

060551C0 (3d1c0) = base of string pointer table for "system" text?
  - 060551C8 (3d1c8) = pointer to システム text
  
060300f0 (180f0): ステレオ
  - pointer: 181ec
060302bc (182bc): メッセー
  - pointer: 183f8
060304d4 (184d4): something カーソル
  - pointer: 185dc
  
"2"
  - 4a1c9: pointer to フレイ
  - 0606324e (4b24e): ひんし (8x8 hiragana encoding)
    - ?
    - 4b1f2: こんらん 
    - 4b1ff: ゆうわく 
    - 4b20c:  と゛く  
    - 4b219:  まひ  
    - 4b227: せきか 
    - 4b234: きせ゛つ 
    - 4b241: きせ゛つ 
    - 4b24e: ひんし 
  
1:13890: ﾌﾚｲ
  - pointer at 06054d50 (3cd50)
    - read at 0603110e (1910e) for magic use menu
    - read at 06030aac (18aac) for status screen
    
120a4 = core print 8x8?

overworld magic use menu: see test_6x8_magic_use_overworld.asm
  19118 = call 11de4 to draw name
    - insert code before here to:
      - change 11FF6 from 70 04 to 70 03 (reduce spacing to 6x8)
    - insert code after here to:
      - change 11FF6 back to 70 04
    - spell name strings should be preconverted
    19194 -- address used at 190D2 (0x060A26F0)
      -- set this to some free space (06041be0 / 29be0)
    190D4 -- change to
      43 0b   jsr @r3
      0x021A  sts	macl,r2
    191a4 -- address used at 19128
      -- set to some free space (0604a998 / 32998)
    change 1912A to:
      41 0b   jsr @r1
  
overworld status screen magic list: see test_6x8_magic_status.asm
  18A8A: E5 02 -> E5 10
    - position of first column
  18AA8: E5 5E -> E5 6C
    - position of second column
  ; call 11de4 to draw name
  0x00018AB8: 0x4A0B	jsr	@r10
    - insert code before/after to change
      11FF6 from 70 04 to 70 03 and back

19134 = done drawing everything
  - insert code to change 06029ff6 (11FF6) from 70 04 to 70 03
11FF6 = advance 8x8 character spacing
  - 70 04
  - add flag and check here to see if spacing should be reduced to 3
  - actually, better yet, just use self-modifying code
  
***STRING POINTER TABLES ("1") -- overworld***
3a9a0-3a9bc -- character names (halfwidth)?
  - 0x7 entries?
3ccb0-3cccc -- character names (fullwidth)?
  - 0x7 entries?
3cd04-3ce7c -- magic??
  - 0x5e entries?
3cf8c-3d1d8? = string pointer table
  - 0x93 entries?
also:
  3a494-3dcaf = some filename pointers (.FLD)
  
  
***STRING POINTER TABLES ("2") -- battle***
  ...
  
  

* physical screen space for 8x8 stuff -- 




1:13650 噂xf3れたプレート
  89 F3 82 EA 82 BD 83 76 83 8C 81 5B 83 67
  - in-game: 壊れたプレート
1:140ac 単体・炎の攻撃 (flay description)
  - pointer: 3cf90

13864
  01 B6 DE DD BE B7 B5 C4 BC
    01  ｶﾞﾝｾｷｵﾄｼ
    - inline hiragana/katakana switching:
      - 01 switches to hiragana
      - 02 switches to katakana
13890: ﾌﾚｲ
  pointer: 
  
2:45d44
  96 DE FD 9E 97 95 E4 9C 00
   	か゛んせきおとし
  - HARDCODED halfwidth hiragana
  
moved to 002f4e29
"attack" to 060d7a04
decompressed to 060d7f00
first nonzero data to 060d7f20
; call 2d73c (send pixel data to vdp?)
0x0001A940: 0x400B	jsr	@r0
  - called at 060328ea (1a8ea)
goes to (2)5c47b40
structs (0x24 bytes?) with vram pointers starting(?) at 0609a2b8
  - pointer to raw pixel data?
  - pointer to vram target?
  - "Attack" -- 0609a4d4?
    - to e.g. 25c4ba20 (pointer at 0609a4d8)
    - pointers to decompressed graphic:
      - 0609a4d4 (+4 = texture)
      - 060d7d50 (+4 = texture)
      - 060d7e10 (-18 = texture)
      - texture: 060b8368
      - texture: 060d7df8
25c484c0
final pointers to texture at:
  060b8368
  060d7d54
  060d7df8
  
0605d73f = フレイズ
  - copied to 060e5ce0
  - 060e5c44
  
20114 = ??
27D70 = ??
25692 = ??
1fe08 = ??

1BD04

1C112: call to 3d1f8 (strlen) to determine text box width on
  magic target screen
  - called from 23db2

06036300 (1e300) -- generate dialog box
  - for attack, called at 0603b8e0 (238e0) and 0603ebb0 (26bb0)
  - for defense, called at 0603bb20 (23b20) and 0603ebb0
  - for spell names, called at 0603bdd4 (23dd4)
