Pointers in Magic Sword

[Hitashi]

Hi. I've been trying to hack some things in the Snes port of Magic Sword, mainly some graphics but also some text changes.

I've found most of the things I'm looking to edit, and some changes were successful. But I'm having a hard time finding how to edit specific things like the SCORE word. For reference, it's located at 000270B: C4 20 B4 20 C0 20 C3 20 B6 20. I was looking to change the word to POINTS but I needed one more letter/image.

The thing is, this is quite packed. SCORE is nestled between L ("L" being the L word used for your allies in the bottom part of the interface: L1, L2, L8, etc.) and TOP (the TOP score) with no leftover space: it's all surrounded by code for how the game draws the remaining interface (energy bars, etc.), so going brute force & just adding an extra letter doesn't hold up because the code immediately afterwards is the one use for drawing the item box, for instance.

I looked around for pointers but I'm having problems finding them. I tried looking for anything that would point to SCORE, and also to the start of what I think is the start of this sequence (interface drawing + words), but couldn't find anything. Being Lo-ROM, I've tried applying the +8000 rule the offset is between the 0000-7FFF range, but nothing. The allies' bios also pose the same problem to me, as they are all quite packed...

Ideally I'd point them to an empty space/block (the FBEA0-FBFFF is empty, for instance), though given my knowledge that would be extremely difficult.

Could someone point me to the right direction on how I could do this? Thank you

 

[Reaper man]

That really depends on your skill. Have you ever used a debugger? do you know 65x derivative assembly, notably 65c816? You'll probably have to crack open a debugger and figure out how it renders the string to screen, from there modify the code to place it wherever you'd like. EDIT: Also I couldn't but notice the rather... unconventional format the string is stored in. Care to elaborate?

 

[Hitashi]

Hi, thank you for your answer!

From what I've messed around with, the relevant code in that area starts at offset 2703 (here's the code and what it means on screen):

C7 23 C5 20 C0 20 C1 20 C4 20 B4 20 C0 20 C3 20 B6 20
L     T     O     P     S     C     O     R     E

And after that, it continues this way from offset 2715:

81 23 82 23 82 23 83 23 84 23 85 23 84 23 85 23 86 23 87 23 87 23 88 23 61 23 62 23 63 23 64 23 65 23 66 23 67 23 68 23 69 23 6A 23 6B 23 6C 23 6D 23 6E 23 6F

In short, what happens is:

81 = renders top left corner of item box.
82 = renders top of the item box. it's repeated because the same sprite is used twice.
83 = renders top right corner of item box.
84 = renders left side of item box. also repeated, tile used twice.
85 = renders right side of item box. both repeated.
86 = renders bottom left of item box.
87 = renders bottom of item box. also repeated, used twice.
88 = renders bottom right of item box.

61 = top left of floor box (where the large digits are, they show what floor you're on)

...And so on. The interface code is basically one long string where everything is packed and there's basically zero room to make changes. This part of the code also includes health bar changes (specific graphics to show a half health bar, for instance).

Here's a picture of the game for reference:

(the item box is the thin brown frame, and the floor box is the one that reads 08)

20 and 23 are spacing or position values, I think.

I don't know quite how to find a pointer here because I'm not even sure how and where the code begins exactly.

And regretfully, it seems the more I try to invest in debugging and assembly, the less I seem to understand it

 

[Reaper man]

You're probably going to have to buckle down and start learning. (it's what I had to do at some point)
I think there's still a sticky here where I go over the basics, but honestly, I would begin with setting a read breakpoint where the S is and go from there. See what the routine does, with an instruction reference at hand to see what it's doing. If I have time, I may decide to poke around and see what it's doing. No promises though.

 

[Reaper man]

okay, after looking at the data again, it really doesn't follow any... common sense order in regards to the letters. How, exactly, did you find this data in the first place?


EDIT: okay, maybe I was a bit tired last I looked at it, it actually does make some sense. Just so you know , those values are 16 bit vram addresses that indicate where the tiles are stored, so the extra bytes (eg: 20) are just the upper bytes in the address.
I did find something though, perhaps modifying the 16 bit value at address 0x25C1 2615 will change where it points to. With that said, however, you still need to figure out how it knows to print out 5 characters instead of say 6.
....
oh who the fuck am I kidding *keeps digging through code*


EDIT EDIT: I'm an idiot, I set the wrong breakpoint (I had it set to the "L" string, whoops!), like a moron. Good thing I caught that, or else I would be pulling my hair out.


Okay, so now that I spotted fixed that error, everything makes a lot more sense. This game handles pointers in a very strange way, utilizing its zero page register as the pointer itself (never seen that before). It loads it from a pointer table of sorts, which is more like a pointer/length/location array. The table is basically 2 bytes that indicate the pointer (where to read the data), 2 more bytes to indicate the value of the x register (used for length of string) and another 2 bytes that indicate where to write this in vram (modifying this would change the position of the string)


With this knowledge, it should be trivial to modify the string to any length and if you know how snes vram works, put it anywhere you damn well please. I'll probably cook up a proof of concept in a bit.

 

[Reaper man]

Proof of concept, lol: