Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
Our weekly protagonist poll is now up! Vote for your favorite Trading Card Game 2 protagonist in the poll by clicking here.
Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
I see now. You're confused as to why we can use r2 as the bx register for our jump when it's not safe to use in general. Allow me to explain.
Lets first take a look at the routine at 0809A8BC.
Spoiler:
Code:
ROM:0809A8BC @ =============== S U B R O U T I N E =======================================
ROM:0809A8BC
ROM:0809A8BC
ROM:0809A8BC item_by_id:
ROM:0809A8BC
ROM:0809A8BC PUSH {LR}
ROM:0809A8BE LSL R0, R0, #0x10
ROM:0809A8C0 LSR R0, R0, #0x10
ROM:0809A8C2 BL itemid_sanitize
ROM:0809A8C6 LSL R0, R0, #0x10
ROM:0809A8C8 LSR R0, R0, #0x10
ROM:0809A8CA MOV R1, #sizeof(item)
ROM:0809A8CC MUL R0, R1
ROM:0809A8CE LDR R1, =item_undefined
ROM:0809A8D0 ADD R0, R0, R1
ROM:0809A8D2 POP {R1}
...
...
ROM:0809A8A4 itemid_sanitize: @ CODE XREF: item_by_id+6p
ROM:0809A8A4
ROM:0809A8A4 PUSH {LR}
ROM:0809A8A6 LSL R0, R0, #0x10
ROM:0809A8A8 LSR R1, R0, #0x10
ROM:0809A8AA MOV R0, #0x176
ROM:0809A8AE CMP R1, R0
ROM:0809A8B0 BHI loc_809A8B6
ROM:0809A8B2 MOV R0, R1
ROM:0809A8B4 B loc_809A8B8
ROM:0809A8B6 @ ---------------------------------------------------------------------------
ROM:0809A8B6
ROM:0809A8B6 loc_809A8B6:
ROM:0809A8B6 MOV R0, #0
ROM:0809A8B8
ROM:0809A8B8 loc_809A8B8:
ROM:0809A8B8 POP {R1}
ROM:0809A8BA BX R1
ROM:0809A8BA @ End of function itemid_sanitize
ROM:0809A8BA
ROM:0809A8BC
As you can see, the whole function doesn't use r2. However, this is just something that happened in this specific case. We can tell by just looking at the above routines that this function doesn't use r2 as a parameter AND that r2 isn't used for any of the calculations. However, there can be routines which don't take r2 as a parameter but use it for calculation inside the routine.
In general, if the registers aren't specifically used as parameters, you can use them to call the function. If they're not parameters, the only way for them to be used inside the routine is for calculations. For example, lets look at the other routine you were talking about.
Clearly here, r2 cannot be a Parameter because it's overwritten by r0 in the first OP code after the push statement. In fact, if r2 or r1 isn't a parameter, but it used in calculations, the routine must first make measures to "clean" or set them. This is because the function doesn't know from where it may be getting called from. In this case r2 is overwritten with r0, so the old value of r2 is irrelevant to the function. Notice that because r2 is overwritten, the function which calls this one had it's old value of r2 changed. This is what I mean by "we cannot guarantee registers r0-r3 aren't overwritten".
To take away from this, basically if a register isn't used specifically as a parameter for the function, and is a low register, then it's safe to use as a caller register.
I got what you meant in the above reply now, but I think there's still a specific case which cause problem. (Not the case in the tutorial as the tutorial do not cause such problem) To show it more clearly, I will make an example:
Firstly, the routine at 0809A8BC was called (which is already modified) so that r2 was changed.
Then an unknown routine is called, which use R2 as a parameter.
For pseudo code:
.......(instructions, which turns r2 into 0x1 for example)
bl 0809A8BC(r2 is changed into a pointer as the routine is modified)
bl 08XXXXXX(take r2 as a parameter to output something)
.......(Not related codes)
As you can see, I think it may cause problem... I think what you said is the case when the function at 08XXXXXX doesn't take r2 as a parameter, as in the tutorial. Or did I ignore something in your words? Thank you very much.
I got what you meant in the above reply now, but I think there's still a specific case which cause problem. (Not the case in the tutorial as the tutorial do not cause such problem) To show it more clearly, I will make an example:
Firstly, the routine at 0809A8BC was called (which is already modified) so that r2 was changed.
Then an unknown routine is called, which use R2 as a parameter.
For pseudo code:
.......(instructions, which turns r2 into 0x1 for example)
bl 0809A8BC(r2 is changed into a pointer as the routine is modified)
bl 08XXXXXX(take r2 as a parameter to output something)
.......(Not related codes)
As you can see, I think it may cause problem... I think what you said is the case when the function at 08XXXXXX doesn't take r2 as a parameter, as in the tutorial. Or did I ignore something in your words? Thank you very much.
In this case the routine would need to set the paramaters again before the second "bl", or the first routine would have to restore said parameter (which it probably won't).
Remember that functions are expected to modify or use registers r0-r3. So if one function is called, then we need to assume r0-r3 holds some sort of return value OR the values are messed up. So the second function, by definition, mustn't have any parameters at all, OR the parameters for it are the return value from the first function. For example, picture this:
bl getPokemonName @maybe sets r0 to a RAM offset with the Pokemon's name
bl checkIfMagikarp @maybe checks if r0's RAM location says Magikarp
(or the parameters are stored via SP, which is a little more complicated and I will probably explain in my next tutorial or something, just forget I said this bracketed comment for now :P ).
In this case the routine would need to set the paramaters again before the second "bl", or the first routine would have to restore said parameter (which it probably won't).
Remember that functions are expected to modify or use registers r0-r3. So if one function is called, then we need to assume r0-r3 holds some sort of return value OR the values are messed up. So the second function, by definition, mustn't have any parameters at all, OR the parameters for it are the return value from the first function. For example, picture this:
bl getPokemonName @maybe sets r0 to a RAM offset with the Pokemon's name
bl checkIfMagikarp @maybe checks if r0's RAM location says Magikarp
(or the parameters are stored via SP, which is a little more complicated and I will probably explain in my next tutorial or something, just forget I said this bracketed comment for now :P ).
Okay, I think this time I know your meaning! Thank you very much for your replies!
But I've found another problem:
The function runs well when use "bufferitem" command in script, but in the bag it is messed up with the next line. After some debugging, I've found that the problem is caused because the string of the text of the next item (or "cancel") overwrite the RAM offset where the 15th,16th... character of the first item are stored.
Okay, I think this time I know your meaning! Thank you very much for your replies!
But I've found another problem:
The function runs well when use "bufferitem" command in script, but in the bag it is messed up with the next line. After some debugging, I've found that the problem is caused because the string of the text of the next item (or "cancel") overwrite the RAM offset where the 15th,16th... character of the first item are stored.
Do you have the RAM offsets for these? It could be either an insufficient malloc or possibly the buffer is too small. Dependently the fix is a little different for each time. It's also important to note, that after a few char expansions that the graphical space for the name will overflow.
Do you have the RAM offsets for these? It could be either an insufficient malloc or possibly the buffer is too small. Dependently the fix is a little different for each time. It's also important to note, that after a few char expansions that the graphical space for the name will overflow.
It seems that the function at "08008D84" is always called to transfer the string data of item in the ROM to a RAM offset.
Therefore, the RAM offset of the first item should be at "020041F1". You will see that firstly the string of the expanded is written correctly to that offset, but after some time the offset after the 14th byte of the string is overwritten by the next item string (or cancel). If you create a breakpoint on write to this offset, you will find the function at "08008D84" is called again.
This is a screenshot of this. (I modified "burn heal" into "THEITEMNAMEISNEW")
It seems that the function at "08008D84" is always called to transfer the string data of item in the ROM to a RAM offset.
Therefore, the RAM offset of the first item should be at "020041F1". You will see that firstly the string of the expanded is written correctly to that offset, but after some time the offset after the 14th byte of the string is overwritten by the next item string (or cancel). If you create a breakpoint on write to this offset, you will find the function at "08008D84" is called again.
This is a screenshot of this. (I modified "burn heal" into "THEITEMNAMEISNEW")
Alright, I took a few minutes to briefly look at how the bag strings are being made. I'm unsure wheather to give you a solution, or to let you try and figure this out yourself. For now, I'll explain some details, and see if you can make it work yourself.
It looks like the bag hasn't malloc'd enough space for the larger strings. It's malloc'd 0x331 space. Given 43 items, that's obviously 0x13 bytes of string space per item. So we would need to malloc a greater amount, say each item string is potentially 0x19 bytes long. Then the malloc needs to be changed to 0x408. By the way, this malloc is happening here like this:
In addition to the malloc problem, the game has also hard coded a loop counter similar to this format:
Code:
/*some stuff before this*/
void Bag() {
//the destination RAM is malloc'd and put in the static pointer
mallocBagAttributes();
generateBagStrings();
//more stuff
return;
}
void generateBagStrings(){
/*Writes to RAM rather than returning*/
items = sizeof(bag.pocket);
counter = 0;
while (items != counter){
int temp;
str *src = bag.pocket[counter]; //src
//Also some math you should definitely think about changing *hint hint*
//I recommend changing the entire thing rather than a small fix
/*R6 = counter */
temp = counter * 4;
temp += counter;
temp *= 4;
temp -= counter;
//The static pointer is used to generate a "clean pointer"
temp += *mallocPointer;
generateString(temp, src);
}
/*This function also handles the cancel string and a few others which aren't related
to the bag's pocket space. However, they are irrelevant here, so I'm not going to code-ify them*/
return;
Clearly, there's some hard-coded math which is also creating a problem. I suggest that you change this math, either with a hook or by overwriting it, so suit us. Think about when counter = 0, counter = 1, and counter =2, ect.
You will notice the yield is going to be in multiples of 13 +1. Then, all you need to do is make it multiples of the real string length instead. Because strings are 0xFF terminated, we don't need to worry about having unused bytes in-between strings.
Alright, I took a few minutes to briefly look at how the bag strings are being made. I'm unsure wheather to give you a solution, or to let you try and figure this out yourself. For now, I'll explain some details, and see if you can make it work yourself.
It looks like the bag hasn't malloc'd enough space for the larger strings. It's malloc'd 0x331 space. Given 43 items, that's obviously 0x13 bytes of string space per item. So we would need to malloc a greater amount, say each item string is potentially 0x19 bytes long. Then the malloc needs to be changed to 0x408. By the way, this malloc is happening here like this:
In addition to the malloc problem, the game has also hard coded a loop counter similar to this format:
Code:
/*some stuff before this*/
void Bag() {
//the destination RAM is malloc'd and put in the static pointer
mallocBagAttributes();
generateBagStrings();
//more stuff
return;
}
void generateBagStrings(){
/*Writes to RAM rather than returning*/
items = sizeof(bag.pocket);
counter = 0;
while (items != counter){
int temp;
str *src = bag.pocket[counter]; //src
//Also some math you should definitely think about changing *hint hint*
//I recommend changing the entire thing rather than a small fix
/*R6 = counter */
temp = counter * 4;
temp += counter;
temp *= 4;
temp -= counter;
//The static pointer is used to generate a "clean pointer"
temp += *mallocPointer;
generateString(temp, src);
}
/*This function also handles the cancel string and a few others which aren't related
to the bag's pocket space. However, they are irrelevant here, so I'm not going to code-ify them*/
return;
Clearly, there's some hard-coded math which is also creating a problem. I suggest that you change this math, either with a hook or by overwriting it, so suit us. Think about when counter = 0, counter = 1, and counter =2, ect.
You will notice the yield is going to be in multiples of 13 +1. Then, all you need to do is make it multiples of the real string length instead. Because strings are 0xFF terminated, we don't need to worry about having unused bytes in-between strings.
I'm terribly sorry because I really don't understand your words though I really want to try myself.
Actually I haven't learned C language yet. So could you please try to tell me in something I can understand?
I'm Sorry indeed to waste your time writing the codes but I really don't know even a bit of C.
/*some stuff before this*/
Load_bag_function:
push {r4-rx, lr}
@some stuff before this
@Allocate memory in Ram for bag strings
bl mallocBagAttributes
ldr r4, =(0x203AD1C) @this is a pointer to free RAM space
str r0, [r4] @load the return from the malloc call into the pointer
@generate bag strings at allocated memory
bl generateBagStrings
//more stuff
pop {r4-rx, pc}
generate_bag_strings:
push {r4-rx, lr}
@some stuff before this
....
@save RAM space pointer in r5
ldr r5, =(0x203AD1C)
mov r6, #0x0 @r6 is a counter
loop:
ldr r0, =(Amount of items in pocket)
cmp r0, r6
bhi exit
@here is the math you're interested in changing
@make r4 at the end = [max string size -1]
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
@get item name from ID, takes r0 = item ID
@once again irrelavent
bl build_str_item
....
....
@some operations occur for R6 = next item
...
...
cmp r6, Amount of items
blo loop
exit:
@This function also handles the cancel string and a few others which aren't related
@to the bag's pocket space such as the word cancel. But they are irrelevant for this hack
pop {r4-rx, lr}
This code is not EXACTLY what's there. I've simplified it so it's easier to understand. You're interested in the :
Code:
@here is the math you're interested in changing
@make r4 at the end = [max string size -1]
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
portion of the above code. This happens exactly at 08108450.
/*some stuff before this*/
Load_bag_function:
push {r4-rx, lr}
@some stuff before this
@Allocate memory in Ram for bag strings
bl mallocBagAttributes
ldr r4, =(0x203AD1C) @this is a pointer to free RAM space
str r0, [r4] @load the return from the malloc call into the pointer
@generate bag strings at allocated memory
bl generateBagStrings
//more stuff
pop {r4-rx, pc}
generate_bag_strings:
push {r4-rx, lr}
@some stuff before this
....
@save RAM space pointer in r5
ldr r5, =(0x203AD1C)
mov r6, #0x0 @r6 is a counter
loop:
ldr r0, =(Amount of items in pocket)
cmp r0, r6
bhi exit
@here is the math you're interested in changing
@make r4 at the end = [max string size -1]
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
@get item name from ID, takes r0 = item ID
@once again irrelavent
bl build_str_item
....
....
@some operations occur for R6 = next item
...
...
cmp r6, Amount of items
blo loop
exit:
@This function also handles the cancel string and a few others which aren't related
@to the bag's pocket space such as the word cancel. But they are irrelevant for this hack
pop {r4-rx, lr}
This code is not EXACTLY what's there. I've simplified it so it's easier to understand. You're interested in the :
Code:
@here is the math you're interested in changing
@make r4 at the end = [max string size -1]
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
portion of the above code. This happens exactly at 08108450.
Then I write this to 08800070: (I think the registers I used are safe because they will be refreshed after bx r0)
Code:
.thumb
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new codes start
mov r1, #0x13
ldr r3, labeltwo @call the divmod function1 in the ROM
bl div
mov r1, #0x6 @For test I have even changed it to 5 instead but also failed
mul r0, r1
add r4, r4, r0
ldr r0, label
bx r0
div:
bx r3
.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
After done these the first item name is right but after that other items are piles of "?" or other item names.
Could you tell me where I made a mistake?
P.S. This is the memory data, after some strings loaded.
You can see that the data are messed up.
Then I write this to 08800070: (I think the registers I used are safe because they will be refreshed after bx r0)
Code:
.thumb
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new codes start
mov r1, #0x13
ldr r3, labeltwo @call the divmod function1 in the ROM
bl div
mov r1, #0x6 @For test I have even changed it to 5 instead but also failed
mul r0, r1
add r4, r4, r0
ldr r0, label
bx r0
div:
bx r3
.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
After done these the first item name is right but after that other items are piles of "?" or other item names.
Could you tell me where I made a mistake?
P.S. This is the memory data, after some strings loaded.
You can see that the data are messed up.
Hey, first of all, if you changed 0x331 to 0x408, then by definition your string sizes are 23 + 0xFF bytes long. Now, if we go over to this:
Code:
.thumb
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new codes start
mov r1, #0x13
ldr r3, labeltwo @call the divmod function1 in the ROM
bl div
mov r1, #0x6 @For test I have even changed it to 5 instead but also failed
mul r0, r1
add r4, r4, r0
ldr r0, label
bx r0
div:
bx r3
.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
You've kept the original math. This math basically is a calculation to add 13 to a RAM offset. Since our string is now 23 chars + 1 long, then all we'd need to do is add 0xA to whatever the result of that old math was.
try:
Code:
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
add r4, r4, #0xA @just increase size of next string by 10
There's also one more thing I forgot to mention. For the cancel string, it's also done in the same function, in the same method. You'd want to edit that part too.
Unedited code:
Actually on second look, I now see that this function handles a lot lot more. I'm unsure without proper debugging/research if the remaining code is relevant to the string. It seems like it's for browsing/oam display and basic bag exploration handling. Anyways, try the above fixes and report back.
Hey, first of all, if you changed 0x331 to 0x408, then by definition your string sizes are 23 + 0xFF bytes long. Now, if we go over to this:
Code:
.thumb
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new codes start
mov r1, #0x13
ldr r3, labeltwo @call the divmod function1 in the ROM
bl div
mov r1, #0x6 @For test I have even changed it to 5 instead but also failed
mul r0, r1
add r4, r4, r0
ldr r0, label
bx r0
div:
bx r3
.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
You've kept the original math. This math basically is a calculation to add 13 to a RAM offset. Since our string is now 23 chars + 1 long, then all we'd need to do is add 0xA to whatever the result of that old math was.
try:
Code:
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
add r4, r4, #0xA @just increase size of next string by 10
There's also one more thing I forgot to mention. For the cancel string, it's also done in the same function, in the same method. You'd want to edit that part too.
Unedited code:
Actually on second look, I now see that this function handles a lot lot more. I'm unsure without proper debugging/research if the remaining code is relevant to the string. It seems like it's for browsing/oam display and basic bag exploration handling. Anyways, try the above fixes and report back.
If it is right, I've found that the text strings are messed up, like in the first case: (As you see not only the "cancel" cause problem)
(I've underlined the problems)
I will update the post after setting the branch in the new function you found.
======================================================================
After that I have done the branch:
@0810848C:
If it is right, I've found that the text strings are messed up, like in the first case: (As you see not only the "cancel" cause problem)
(I've underlined the problems)
I will update the post after setting the branch in the new function you found.
======================================================================
After that I have done the branch:
@0810848C:
I'd prefer the latter, as a solution like "compile XX at XX" does not make sense. But I have no idea now, as the code is too complex and I often do not know what it's doing...... So could you give me some hints so I can continue working on it? That will be really appreciated. :D And I'm very curious about how you get what the code is doing as it's so huge when I'm looking in VBA's disassembler.
Thank you for your help!
I'd prefer the latter, as a solution like "compile XX at XX" does not make sense. But I have no idea now, as the code is too complex and I often do not know what it's doing...... So could you give me some hints so I can continue working on it? That will be really appreciated. :D And I'm very curious about how you get what the code is doing as it's so huge when I'm looking in VBA's disassembler.
Thank you for your help!
When looking in VBA's disassembler, you're looking at the entire game in asm. That's not great if you're trying to learn anything, it's great for looking at small pieces of code when you know where they are.
Even still, it's best using a debugger or an idb so you can see the stuff better and you will understand it. Most ASM hackers do not even touch VBA's disassembler. I only use it when I compile C to ASM and something goes wrong.
I'd prefer the latter, as a solution like "compile XX at XX" does not make sense. But I have no idea now, as the code is too complex and I often do not know what it's doing...... So could you give me some hints so I can continue working on it? That will be really appreciated. :D And I'm very curious about how you get what the code is doing as it's so huge when I'm looking in VBA's disassembler.
Thank you for your help!
I use VBA's disassembler in conjunction with VBA-SDL-H only (or IDA). But IDA is generally many times better than VBA's for most situations. Knowing what the code does at a glance is somewhat from experience of doing it so many times.
For your hints, examine the code inbetween the cancel string generation and the item string loop. You'll notice that R5 is used and the RAM offset is written to again.
When looking in VBA's disassembler, you're looking at the entire game in asm. That's not great if you're trying to learn anything, it's great for looking at small pieces of code when you know where they are.
Even still, it's best using a debugger or an idb so you can see the stuff better and you will understand it. Most ASM hackers do not even touch VBA's disassembler. I only use it when I compile C to ASM and something goes wrong.
VBA's disassembler is best used in conjunction with VBA-SDL-H or some debugger. You can also use it to find faulty branches and such. But, yeah, in general it's not a good idea to use solely VBA (even though that's what I used when I started).
When looking in VBA's disassembler, you're looking at the entire game in asm. That's not great if you're trying to learn anything, it's great for looking at small pieces of code when you know where they are.
Even still, it's best using a debugger or an idb so you can see the stuff better and you will understand it. Most ASM hackers do not even touch VBA's disassembler. I only use it when I compile C to ASM and something goes wrong.
I use VBA's disassembler in conjunction with VBA-SDL-H only (or IDA). But IDA is generally many times better than VBA's for most situations. Knowing what the code does at a glance is somewhat from experience of doing it so many times.
For your hints, examine the code inbetween the cancel string generation and the item string loop. You'll notice that R5 is used and the RAM offset is written to again.
Thank you for your hint, I will try when I have free time. (Now I have Calculus to do) You have recommended IDA to us newbies several times but there seems no tutorial to teach us how to use that. TAT
Thank you, but I have no idea about how to use idb file as I don't know how to use IDA at all and there seems no tutorial.
Thank you for your hint, I will try when I have free time. (Now I have Calculus to do) You have recommended IDA to us newbies several times but there seems no tutorial to teach us how to use that. TAT
After an hour's research, I've found something really funny.
(I changed 3 item names into pointers, as you can see)
This can be done by using no$gba's function of changing the value of registers.
I will explain what I did:
add breakpoint at 08108450 and 0810848C(for the sake of cancel):
these two places do such math calculations, as you know before.
After calculation r4's value will change each time the 2 functions are called.
If after each calculation I modify r4 to 0, 0x19, 0x19 * 2, 0x19 * 3......
The item will be shown correctly as the image showed.
However when it comes to a routine it all messed up and I really don't know the reason because I think they do the same thing.
This is my routine.
Code:
.thumb
@at 0x08800070, branch from the function you know
lsl r2, r6, #0x2 @original code
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new code start, parameter1
mov r1, #0x13 @parameter2
ldr r3, labeltwo @function pointer
bl div @call the div function
mov r1, #0x19
mul r0, r1
mov r4, r0
ldr r0, label
bx r0 @back to the original code
div:
bx r3
.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
Code:
.thumb
@This code is at 0x08800100 as I did before, branch from the function you know
ldr r5, =0x203AD1C
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4
mov r1, #0x13
ldr r3, label
bl div
mov r1, #0x19
mul r0, r1
mov r4, r0
ldr r0, back
bx r0
div:
bx r3
.align 2
label:
.word 0x081E4019
back:
.word 0x08108497
I'm very confused as I think the function does the same thing as changing value of r4, and I think the registers I use are safe.
Maybe you can find my problem?
After an hour's research, I've found something really funny.
(I changed 3 item names into pointers, as you can see)
This can be done by using no$gba's function of changing the value of registers.
I will explain what I did:
add breakpoint at 08108450 and 0810848C(for the sake of cancel):
these two places do such math calculations, as you know before.
After calculation r4's value will change each time the 2 functions are called.
If after each calculation I modify r4 to 0, 0x19, 0x19 * 2, 0x19 * 3......
The item will be shown correctly as the image showed.
However when it comes to a routine it all messed up and I really don't know the reason because I think they do the same thing.
This is my routine.
Code:
.thumb
@at 0x08800070, branch from the function you know
lsl r2, r6, #0x2 @original code
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new code start, parameter1
mov r1, #0x13 @parameter2
ldr r3, labeltwo @function pointer
bl div @call the div function
mov r1, #0x19
mul r0, r1
mov r4, r0
ldr r0, label
bx r0 @back to the original code
div:
bx r3
.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
Code:
.thumb
@This code is at 0x08800100 as I did before, branch from the function you know
ldr r5, =0x203AD1C
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
mov r0, r4
mov r1, #0x13
ldr r3, label
bl div
mov r1, #0x19
mul r0, r1
mov r4, r0
ldr r0, back
bx r0
div:
bx r3
.align 2
label:
.word 0x081E4019
back:
.word 0x08108495
I'm very confused as I think the function does the same thing as changing value of r4, and I think the registers I use are safe.
Maybe you can find my problem?
mov r4, #0x19
mul r4, r4, r6
@r6 is the item counter, so it should increment by one
@if r6 starts at 1, then sub r6, r6, #0x1
@also, this should overwrite the old math
So replace the old code for the math calcs, with this one
mov r4, #0x19
mul r4, r4, r6
@r6 is the item counter, so it should increment by one
@if r6 starts at 1, then sub r6, r6, #0x1
@also, this should overwrite the old math
So replace the old code for the math calcs, with this one
![[PokeCommunity.com] ASM & Disassembly](https://i869.photobucket.com/albums/ab256/jiangzhengwenjz/1_zpsdxhng38d.png "[PokeCommunity.com] ASM & Disassembly")
![[PokeCommunity.com] ASM & Disassembly](https://i869.photobucket.com/albums/ab256/jiangzhengwenjz/_zpsnwcwkxek.png "[PokeCommunity.com] ASM & Disassembly")
![[PokeCommunity.com] ASM & Disassembly](https://i869.photobucket.com/albums/ab256/jiangzhengwenjz/aq_zpse878njle.png "[PokeCommunity.com] ASM & Disassembly")
![[PokeCommunity.com] ASM & Disassembly](https://i869.photobucket.com/albums/ab256/jiangzhengwenjz/1_zpsh80lsofc.png "[PokeCommunity.com] ASM & Disassembly")
![[PokeCommunity.com] ASM & Disassembly](https://i869.photobucket.com/albums/ab256/jiangzhengwenjz/1_zps6w36liif.png "[PokeCommunity.com] ASM & Disassembly")