Framing the Phase 2 WW Hack

With this hack proposal, a variable in WRAM will be assessed and based on its value each character will go from 1 fixed default to 1 of 22 options loaded on battle start. Afaik the routine to load the K.O. sprite is run for all 4 slots— so making a hack to how it works would neatly affect all the character slots without too much extra logic.

Which of the new sprites we want to actually load from ROM is determined by these “Job bytes” on battle start: $7E:2001, $7E:2081, $7E:2101, $7E:2181. Same pattern, with slot 1 through 4. A value of #$00 will indicate the first sprite for that character slot, and #$15 does indeed represent the final sprite (22nd, 44th, 66th, 88, 110th options).

Based on prior pseudo-code routines, I’m thinking that the easiest way to choose the sprite is to look at the “Job byte” and then move forward from sequence start that many times. Regarding the standard size of the sprites, they are all 6 tiles of 4bpp image data so at 32 bytes per tile that’s 32 x 6 = 192 bytes per sprites.

192 x 110 = 21120 = $5280

From E8:0000 to E8:527F will be the 110 new sprites’ location.

Test template with 110 zones of 6 tiles painted on, with numerals.

Using Edit > Paste From in T.M. allows direct injection of PNG files! It can be much quicker than SNES Tiles Kitten to do it this way, but the palette control is a lot trickier to maintain. For a rough test like this it’s ideal, as just seeing something on the screen is the goal— the numbers in the tiles appearing on screen is the only thing getting tested (they’re 00 thru 21 so it will be possible to see if the Job byte lines up as expected when the new hack logic is firing).

The catch is that the vanilla K.O. sprites for Freelancer (the only option) are all adjacent. Now those will be 4224 ($1080) bytes apart, so the new logic will need to account for the spacing. It currently thinks they’re only 192 bytes apart, because they’re adjacent.

Once this sprite loading routine is found, the disassembly will provide a scaffold that can be modified to make this happen.

Finding the K.O. Sprite Load Routine

Same process Cubear demonstrated will work here. Setting a breakpoint at the WRAM that equals the first byte of the first K.O. tile will pause the game and reveal what routine is writing to that location.

And once found, writing a new routine that can handle 22 options versus always the same one will be challenging.

• Must reload the KO sprites into VRAM on Job change (in Job menu)
  • will need to find where in RAM this is stored
  • cannot rely on the in-battle Job byte listed above
    • they exist in VRAM before the battle loads
• Will hook off the existing routine and replace it
  • will resemble its logic re: how to write to VRAM
  • will need to:
    • sample Job byte when choice is made in Job menu
    • count forward that many times from the start of that character’s sprites, times $C0
    • load those $C0 bytes to VRAM at this time

Another hint from Cubear recommends tracking these values through DMA, which will be a first for me.

VRAM doubles the incoming addresses. IDK why, but it’s visible here as w.$6700 is seen in VRAM at $CE00. (w. as notation means “word” versus “byte” 🤷‍♂️ )