+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  What do you do when pointers are hard-coded into ASM?
Pages: [1]
Author Topic: What do you do when pointers are hard-coded into ASM?  (Read 2 times)
Markliujy
Guest
« on: September 09, 2009, 08:45:08 am »

I've been playing around with this game (Angelic Layer for the GBA), but I've hit a wall, in that as far as I can tell, the pointers are hard-coded.

To make matters worse, the game has a lot of control codes in the script, like movement, display things etc.

There's a giant table with pointers to ASM routines. There's actually a reference table of sorts, which is compared to something (I haven't gotten that far backwards in the ASM yet) to determine which pointer to take.

In the ASM routines, it then has hard-coded pointers to where the actual script pieces are. And they're all over the place as far as I can tell. Some ASM routines are ASM hard-coded to run a piece of script repeatedly, usually a control code such as movement. (I assume to save space...) And they all use the same script reading routine for text or control codes.

I was thinking of writing a half-baked ASM interpreter to run through the entire thing to try and pick out the pointers to actual script (by noting everytime it calls the script reading routine), but it has so many false positives due to the hard-coded ASM to save space...

Or maybe look at the giant blocks of actual script, and try to see if there's a range for it all, and put that through an algorithm to distill the actual script pieces and the pointers?

Or I guess I could go through it one by one manually...but I'm wondering....is there any great ideas I missed? Or should I be just giving up?
« Last Edit: September 09, 2009, 08:58:52 am by Markliujy »
KaioShin
Guest
« Reply #1 on: September 09, 2009, 08:58:27 am »

What I learned from Kingcom for SRW game's menu text is to do the opposite approach of what you're planning.

In SRW, the pointers to the menu text are embedded in ASM code, but the actual text is one big block. If your game is similiar, do the following: Dump that block of text, and search the ROM on each (aligned) letter address for a pointer to that address. Or search for a pointer to each string if you can tell easily where one strings ends and another begins. This will give you the pointers to each string, plus a few false positives, but it shouldn't be that many since GBA 4 byte pointers are pretty unique.

This is pretty simple and should work every well. Definitely 10 times easier and less work than to write some sort of ASM parser.
Markliujy
Guest
« Reply #2 on: September 09, 2009, 09:02:23 am »

Guess that's one thing to try next...I think the game has 00's splitting up the strings, but I really ought to have a look at where most of the script is...

I'm assuming you'd probably need to do a fair bit of testing to make sure everything was caught though?

Don't think I've ever seen a false positive on a GBA 4 byte pointer yet...4 bytes of uniqueness is great.
Dragonsbrethren
Guest
« Reply #3 on: September 09, 2009, 01:19:22 pm »

Quote from: KaioShin on September 09, 2009, 08:58:27 am
What I learned from Kingcom for SRW game's menu text is to do the opposite approach of what you're planning.

In SRW, the pointers to the menu text are embedded in ASM code, but the actual text is one big block. If your game is similiar, do the following: Dump that block of text, and search the ROM on each (aligned) letter address for a pointer to that address. Or search for a pointer to each string if you can tell easily where one strings ends and another begins. This will give you the pointers to each string, plus a few false positives, but it shouldn't be that many since GBA 4 byte pointers are pretty unique.

This is pretty simple and should work every well. Definitely 10 times easier and less work than to write some sort of ASM parser.

Yeah, this is what I did for FF4ET. I really wanted to get a nice, compilable disassembly of its menu bank, but that would've been way too much work. Instead, I just used the old-fashioned way of finding the text and window pointers, which worked well enough. Since all of the menu-related things are in one bank, I knew exactly where to search, and had absolutely no false positives.
Nightcrawler
Guest
« Reply #4 on: September 09, 2009, 04:40:09 pm »

That works if you're lucky enough to have the referenced text in a big block. I've seen it where the text is immediately following the ASM code that calls it. Then after that individual string is more ASM code. Then the method described of scanning for ASM patterns would probably work better than most. It's generally fairly easy because there's usually some code or a subroutine that is called the same way for all and it's usually only used for text. You'll have to verify that's the case in your game though.

Or, you can just kind of do them while you hack them as you go along and find each pointer. It usually only takes a few seconds when you know what to look for in the debugger. No need to really figure out how to dump them all that way.

You be the judge on what the best method is for you and your game. There's always more than one way to do something. Wink
Markliujy
Guest
« Reply #5 on: September 10, 2009, 10:38:59 am »

Luckily enough, most of the text was in a giant block, so KaioShin's method worked. Except for a few false positives, since for some reason they had pointers to pointers in there for NPC choices I think, but nothing a bit of old fashioned manual checking didn't solve. I'm not sure why I initially thought that it'd be a pain to go through it with that method...it was actually pretty simple...

Well, thanks for the help! Now to see if I can code ASM and get a VWF going...
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC