Well, what game? Tell us a bit more and give us some examples right out or your hexeditor. That way, we can understand better what you're talking about. Also, did you watch for alignment? Some games have 1 and 2 byte codes for characters but some control codes may only start at the next even offset.

cYa,

Tauwasser

Well, the only other way to know for sure is either hacking ASM, or looking for some related pointers/stuff that you don't move and see if it happens to define variables. Also, you could try repointing a japanese text with $03 in it to another japanese text with $03 in it and see if it now prints other variable names, or the one it would have in the other text.

cYa,

Tauwasser

Comments get compiled out of code. That said, it's still possible to divine how code works if you know what to look for.

You're going to need two things.

First is a debugger. Get VBA-SDL-H, or better still, pony up $15 for NO$GBA. Vanilla Visual Boy Advance has a debugger, but it's crap.

Second is the text in the ROM. Find a string you can get to easily and note its position.

Now, before we continue, here's a little aside. The nice thing about GBA programming is that there's no bank swapping. Other cartridge-based consoles, for the most part, can only access a little window of program ROM at a time: this generally makes expanding ROMs a pain in the ass and necessitates some tedious math every time we crack open a ROM in WindHex or whatever and want to figure out what the address we find translates to in hardware terms. For GBA games, all we have to do is add $8000000 to the ROM address. That's it. If we're looking at data at $42 in WindHex, the GBA sees that same data at $8000042. If it's at $68106, the GBA address is $8068106. If it's at $DABEEF, the GBA address is $8DABEEF. And so on.

That said, what we want to do is set a breakpoint for that location in the ROM. Basically, you tell the emulator to freeze when it loads from that position. The entire GBA memory map, ROM and all, is just one big block, so the same procedure works if we're checking for reads from anywhere else in memory. We can also check for writes, but for obvious reasons it's pointless to check for writes to the game ROM. ^_^;

In brief, you will set the debugger to catch the game in the act of reading your problem string. And what are you going to find when the trap closes? Why, an "ldr" instruction that loads the first byte of your string (you did set the breakpoint to check for reading the first byte, correct?). You'll need a GBA THUMB ASM reference to get much further, but the next step is to set an execute breakpoint for the instruction that loads the string from the game ROM. Let the game run a few cycles through the code until the instruction loads your headache-inducing name variable byte. Step through the code and watch what it does next (again, you'll need a GBA THUMB reference to make sense of what you'll find, but note that mnemonics all have logical meanings: "ldr" is short for "load register", for instance, and by paying attention to what happens after each instruction, figuring out what some opcodes do on your own is a simple matter of logic.).

Now we start all over with the modified ROM, with the string that doesn't work. Repeat the process and watch what happens when it hits the problem code: what does it do differently, and why? If you can figure that out...well, the rest is obvious. ^_^

Good luck!

Thanks for all the info!  I'll definitely try it out, but maybe not until the weekend.  One thing I do need to learn is the basic syntax dealing with R1-R16 and the hex values in the code (do they refer to offsets, actual values being used, or does it depend on the situation?).  If you know of a tutorial around here or elsewhere that starts at that basic level, I think that will help me figure out what I'm looking at.

I found some time to mess with it tonight.  I can get VBA-SDL-H to stop at a certain address, but how do I step through?  Sadly, I've never used any debugger...I have no formal programming experience, just what I've been forced to learn for work and had to learn to complete some sort of project.

Anyway, I created log files and had them stop on the first character of the <$03><$##> string in both the original and translated states.  Here's the output:

08000000  ea00002e b $080000c0
080000c0  e3a00012 mov r0, #0x12
080000c4  e129f000 msr cpsr_fc, r0
080000c8  e59fd028 ldr sp, [$080000f8] (=$03007fa0)
080000cc  e3a0001f mov r0, #0x1f
080000d0  e129f000 msr cpsr_fc, r0
080000d4  e59fd018 ldr sp, [$080000f4] (=$03007e00)
080000d8  e59f10cc ldr r1, [$080001ac] (=$03007ffc)
080000dc  e28f0018 add r0, pc, #0x18

They were identical in both cases.  Also, this seems like an incredibly small amount of code, is it only outputting code that references this specific address?  The documentation made it sound like it outputs all code from the beginning to the reference to this address.

You must have inputted the break code in a weird/wrong way. If you looked for it accessing rom data, then it shouldn't have breaked on the first 3 already...

cYa,

Tauwasser

Tauwasser: I entered the break at the address when the text starts plus the 08000000 offset.  I don't know how else to do it and the debugger doesn't offer very many instructions.

Kajitani-Eizan:  VBA tracer worked.  Now, I have the thousands of lines of code that I expected.  When I run the original ROM, I find the address of the beginning of the item description, while when I run the translated version of that sentence, I find neither the old offset nor the new offset, yet translated text does show up except for the variable part.  The address was in "R5", which I assume is some memory area.  I looked around this site and elsewhere and I can't seem to find a guide that explains the exactly what R0-R16 is, the syntax of ARM and THUMB and an explanation of the commands.  If such information exists, I think I may be able to figure it out.

Thanks for sticking with me, people.  I commend you for resisting the urge to scream n00b at me!