Help Thread ASM & Disassembly Page 23

Started by Spherical Ice December 1st, 2014 11:05 AM
  • 65283 views
  • 626 replies
Seen November 20th, 2016
Posted November 20th, 2016
417 posts
8.2 Years
Uhm... Help? :(

I'm trying to assemble the routine written here by azurile13 but when I try to drag in onto the compiler/assembler, all it gives me is a 127mb sized .bin file. I'm doing it wrong, am I not?

And if my question didn't make any sense, "How do I assemble this?" pretty much makes the same idea. xDD

Anyways, here's the post about the said routine.
I used .org because it was bl'ing the malloc. It pads the file with zeroes. Basically, go to the end of the bin and copy the bytes there to the corresponding address in your ROM (ignoring the 0x8000000 for ROM, which I just type out of habit and really doesn't need to be there and is currently only inflating the bin by a gigantic amount). Btw, that post alone doesn't change the item cap. I alluded to it, but you also need to change that other routine mentioned in the post, which I should have made clearer but was probably lazy. I think I'll edit that it the next time I'm on a computer.
Age 25
Male
Seen 2 Weeks Ago
Posted September 2nd, 2020
534 posts
10.7 Years
I used .org because it was bl'ing the malloc. It pads the file with zeroes. Basically, go to the end of the bin and copy the bytes there to the corresponding address in your ROM (ignoring the 0x8000000 for ROM, which I just type out of habit and really doesn't need to be there and is currently only inflating the bin by a gigantic amount). Btw, that post alone doesn't change the item cap. I alluded to it, but you also need to change that other routine mentioned in the post, which I should have made clearer but was probably lazy. I think I'll edit that it the next time I'm on a computer.
Okay, I've done that and edited parts of the routine at 0x99E44 (namely, 0x99E52 - new item cap., 0x99E56 - new item cap. * 4, and 0x99E7C - new item cap. +1). When I played the game, it doesn't crash anymore BUT alas! Bag was messed up! The regular items pocket merged with the key items pocket (key items are in the regular items pocket), Key Items Pocket is Empty, TMs went to the Pokeballs Pocket and my Pokeballs, gone. Is there a different byte that I should've changed? Like a limiter of some sort. I'm sorry for bugging out on this. I just want to learn how this works. :(
Seen November 20th, 2016
Posted November 20th, 2016
417 posts
8.2 Years
Okay, I've done that and edited parts of the routine at 0x99E44 (namely, 0x99E52 - new item cap., 0x99E56 - new item cap. * 4, and 0x99E7C - new item cap. +1). When I played the game, it doesn't crash anymore BUT alas! Bag was messed up! The regular items pocket merged with the key items pocket (key items are in the regular items pocket), Key Items Pocket is Empty, TMs went to the Pokeballs Pocket and my Pokeballs, gone. Is there a different byte that I should've changed? Like a limiter of some sort. I'm sorry for bugging out on this. I just want to learn how this works. :(
I remember now - I think I didn't explain the 0x99E44 routine because I posted an explanation of it elsewhere around the same time period. Not the smartest decision on my part to not even link it in the post, but after some digging, here it is: http://www.pokecommunity.com/showpost.php?p=9014911&postcount=2018
Your bag is mixing items because all items pockets are handled in that routine, not just general items. As a result, they will overlap. If you have some ASM knowledge, I think that post should let you know how you'll need to modify 0x99E44. If you don't, this is a nice learning experience ;) No need to apologize. Feel free to ask questions if you run into any more problems - if I didn't want to answer questions, I would have just posted a routine for you and been done with this topic, but I think its better when people actually understand what they're putting in their ROMs.
Male
Seen 1 Day Ago
Posted December 26th, 2022
175 posts
10.7 Years
Just a quote
Hi! I want to ask a question about using bitfields as u32 vars in C.
(Yes, I know you don't understand what I'm speaking of, so let's take an example)
This is the bitfield of DMA config data:
/*From Nintendo*/
struct DMACNT
{
    u16 Count;              // Transfer Count
    u16 Dummy_21_16:5;
    u16 DestpCnt:2;         // Destination Address Control
    u16 SrcpCnt:2;          // Source Address Control
    u16 ContinuousON:1;     // Continuous Mode
    u16 BusSize:1;          // Bus Size 16/32Bit Select
    u16 DataRequest:1;      // Data Request Synchronize Mode
    u16 Timming:2;          // Timing Select
    u16 IF_Enable:1;        // Interrupt Request Enable
    u16 Enable:1;           // DMA Enable
};
and we use cast here:
struct DMACNT *DMA3CNT = (struct DMACNT *)0x40000DC;
Then here comes the question:
How to exceed such effect via it in C?
ldr r0, =0x40000DC
ldr r1, =0x81000800
str r1, [r0]
If we use u32 value for 0x81000800, the code is extremely simple, but not clear.
So is it a way to use the struct as u32 value? (I think there's a way, otherwise there's no need to include the bitfields)

Blah

Free supporter

Male
Unknown Island
Seen 52 Minutes Ago
Posted February 28th, 2023
1,924 posts
10.3 Years
Hi! I want to ask a question about using bitfields as u32 vars in C.
(Yes, I know you don't understand what I'm speaking of, so let's take an example)
This is the bitfield of DMA config data:
/*From Nintendo*/
struct DMACNT
{
    u16 Count;              // Transfer Count
    u16 Dummy_21_16:5;
    u16 DestpCnt:2;         // Destination Address Control
    u16 SrcpCnt:2;          // Source Address Control
    u16 ContinuousON:1;     // Continuous Mode
    u16 BusSize:1;          // Bus Size 16/32Bit Select
    u16 DataRequest:1;      // Data Request Synchronize Mode
    u16 Timming:2;          // Timing Select
    u16 IF_Enable:1;        // Interrupt Request Enable
    u16 Enable:1;           // DMA Enable
};
and we use cast here:
struct DMACNT *DMA3CNT = (struct DMACNT *)0x40000DC;
Then here comes the question:
How to exceed such effect via it in C?
ldr r0, =0x40000DC
ldr r1, =0x81000800
str r1, [r0]
If we use u32 value for 0x81000800, the code is extremely simple, but not clear.
So is it a way to use the struct as u32 value? (I think there's a way, otherwise there's no need to include the bitfields)
Hi Jiang, you can achieve this with some casting or the use of a union.

union DMACNT {
    u32 u_DMACNT;
    struct s_DMACNT st_DMACNT;
};
Something like that.
...
Age 25
Male
Seen 2 Weeks Ago
Posted September 2nd, 2020
534 posts
10.7 Years
I remember now - I think I didn't explain the 0x99E44 routine because I posted an explanation of it elsewhere around the same time period. Not the smartest decision on my part to not even link it in the post, but after some digging, here it is: http://www.pokecommunity.com/showpost.php?p=9014911&postcount=2018
Your bag is mixing items because all items pockets are handled in that routine, not just general items. As a result, they will overlap. If you have some ASM knowledge, I think that post should let you know how you'll need to modify 0x99E44. If you don't, this is a nice learning experience ;) No need to apologize. Feel free to ask questions if you run into any more problems - if I didn't want to answer questions, I would have just posted a routine for you and been done with this topic, but I think its better when people actually understand what they're putting in their ROMs.
Okay, since I don't have *that* much knowledge about ASM, here's another question. The bag is not so messed up now except that some Key Items are in the General Items Pocket. To avoid that happening, should I repoint the RAM address where the General Items are stored (which is at 0x203988C)? @[email protected]

I have this theory that is a little incomplete:

Since I increased the General Items Pocket's Capacity to 0x3C (60) which is 0x12 more than the original 0x2A (42), I'm guessing I either have to adjust the offsets of the next pockets' addresses to make room for the new 0x12 general items OR repoint where the General Items are stored to a free space in the save data (which is I am not really knowledgable). The problem is, I don't know which offsets I have to change for the former since the comment and the content in a hex editor is unequal which is so confusing. @[email protected]
Seen November 20th, 2016
Posted November 20th, 2016
417 posts
8.2 Years
Okay, since I don't have *that* much knowledge about ASM, here's another question. The bag is not so messed up now except that some Key Items are in the General Items Pocket. To avoid that happening, should I repoint the RAM address where the General Items are stored (which is at 0x203988C)? @[email protected]

I have this theory that is a little incomplete:

Since I increased the General Items Pocket's Capacity to 0x3C (60) which is 0x12 more than the original 0x2A (42), I'm guessing I either have to adjust the offsets of the next pockets' addresses to make room for the new 0x12 general items OR repoint where the General Items are stored to a free space in the save data (which is I am not really knowledgable). The problem is, I don't know which offsets I have to change for the former since the comment and the content in a hex editor is unequal which is so confusing. @[email protected]
Right, so basically what is happening is because you've changed the length of what is read for general items but haven't moved where key items start, your key items are being read in the general list. I'm not really sure how to explain this more precisely, so maybe you could post your the routine you tried? It would be easier to explain with concrete addresses than in the abstract.
Age 25
Male
Seen 2 Weeks Ago
Posted September 2nd, 2020
534 posts
10.7 Years
Right, so basically what is happening is because you've changed the length of what is read for general items but haven't moved where key items start, your key items are being read in the general list. I'm not really sure how to explain this more precisely, so maybe you could post your the routine you tried? It would be easier to explain with concrete addresses than in the abstract.
I didn't actually edit the routine, just hex edit because I don't know how to rip the routine. :( And the only part that I actually changed is:
ROM:08099E52                 MOVS    R0, #0x2A @ '*'    @#42 (changed to 3C for 60 items)
And the following (bracketed and bold) are what I changed to accommodate the new 0x12 items but apparently messed up the bag.
ROM:08099E56                 ADDS    R3, #0xA8 @ '¿'     @0x3B8; offset of key items [changed to A8+12=BA]
ROM:08099E60                 ADDS    R3, #0x78 @ 'x'     @0x430; offset of pokeballs [changed to 78+12=8A]
ROM:08099E6A                 ADDS    R3, #0x34 @ '4'    @0x464; offset of TMs/HMs [changed to 34+12=46]
ROM:08099E74                 LDR     R0, =0x54C             @0x54C, offset of berries [this one I am unsure of because in a hex editor, it's 05 48]
And then these ones are what I am really not sure because however I think of it, I don't see a connection between the [R1]'s and it's value on a hex editor.
ROM:08099E50                 STR     R0, [R1]            @store address of general items at 0x203988C 
ROM:08099E5A                 STR     R0, [R1,#8]    @store address of key items at 0x2039894 [0x88 in a hex editor, maybe I should +0x12 this?]
ROM:08099E64                 STR     R0, [R1,#0x10]    @store address of pokeballs at 0x203989C [0x8 in a hex editor]
ROM:08099E6E                 STR     R0, [R1,#0x18]    @store address of TMs/HMs at 0x20398A4 [0x88 in a hex editor]
ROM:08099E78                 STR     R2, [R1,#0x20]    @store address of berries at 0x20398AC [0xA in a hex editor]
Seen November 20th, 2016
Posted November 20th, 2016
417 posts
8.2 Years
I didn't actually edit the routine, just hex edit because I don't know how to rip the routine. :( And the only part that I actually changed is:
ROM:08099E52                 MOVS    R0, #0x2A @ '*'    @#42 (changed to 3C for 60 items)
And the following (bracketed and bold) are what I changed to accommodate the new 0x12 items but apparently messed up the bag.
ROM:08099E56                 ADDS    R3, #0xA8 @ '¿'     @0x3B8; offset of key items [changed to A8+12=BA]
ROM:08099E60                 ADDS    R3, #0x78 @ 'x'     @0x430; offset of pokeballs [changed to 78+12=8A]
ROM:08099E6A                 ADDS    R3, #0x34 @ '4'    @0x464; offset of TMs/HMs [changed to 34+12=46]
ROM:08099E74                 LDR     R0, =0x54C             @0x54C, offset of berries [this one I am unsure of because in a hex editor, it's 05 48]
And then these ones are what I am really not sure because however I think of it, I don't see a connection between the [R1]'s and it's value on a hex editor.
ROM:08099E50                 STR     R0, [R1]            @store address of general items at 0x203988C 
ROM:08099E5A                 STR     R0, [R1,#8]    @store address of key items at 0x2039894 [0x88 in a hex editor, maybe I should +0x12 this?]
ROM:08099E64                 STR     R0, [R1,#0x10]    @store address of pokeballs at 0x203989C [0x8 in a hex editor]
ROM:08099E6E                 STR     R0, [R1,#0x18]    @store address of TMs/HMs at 0x20398A4 [0x88 in a hex editor]
ROM:08099E78                 STR     R2, [R1,#0x20]    @store address of berries at 0x20398AC [0xA in a hex editor]
Okay I see something. You say stuff like "A8+12=BA"
But 0x12 is the number of items, right? You're adding 0x12 items, but each one is taking up 4 bytes. So you'd actually have to do 0x12 times four = 72 = 0x48.
But forget that for a moment. Forget about hex editing and forget about trying to copy the format of the routine in the game for the moment. Do you know how to write a routine? If not, I can help walk you through it. Because all that you should really care about is this:
At the end routine, the following offsets should contain the important offsets/quantities:
0x203988C: offset of general items
0x2039890: maximum number of held items
0x2039894: offset of key items
0x2039898: maximum number of key items
0x203989C: offset of pokeballs
0x20398A0: maximum number of pokeballs
0x20398A4: offset of TMs/HMs
0x20398A8: maximum number of TMs/HMs
0x20398AC: offset of berries
0x20398B0: maximum number of berries
I think that looking at the hex and attempting to change the code byte by byte is a waste and only serves to create extra work.
Age 25
Male
Seen 2 Weeks Ago
Posted September 2nd, 2020
534 posts
10.7 Years
Okay I see something. You say stuff like "A8+12=BA"
But 0x12 is the number of items, right? You're adding 0x12 items, but each one is taking up 4 bytes. So you'd actually have to do 0x12 times four = 72 = 0x48.
Oh crap. And all this time I thought that was 0x203988C + something = position of the next pocket. :( I thought so.
Do you know how to write a routine? If not, I can help walk you through it. Because all that you should really care about is this:I think that looking at the hex and attempting to change the code byte by byte is a waste and only serves to create extra work.
Uhm... Just a tiny bit. And all the routine that I ever did from scratch was a multiply variables and a change gender routine, both of which were based off of FBI's examples. I'd be really glad if you'd walk me through it! :D
Seen November 20th, 2016
Posted November 20th, 2016
417 posts
8.2 Years
Not entirely sure if I should post it here, but is there any replacement for IDA on linux or should I just use wine?
I'm not sure. But one thing that I'd point out is that it isn't just about IDA itself. One of the biggest draws is being able to use knizz's idb. The power comes from the documentation in that specific file. So there may be some other good interactive disassembler (no clue), but it would be pointless if it couldn't also read the FireRed idb (or Emerald). Use wine :D

C me

Creator of Pokemon League Of Legends

Age 26
Male
Seen April 9th, 2021
Posted September 9th, 2018
681 posts
9.3 Years
So the last thing I need for my hack now is to fix status effects. I've been looking at the setrest routine because it always sets the sleep turns to 3. In Emerald it's at 0x050528.

I've found the length that you sleep for is determined by the byte at 0x0505C3 because of the mov r1, #0x3. But what I don't understand is where in RAM this number is stored because surely each turn it goes down and the game checks to see how many turns are left. The RAM locations in the routine are just the common ones like userbank and CurrentBS, nothing that relates to the sleep length.

Eventually I'd like to change the main status effects to last for a set number of turns like in rest instead of lasting forever or having a random chance of wearing off.

It would be really cool if someone could help me understand how to go about doing this and if there is an easier way to do it.
Seen June 7th, 2016
Posted June 4th, 2016
4 posts
7 Years
I posted this over in the quick questions and answers, but I'm not sure if it's the right place since it's related to the Pokemon Crystal disassembly.

I'm farily decent when it comes to programming, or at least editing and adding scripts to the already existing assembly code, but I just can't figure out how I'm supposed to edit or add maps in the Pokecrystal Disassembly.

I can't find any guides, nothing at all anywhere on the internet. I'm sure if I should kick myself in the head for not being able to google or if they just don't exist at all.

I supposed these were contained in the .blk files, but I have no way of editing them. I read some people saying that they used Crystalmap to do this, but even then they didn't explain how crystalmap is used at all, and since the program is used to edit an already existing ROM instead of the source code it's not very helpful in my case.

If anyone can steer me in the right direction or can be kind enough to help me on this front they'd have my eternal gratitude.

Once again sorry if I posted this in two threads, I wasn't sure which one was the right one as this seems to be more code-oriented.
Seen June 7th, 2016
Posted June 4th, 2016
4 posts
7 Years
I found out the answer to my above question, I'm just going to write it here so that maybe someone in my same situation will have a solution ready.

To edit maps in pokecrystal, look for crowdmap, it uncompresses the tilesets and has a WYSIWYG map and event editor.

Moving to something else, any tips on replacing tilesets? As of now, even with the uncompressed tilesets, they're all messed up and it's really hard to make out what's on them. Is there any easier way to fix this or do I just need to edit them as they are?
Male
Antarctica
Seen April 1st, 2020
Posted September 26th, 2017
326 posts
9.1 Years
So recently I've been trying to port my project over to FBI's empty template, found here. I can get it to compile after changing the path in insert2, but how would I write hooks? The hooks file doesn't seem to do anything, because the only place that is changed is the offset specified in linker.ld.

As an alternative, I've looked at armips, but I'm not quite sure how to handle it. I want to use 0.8 because it has more features, but right now I'm not sure how to get it in its .exe form. Any idea how to properly make it? The link is here.

C me

Creator of Pokemon League Of Legends

Age 26
Male
Seen April 9th, 2021
Posted September 9th, 2018
681 posts
9.3 Years
I'm having a problem with this routine in Emerald.

Spoiler:
main:
push {r0-r2, lr}
@derive 0x867 in register r0, first badge
mov r0, #0xFF
mov r1, #0x8
mul r0, r0, r1
add r0, r0, #0x30
@this is how we call the function
ldr r1, =(0x809D790 +1)
bl linker
@check if set or not
cmp r0, #0x0
beq set
add r0, r0, #0x1
cmp r0, #0x0
beq set2
add r0, r0, #0x1
cmp r0, #0x0
beq set3
add r0, r0, #0x1
cmp r0, #0x0
beq set4
add r0, r0, #0x1
cmp r0, #0x0
beq set5
add r0, r0, #0x1
cmp r0, #0x0
beq set6
add r0, r0, #0x1
cmp r0, #0x0
beq set7
add r0, r0, #0x1
cmp r0, #0x0
beq set8
ldr r1, .BS1
b End
pop {r0-r2, pc}

linker:
bx r1

set:
b End

set2:
ldr r1, .BS2
b End

set3:
ldr r1, .BS3
b End

set4:
ldr r1, .BS4
b End

set5:
ldr r1, .BS5
b End

set6:
ldr r1, .BS6
b End

set7:
ldr r1, .BS7
b End

set8:
ldr r1, .BS8
b End
End:
sub r1, #0x5
ldr r0, .ScriptPointer
str r1, [r0]
bx lr
pop {r0-r2, pc}

.align 2
.ScriptPointer: .word 0x02024214
.BS1: .word 0x83ED960
.BS2: .word 0x83ED970
.BS3: .word 0x83ED980
.BS4: .word 0x83ED990
.BS5: .word 0x83ED9A0
.BS6: .word 0x83ED9B0
.BS7: .word 0x83ED9C0
.BS8: .word 0x83ED9D0
It's supposed to check for the first gym badge (flag 0x867), then if it's set it checks for the other gym badges. It then branches to a script which adds 5 to the base power ram location 0x02024400 per badge. This is to increase the base power of a move as you progress through the game. The asm is called before the damagecalculation.

Currently it just freezes the game. What's wrong with it?
Male
Antarctica
Seen April 1st, 2020
Posted September 26th, 2017
326 posts
9.1 Years
I'm having a problem with this routine in Emerald.

[massive wall of text]

It's supposed to check for the first gym badge (flag 0x867), then if it's set it checks for the other gym badges. It then branches to a script which adds 5 to the base power ram location 0x02024400 per badge. This is to increase the base power of a move as you progress through the game. The asm is called before the damagecalculation.

Currently it just freezes the game. What's wrong with it?
As far as I can see, there are a couple of small problems with this routine, as well as some things that we don't know. First of all, where are you hooking from? We need to know the offset of the hook.

The first problem with this routine is that you don't actually get 0x867 into r0 in the very beginning.
.thumb

start:
    mov r0, #0x86
    lsl r0, r0, #0x4
    add r0, r0, #0x7
This is what you should be doing to get 0x867 into r0.

In addition, some things are rather confusing. What is the function at 0x809D790? I know this is the get_flag address, but that's because I went and checked. You should use a label. Your first check is wrong as well. If you wanted to jump to the end if the first flag's not set, then just jump to the end rather than jumping to somewhere that jumps to the end.

What I think you're trying to do; get the first flag in r0, then seeing if that flag is set. If it is, check to see if the next flag is set, otherwise jump to the first battlescript. If the second badge is set, check the third badge, etc.

What you're actually doing; loading a flag into r0, then comparing that. If it is set, then it'll continue to add 1 to the result of the the function you called earlier. This will either cause only the first or second check to actually result in anything.

My suggestion; drop the battlescript, it's rather complicated to call a battlescript in a function. Instead, read and write directly to that offset. Also, edit your checks and your flag checks.
start:
push
load byte from base_power(0x02024400) into r5
get flag in both r0 and r4
bl to flag_check
check if the flag was set
if it wasn't, b to the_end
add five to r5
add 1 to r4
bl to flag_check
check to see if second flag was set
if it wasn't b to the_end
add five to r5
add 1 to r4, then bl to flag_check
(you can do this until you checked all your flags)

the_end:
store r5 in 0x02024400
pop

flag_check:
move r4 to r0
make r1 0x0809D790 + 1
bx r1
This is kinda sloppy and can be done by a loop, but once you make a routine resembling this, I'll show you how to make this into a loop.

~EDIT~ Oh yeah and just as a reminder, you should add a check to make sure that this routine only does this to one move or else you'll be increasing the power of every move. In addition, the AI will calculate how to use that move based on its original base power, and will get the same bonus that you do when using this move.

C me

Creator of Pokemon League Of Legends

Age 26
Male
Seen April 9th, 2021
Posted September 9th, 2018
681 posts
9.3 Years
As far as I can see, there are a couple of small problems with this routine, as well as some things that we don't know. First of all, where are you hooking from? We need to know the offset of the hook.
It's not being hooked from anywhere, it's being callasmd in a unique move effect.

The first problem with this routine is that you don't actually get 0x867 into r0 in the very beginning.
.thumb

start:
    mov r0, #0x86
    lsl r0, r0, #0x4
    add r0, r0, #0x7
This is what you should be doing to get 0x867 into r0.
(Why was I looking for 867 instead of 0x867? derp) I don't understand the maths here. What does the lsl line do that mul r0, #0x10 wouldn't do?

My suggestion; drop the battlescript, it's rather complicated to call a battlescript in a function. Instead, read and write directly to that offset. Also, edit your checks and your flag checks.
start:
push
load byte from base_power(0x02024400) into r5
get flag in both r0 and r4
bl to flag_check
check if the flag was set
if it wasn't, b to the_end
add five to r5
add 1 to r4
bl to flag_check
check to see if second flag was set
if it wasn't b to the_end
add five to r5
add 1 to r4, then bl to flag_check
(you can do this until you checked all your flags)

the_end:
store r5 in 0x02024400
pop

flag_check:
move r4 to r0
make r1 0x0809D790 + 1
bx r1
This is kinda sloppy and can be done by a loop, but once you make a routine resembling this, I'll show you how to make this into a loop.
I didn't know it was possible to write to a byte directly. What would be the point in loading the byte then doing the addition? Wouldn't it be simpler to just write the base power value? Then the summary screen value won't be confusing (Since the bp value will be --- and some npc will just tell the player that it changes per badge)

~EDIT~ Oh yeah and just as a reminder, you should add a check to make sure that this routine only does this to one move or else you'll be increasing the power of every move. In addition, the AI will calculate how to use that move based on its original base power, and will get the same bonus that you do when using this move.
It would only affect the moves with the move effect that calls the routine so it should be fine. AI will be AI, can't do much with that. I don't mind the AI having the same bonus, the badge thing is just a good measurement of game progression so it makes sense that the AI's attacks would hurt more too.

pokedude9

Creator (with Diego) of AME and ASE

Male
Seen January 1st, 2017
Posted December 28th, 2016
31 posts
7 Years
(Why was I looking for 867 instead of 0x867? derp) I don't understand the maths here. What does the lsl line do that mul r0, #0x10 wouldn't do?
MUL requires a second register that contains 0x10 as value already, whereas LSL accepts immediate values.
Male
Antarctica
Seen April 1st, 2020
Posted September 26th, 2017
326 posts
9.1 Years
It's not being hooked from anywhere, it's being callasmd in a unique move effect.
Ah, ok. I didn't know that.

(Why was I looking for 867 instead of 0x867? derp) I don't understand the maths here. What does the lsl line do that mul r0, #0x10 wouldn't do?
I looked at it on a bitwise level. 0x86 is 10000110b, and 7 is 0111b. Because mov only accepts one byte, I loaded 0x86 into r0. Then I shifted it to the left by four spaces(note that 7 takes up four spaces). This makes 0x860. Adding 7 is obvious after that. It's shorter, and yeah, pokedude9 is right.

I didn't know it was possible to write to a byte directly. What would be the point in loading the byte then doing the addition? Wouldn't it be simpler to just write the base power value? Then the summary screen value won't be confusing (Since the bp value will be --- and some npc will just tell the player that it changes per badge)
You can store a byte, a half-word, or a word with strb, strh, and str respectively. Sometimes this is difficult becuase of malloc-ing, but the BP is stored in one location.
I see, I thought you had a set base power like 50 for 0 badges and then added to it every time rather than it being null. In that case, load the base power of 0 badges into r5 in the beginning rather than loading from 0x02024400, and then you can add as you go along.

It would only affect the moves with the move effect that calls the routine so it should be fine. AI will be AI, can't do much with that. I don't mind the AI having the same bonus, the badge thing is just a good measurement of game progression so it makes sense that the AI's attacks would hurt more too.
K, just wanted to make sure I understood.

C me

Creator of Pokemon League Of Legends

Age 26
Male
Seen April 9th, 2021
Posted September 9th, 2018
681 posts
9.3 Years
start:
push
load byte from base_power(0x02024400) into r5
get flag in both r0 and r4
bl to flag_check
check if the flag was set
if it wasn't, b to the_end
add five to r5
add 1 to r4
bl to flag_check
check to see if second flag was set
if it wasn't b to the_end
add five to r5
add 1 to r4, then bl to flag_check
(you can do this until you checked all your flags)

the_end:
store r5 in 0x02024400
pop

flag_check:
move r4 to r0
make r1 0x0809D790 + 1
bx r1
So I've translated most of your example. I've highlighted the ones I can't get.

Spoiler:
start:
push {r0-r5, lr}
mov r5, #0x3C @0 badge base power
mov r4, #0x86 @puts 0x867
lsl r0, r4, #0x4 @into
add r0, r4, #0x7 @r4
bl flag_check
cmp r1, #0x0 @if the flag isn't set
beq the_end @ go to the_end
add r0, r5, #0x5 @adds 5 to the base power
add r0, r4, #0x1
bl flag_check @pretty much the same from here
cmp r1, #0x0
beq the_end
add r0, r5, #0x5
add r0, r4, #0x1
bl flag_check
cmp r1, #0x0
beq the_end
add r0, r5, #0x5
add r0, r4, #0x1
bl flag_check
cmp r1, #0x0
beq the_end
add r0, r5, #0x5
add r0, r4, #0x1
bl flag_check
cmp r1, #0x0
beq the_end
add r0, r5, #0x5
add r0, r4, #0x1
bl flag_check
cmp r1, #0x0
beq the_end
add r0, r5, #0x5
add r0, r4, #0x1
bl flag_check
cmp r1, #0x0
beq the_end
add r0, r5, #0x5
add r0, r4, #0x1
bl flag_check
cmp r1, #0x0
beq the_end
add r0, r5, #0x5
add r0, r4, #0x1
b the_end @don't need more flag checks


the_end:
ldrb r5, =(0x02024400) @I think this stores
strb r0, [r5] @r5 into 02024400?

pop {r0-r5, lr}

flag_check:
move r4 to r0 @I thought mov only worked with a value so I don't know what to do here.
ldr r1, =(0x809D790 +1) @makes r1 0x0809D790 + 1
bx r1


I think everything else is fine.