Help Thread: ASM & Disassembly

[Blah]

Hm it still ended up with the same error, I'm guessing it's still a register clash - at least its not just aborting now though I suppose!

.text
.align 2
.thumb
.thumb_func

main: 
	lsr r7, r0, #0x18
	mov r0, r9
	ldrb r1, [r0] /*replacements for bits my hook overwrites*/
	push {r0-r3}
	mov r2, #0xFF
	lsl r2, r0, #0x6
	add r2, #0xC0
	ldr r3, =(0x806E454 +1)
	bl linker
	ldrh r3, [r0]
	add r3, #0x4
	strh r3, [r0]
	pop {r0-r3}
	ldr r0, =(0x80d83f0 +1)
	bx r0

.align 2
linker:
	bx r3

Oh wow, I see now. The original code does a "bl" to 0x80D83F0 +1. You're doing a bx.

.text
.align 2
.thumb
.thumb_func

main: 
	lsr r7, r0, #0x18
	mov r0, r9
	ldrb r1, [r0] /*replacements for bits my hook overwrites*/
	push {r0-r3}
	mov r2, #0xFF
	lsl r2, r0, #0x6
	add r2, #0xC0
	ldr r3, =(0x806E454 +1)
	bl linker
	ldrh r3, [r0]
	add r3, #0x4
	strh r3, [r0]
	pop {r0-r3}
	ldr r0, =(0x80d83f0 +1)
	bl linker2
	ldr r2, =(0x80D788A +1)
	bx r2

.align 2
linker:
	bx r3

linker2:
	bx r0

 

[daniilS]

I told him to use bx because it seems the bl there is only used because it's of a long range

 

[Mana1]

Back again! :) Less of a problem now, slightly different routine too - this one is trying to add 0x1 to variable 0x4080

If my read variable / write to variable section written correctly? In game the rest works (including the strb r1, [r2] - which goes to RAM) and there are no bad effects, but var 0x4080 doesn't gain 1.

Spoiler:

.text
.align 2
.thumb
.thumb_func

main: 
[B]	mov r1, #0xFF
	lsl r1, r0, #0x6
	add r1, #0xC0
	ldr r3, =(0x806E454 +1)
	bl linker
	ldrh r1, [r0]
	add r1, r1, #0x1
	strh r1, [r0][/B]
	mov r1, #0x1
	strb r1, [r2]
	ldr r0, =(0x8022498 +1)
	bx r0

.align 2
linker:
	bx r3

 

[Blah]

Back again! :) Less of a problem now, slightly different routine too - this one is trying to add 0x1 to variable 0x4080

If my read variable / write to variable section written correctly? In game the rest works (including the strb r1, [r2] - which goes to RAM) and there are no bad effects, but var 0x4080 doesn't gain 1.

Spoiler:

.text
.align 2
.thumb
.thumb_func

main: 
[B]	mov r1, #0xFF
	lsl r1, r0, #0x6
	add r1, #0xC0
	ldr r3, =(0x806E454 +1)
	bl linker
	ldrh r1, [r0]
	add r1, r1, #0x1
	strh r1, [r0][/B]
	mov r1, #0x1
	strb r1, [r2]
	ldr r0, =(0x8022498 +1)
	bx r0

.align 2
linker:
	bx r3

.text
.align 2
.thumb
.thumb_func

main: 
	push {r2, r3}
[B]	mov r0, #0xFF
	lsl r0, r0, #0x6
	add r0, #0xC0
	ldr r3, =(0x806E454 +1)
	bl linker
	ldrh r1, [r0]
	add r1, r1, #0x1
	strh r1, [r0][/B]
	pop {r2, r3}
	mov r1, #0x1
	strb r1, [r2]
	ldr r0, =(0x8022498 +1)
	bx r0

.align 2
linker:
	bx r3

The var address getting takes only one paramater, the var number. So, by definition of how these functions are made, r0 must contain the var number before the call. You're setting r1 to 0x4080, when it should be r0.

Secondly, you need to push r2 and r3 before the the modifications. While r1 and r0 are safe to modify (in this specific case), r2 and r3 are not. That means you need to push them, so you can recall their values for after the hook.

 

[Mana1]

Welcome to the Magic is a noob thread

Reading bytes is straight forward, but some data is stored differently. I'm looking to read data that is stored in the style of what I assume everyone is calling little endian these days? :P idk.

Anyway, map tiles are stored with the tile number and the permissions combined. So... tile 0x10C with no permission (0x1) is stored as 0C 02. How can I account for this in a routine that is trying to find the tile number only?

 

[Touched]

Welcome to the Magic is a noob thread

Reading bytes is straight forward, but some data is stored differently. I'm looking to read data that is stored in the style of what I assume everyone is calling little endian these days? :P idk.

Anyway, map tiles are stored with the tile number and the permissions combined. So... tile 0x10C with no permission (0x1) is stored as 0C 02. How can I account for this in a routine that is trying to find the tile number only?

What you want is called masking. Essentially, the permission and tile number are stored together in a 16 bit word. The tile number is stored in the lower 10 bits of this word, and the meta data (permissions) are in the upper 6. To get the 10 bits out, you use what is called a bit mask. Say for example I have 0x1253 and want the lower ten bits. 0x1253 in binary (padded to 16 bits) is

0001 0010 0101 0011

Now, we select a mask. Everywhere we want a bit to "pass through" we put a 1, and everywhere we want to ignore a bit we put 0. So a mask for the lower 10 bits is

0000 0011 1111 1111

This is 3FF in hex.

Now we do logical AND:
0x1253 & 0x3FF = 0x253

What's happening is very clear when you look at the binary

     0001 0010 0101 0011
AND  0000 0011 1111 1111
------------------------
=    0000 0010 0101 0011

You can use the THUMB op AND to do this. It looks like

and Rd, Rs

and there are no variations, so you'll have to MOV in (or LDR if its is bigger than 8 bits) your mask.

 

[kearnseyboy6]

Wow, masking is very logical. May I ask why this won't work:

lsl 0x6
lsr 0x6

then you will have the same result?

 

[Touched]

Wow, masking is very logical. May I ask why this won't work:

lsl 0x6
lsr 0x6

then you will have the same result?

That won't work because a register is 32 bits. You would need to

lsl Rd, #0x16 @ (16 + 6)
lsr Rd, #0x16

However, I was just trying to introduce a common concept to extract bits rather than show the most efficient way. Masking is more useful when you have non-consecutive bits that you want to extract.

 

[Joexv]

Ok so I'm having... issues....
This is my first actual routine so be nice.:P

Spoiler:

.text
.align 2
.thumb
.thumb_func

main:
push {r0-r6, lr}
@Loads offsets
ldr r0, =(0x20370B8)
ldr r4, =(0x20370BA)
ldr r3, =(0x20370Bc)
ldr r6, =(0x8254784)
@Stores 0x8000 value to r0
ldrh r0, [r0]
@Multiplies stored value by 0x1c to get species
mov r5, #0x1c
mul r0, r0, r5
add r1, r6, r0
add r1, r1, #0x14
add r2, r1, #0x1
@loads final bytes then stores in 0x8001 0x8002
ldrb r1, [r1]
ldrb r2, [r2]
strh r1, [r3]
strh r2, [r4]
pop {r0-r6, pc}

.align 2

All it's supposed to do is get the value stored in 0x8000
multiply it by 0x1c then add 0x14 and then add 0x1 to read both bytes of a pokemons egg group into 2 seperate variables to be buffered.

This is what I'm getting as a result:

Spoiler:

What am I doing wrong??

 

[Blah]

All it's supposed to do is get the value stored in 0x8000
multiply it by 0x1c then add 0x14 and then add 0x1 to read both bytes of a pokemons egg group into 2 seperate variables to be buffered.

What am I doing wrong??

Hey, I'm lead to believe your script is what's wrong here. The routine does what you say it should do, though inefficiently. Try posting your script here or in the script help thread. Anyways, here's the body of a more efficient version.

ldr r2, =(0x20370B8)
ldrh r0, [r2]
mov r1, #0x1C
mul r0, r0, r1
ldr r1, =(0x8254784 +0x14)
add r0, r0, r1
ldrb r1, [r0, #0x1]
ldrb r0, [r0]
ldr r3, =(0x20370BA)
strb r0, [r2]
strb r1, [r3]

0x8000: group 1
0x8001: group 2

 

[Joexv]

Hey, I'm lead to believe your script is what's wrong here. The routine does what you say it should do, though inefficiently. Try posting your script here or in the script help thread. Anyways, here's the body of a more efficient version.

ldr r2, =(0x20370B8)
ldrh r0, [r2]
mov r1, #0x1C
mul r0, r0, r1
ldr r1, =(0x8254784 +0x14)
add r0, r0, r1
ldrb r1, [r0, #0x1]
ldrb r0, [r0]
ldr r3, =(0x20370BA)
strb r0, [r2]
strb r1, [r3]

0x8000: group 1
0x8001: group 2

Wow yea that's wy smaller and way neater.
but the script is super simple so that's why I thought it was the asm:

Spoiler:

#org 0x800030
setvar 0x8000 0x5
callasm 0x8800081
buffernumber 0x1 0x8001
buffernumber 0x2 0x8002
msgbox 0x880004D MSG_NORMAL '"Egg group1-[buffer1]\nEgg group2-[..."
release
end


'---------
' Strings
'---------
#org 0x80004D
= Egg group1-[buffer1]\nEgg group2-[buffer2]

 

[daniilS]

Isn't the first argument of buffernumber zero-indexed?

 

[kleenexfeu]

Hi,
I found the routine of the battle command C1 (hidden power), I wanted to write a far more simple routine to just return the type of the user (wich I think I have), and, if it is needed, the power (fixe)

Here is the hidden power routine :

Spoiler:

sub_8054400: @ DATA XREF: ROM:battle_script_command_tableo
ROM:08054400 PUSH {R4-R7,LR}
ROM:08054402 MOV R7, R10
ROM:08054404 MOV R6, R9
ROM:08054406 MOV R5, R8
ROM:08054408 PUSH {R5-R7}
ROM:0805440A LDR R2, =0x2024084
ROM:0805440C LDR R0, =0x202420B
ROM:0805440E LDRB R1, [R0]
ROM:08054410 MOVS R0, #0x58 @ 'X'
ROM:08054412 MOVS R4, R1
ROM:08054414 MULS R4, R0
ROM:08054416 ADDS R4, R4, R2
ROM:08054418 LDRB R0, [R4,#0x14]
ROM:0805441A MOV R10, R0
ROM:0805441C MOV R7, R10
ROM:0805441E LSLS R7, R7, #0x1B
ROM:08054420 MOVS R0, R7
ROM:08054422 LSRS R0, R0, #0x1B
ROM:08054424 MOV R10, R0
ROM:08054426 MOVS R1, #2
ROM:08054428 MOV R2, R10
ROM:0805442A ANDS R2, R1
ROM:0805442C ASRS R2, R2, #1
ROM:0805442E LDRH R7, [R4,#0x14]
ROM:08054430 MOV R9, R7
ROM:08054432 MOV R0, R9
ROM:08054434 LSLS R0, R0, #0x16
ROM:08054436 MOV R9, R0
ROM:08054438 LSRS R3, R0, #0x1B
ROM:0805443A MOVS R0, R1
ROM:0805443C ANDS R0, R3
ROM:0805443E ORRS R2, R0
ROM:08054440 LDRB R7, [R4,#0x15]
ROM:08054442 MOV R8, R7
ROM:08054444 MOV R0, R8
ROM:08054446 LSLS R0, R0, #0x19
ROM:08054448 MOV R8, R0
ROM:0805444A LSRS R3, R0, #0x1B
ROM:0805444C MOVS R0, R1
ROM:0805444E ANDS R0, R3
ROM:08054450 LSLS R0, R0, #1
ROM:08054452 ORRS R2, R0
ROM:08054454 LDR R6, [R4,#0x14]
ROM:08054456 LSLS R6, R6, #0xC
ROM:08054458 LSRS R3, R6, #0x1B
ROM:0805445A MOVS R0, R1
ROM:0805445C ANDS R0, R3
ROM:0805445E LSLS R0, R0, #2
ROM:08054460 ORRS R2, R0
ROM:08054462 LDRH R5, [R4,#0x16]
ROM:08054464 LSLS R5, R5, #0x17
ROM:08054466 LSRS R3, R5, #0x1B
ROM:08054468 MOVS R0, R1
ROM:0805446A ANDS R0, R3
ROM:0805446C LSLS R0, R0, #3
ROM:0805446E ORRS R2, R0
ROM:08054470 LDRB R3, [R4,#0x17]
ROM:08054472 LSLS R3, R3, #0x1A
ROM:08054474 LSRS R0, R3, #0x1B
ROM:08054476 ANDS R1, R0
ROM:08054478 LSLS R1, R1, #4
ROM:0805447A ORRS R2, R1
ROM:0805447C MOVS R1, #1
ROM:0805447E MOVS R4, R1
ROM:08054480 MOV R7, R10
ROM:08054482 ANDS R4, R7
ROM:08054484 MOV R0, R9
ROM:08054486 LSRS R0, R0, #0x1B
ROM:08054488 MOV R9, R0
ROM:0805448A MOVS R0, R1
ROM:0805448C MOV R7, R9
ROM:0805448E ANDS R0, R7
ROM:08054490 LSLS R0, R0, #1
ROM:08054492 ORRS R4, R0
ROM:08054494 MOV R0, R8
ROM:08054496 LSRS R0, R0, #0x1B
ROM:08054498 MOV R8, R0
ROM:0805449A MOVS R0, R1
ROM:0805449C MOV R7, R8
ROM:0805449E ANDS R0, R7
ROM:080544A0 LSLS R0, R0, #2
ROM:080544A2 ORRS R4, R0
ROM:080544A4 LSRS R6, R6, #0x1B
ROM:080544A6 MOVS R0, R1
ROM:080544A8 ANDS R0, R6
ROM:080544AA LSLS R0, R0, #3
ROM:080544AC ORRS R4, R0
ROM:080544AE LSRS R5, R5, #0x1B
ROM:080544B0 MOVS R0, R1
ROM:080544B2 ANDS R0, R5
ROM:080544B4 LSLS R0, R0, #4
ROM:080544B6 ORRS R4, R0
ROM:080544B8 LSRS R3, R3, #0x1B
ROM:080544BA ANDS R1, R3
ROM:080544BC LSLS R1, R1, #5
ROM:080544BE ORRS R4, R1
ROM:080544C0 LDR R5, =(word_20243CC+0x34)
ROM:080544C2 LSLS R0, R2, #2
ROM:080544C4 ADDS R0, R0, R2
ROM:080544C6 LSLS R0, R0, #3
ROM:080544C8 MOVS R1, #0x3F @ '?'
ROM:080544CA BL sub_82E7540
ROM:080544CE ADDS R0, #0x1E
ROM:080544D0 STRH R0, [R5]
ROM:080544D2 LDR R6, =dword_202449C
ROM:080544D4 LDR R5, [R6]
ROM:080544D6 LSLS R0, R4, #4
ROM:080544D8 SUBS R0, R0, R4
ROM:080544DA MOVS R1, #0x3F @ '?'
ROM:080544DC BL sub_82E7540
ROM:080544E0 ADDS R0, #1
ROM:080544E2 STRB R0, [R5,#0x13]
ROM:080544E4 LDR R1, [R6]
ROM:080544E6 LDRB R0, [R1,#0x13]
ROM:080544E8 CMP R0, #8
ROM:080544EA BLS loc_80544F0
ROM:080544EC ADDS R0, #1
ROM:080544EE STRB R0, [R1,#0x13]
ROM:080544F0
ROM:080544F0 loc_80544F0: @ CODE XREF: sub_8054400+EAj
ROM:080544F0 LDR R2, [R6]
ROM:080544F2 LDRB R0, [R2,#0x13]
ROM:080544F4 MOVS R1, #0xC0 @ '+'
ROM:080544F6 ORRS R0, R1
ROM:080544F8 STRB R0, [R2,#0x13]
ROM:080544FA LDR R1, =0x2024214
ROM:080544FC LDR R0, [R1]
ROM:080544FE ADDS R0, #1
ROM:08054500 STR R0, [R1]
ROM:08054502 POP {R3-R5}
ROM:08054504 MOV R8, R3
ROM:08054506 MOV R9, R4
ROM:08054508 MOV R10, R5
ROM:0805450A POP {R4-R7}
ROM:0805450C POP {R0}
ROM:0805450E BX R0
ROM:0805450E @ End of function sub_8054400

I don't want to someone translate the routine, but, does someone know what it returns ? I mean, It supposed to determine type and power, but in the end it pop five register. So how they're used ?
Or there only R0 that is used ? If so, how the data are stored in ?
I know there's a lot of question but I read tutorials since hours but I am not able to understand this one x)

 

[Blah]

Hi,
I found the routine of the battle command C1 (hidden power), I wanted to write a far more simple routine to just return the type of the user (wich I think I have), and, if it is needed, the power (fixe)

Here is the hidden power routine :

Spoiler:

sub_8054400: @ DATA XREF: ROM:battle_script_command_tableo
ROM:08054400 PUSH {R4-R7,LR}
ROM:08054402 MOV R7, R10
ROM:08054404 MOV R6, R9
ROM:08054406 MOV R5, R8
ROM:08054408 PUSH {R5-R7}
ROM:0805440A LDR R2, =0x2024084
ROM:0805440C LDR R0, =0x202420B
ROM:0805440E LDRB R1, [R0]
ROM:08054410 MOVS R0, #0x58 @ 'X'
ROM:08054412 MOVS R4, R1
ROM:08054414 MULS R4, R0
ROM:08054416 ADDS R4, R4, R2
ROM:08054418 LDRB R0, [R4,#0x14]
ROM:0805441A MOV R10, R0
ROM:0805441C MOV R7, R10
ROM:0805441E LSLS R7, R7, #0x1B
ROM:08054420 MOVS R0, R7
ROM:08054422 LSRS R0, R0, #0x1B
ROM:08054424 MOV R10, R0
ROM:08054426 MOVS R1, #2
ROM:08054428 MOV R2, R10
ROM:0805442A ANDS R2, R1
ROM:0805442C ASRS R2, R2, #1
ROM:0805442E LDRH R7, [R4,#0x14]
ROM:08054430 MOV R9, R7
ROM:08054432 MOV R0, R9
ROM:08054434 LSLS R0, R0, #0x16
ROM:08054436 MOV R9, R0
ROM:08054438 LSRS R3, R0, #0x1B
ROM:0805443A MOVS R0, R1
ROM:0805443C ANDS R0, R3
ROM:0805443E ORRS R2, R0
ROM:08054440 LDRB R7, [R4,#0x15]
ROM:08054442 MOV R8, R7
ROM:08054444 MOV R0, R8
ROM:08054446 LSLS R0, R0, #0x19
ROM:08054448 MOV R8, R0
ROM:0805444A LSRS R3, R0, #0x1B
ROM:0805444C MOVS R0, R1
ROM:0805444E ANDS R0, R3
ROM:08054450 LSLS R0, R0, #1
ROM:08054452 ORRS R2, R0
ROM:08054454 LDR R6, [R4,#0x14]
ROM:08054456 LSLS R6, R6, #0xC
ROM:08054458 LSRS R3, R6, #0x1B
ROM:0805445A MOVS R0, R1
ROM:0805445C ANDS R0, R3
ROM:0805445E LSLS R0, R0, #2
ROM:08054460 ORRS R2, R0
ROM:08054462 LDRH R5, [R4,#0x16]
ROM:08054464 LSLS R5, R5, #0x17
ROM:08054466 LSRS R3, R5, #0x1B
ROM:08054468 MOVS R0, R1
ROM:0805446A ANDS R0, R3
ROM:0805446C LSLS R0, R0, #3
ROM:0805446E ORRS R2, R0
ROM:08054470 LDRB R3, [R4,#0x17]
ROM:08054472 LSLS R3, R3, #0x1A
ROM:08054474 LSRS R0, R3, #0x1B
ROM:08054476 ANDS R1, R0
ROM:08054478 LSLS R1, R1, #4
ROM:0805447A ORRS R2, R1
ROM:0805447C MOVS R1, #1
ROM:0805447E MOVS R4, R1
ROM:08054480 MOV R7, R10
ROM:08054482 ANDS R4, R7
ROM:08054484 MOV R0, R9
ROM:08054486 LSRS R0, R0, #0x1B
ROM:08054488 MOV R9, R0
ROM:0805448A MOVS R0, R1
ROM:0805448C MOV R7, R9
ROM:0805448E ANDS R0, R7
ROM:08054490 LSLS R0, R0, #1
ROM:08054492 ORRS R4, R0
ROM:08054494 MOV R0, R8
ROM:08054496 LSRS R0, R0, #0x1B
ROM:08054498 MOV R8, R0
ROM:0805449A MOVS R0, R1
ROM:0805449C MOV R7, R8
ROM:0805449E ANDS R0, R7
ROM:080544A0 LSLS R0, R0, #2
ROM:080544A2 ORRS R4, R0
ROM:080544A4 LSRS R6, R6, #0x1B
ROM:080544A6 MOVS R0, R1
ROM:080544A8 ANDS R0, R6
ROM:080544AA LSLS R0, R0, #3
ROM:080544AC ORRS R4, R0
ROM:080544AE LSRS R5, R5, #0x1B
ROM:080544B0 MOVS R0, R1
ROM:080544B2 ANDS R0, R5
ROM:080544B4 LSLS R0, R0, #4
ROM:080544B6 ORRS R4, R0
ROM:080544B8 LSRS R3, R3, #0x1B
ROM:080544BA ANDS R1, R3
ROM:080544BC LSLS R1, R1, #5
ROM:080544BE ORRS R4, R1
ROM:080544C0 LDR R5, =(word_20243CC+0x34)
ROM:080544C2 LSLS R0, R2, #2
ROM:080544C4 ADDS R0, R0, R2
ROM:080544C6 LSLS R0, R0, #3
ROM:080544C8 MOVS R1, #0x3F @ '?'
ROM:080544CA BL sub_82E7540
ROM:080544CE ADDS R0, #0x1E
ROM:080544D0 STRH R0, [R5]
ROM:080544D2 LDR R6, =dword_202449C
ROM:080544D4 LDR R5, [R6]
ROM:080544D6 LSLS R0, R4, #4
ROM:080544D8 SUBS R0, R0, R4
ROM:080544DA MOVS R1, #0x3F @ '?'
ROM:080544DC BL sub_82E7540
ROM:080544E0 ADDS R0, #1
ROM:080544E2 STRB R0, [R5,#0x13]
ROM:080544E4 LDR R1, [R6]
ROM:080544E6 LDRB R0, [R1,#0x13]
ROM:080544E8 CMP R0, #8
ROM:080544EA BLS loc_80544F0
ROM:080544EC ADDS R0, #1
ROM:080544EE STRB R0, [R1,#0x13]
ROM:080544F0
ROM:080544F0 loc_80544F0: @ CODE XREF: sub_8054400+EAj
ROM:080544F0 LDR R2, [R6]
ROM:080544F2 LDRB R0, [R2,#0x13]
ROM:080544F4 MOVS R1, #0xC0 @ '+'
ROM:080544F6 ORRS R0, R1
ROM:080544F8 STRB R0, [R2,#0x13]
ROM:080544FA LDR R1, =0x2024214
ROM:080544FC LDR R0, [R1]
ROM:080544FE ADDS R0, #1
ROM:08054500 STR R0, [R1]
ROM:08054502 POP {R3-R5}
ROM:08054504 MOV R8, R3
ROM:08054506 MOV R9, R4
ROM:08054508 MOV R10, R5
ROM:0805450A POP {R4-R7}
ROM:0805450C POP {R0}
ROM:0805450E BX R0
ROM:0805450E @ End of function sub_8054400

I don't want to someone translate the routine, but, does someone know what it returns ? I mean, It supposed to determine type and power, but in the end it pop five register. So how they're used ?
Or there only R0 that is used ? If so, how the data are stored in ?
I know there's a lot of question but I read tutorials since hours but I am not able to understand this one x)

What ROM base? This isn't FireRed :o

 

[kleenexfeu]

Yeah indeed. Forgot to mention this is Emerald x)

 

[Blah]

Yeah indeed. Forgot to mention this is Emerald x)

Well, taking a look at this code atm, I can tell that it doesn't have a return value. Instead, it seems to write into some sort of data structure/RAM pointer.

You'd be best off setting break points at these hard coded RAM offsets and seeing what they are. When they're written directly like this, rather than loaded from pointers, it means the RAM addresses are static. So if you can see what they hold, you can generalize what that RAM offset will always hold (in 99% of cases).

 

[kleenexfeu]

Thank's a lot for the time that you take
But I actually found a post of Chaos Rush and he said he tried to right value/change pointer and so on and nothing happen, it's probably hard coded as he said.
Sorry to make you waste your time :s

 

[kleenexfeu]

Ok now I have other question, see this post in the spoiler. I would like to adapt the following routine to emerald but if only I could understand why it exactly doing in Firered it would be very very useful. So, the routine :

Spoiler:

Natural Gift for FireRed:

Step 1: First, add this command in commands.bsh for Battle Script Pro (credit to KDS for first discovering this when he posted his Incinerate script):

Spoiler:

#command removeitem 0x6A 0x1 "Bank" 0x1

(this command to remove items is already in the game so you don't need to add code or anything, it's just unidentified by BSP)

Step 2:
Compile the following table and put it into free space, make sure you take note of the offset you put it in. We'll refer to this table as NATURAL GIFT TABLE:

Spoiler:

.align 2
.text

main:
/*CHERI*/
.hword 0x0085
.byte 0x0A
.byte 0x50

/*CHESTO*/
.hword 0x0086
.byte 0x0B
.byte 0x50

/*PECHA*/
.hword 0x0087
.byte 0x0D
.byte 0x50

/*RAWST*/
.hword 0x0088
.byte 0x0C
.byte 0x50

/*ASPEAR*/
.hword 0x0089
.byte 0x0F
.byte 0x50

/*LEPPA*/
.hword 0x008A
.byte 0x01
.byte 0x50

/*ORAN*/
.hword 0x008B
.byte 0x03
.byte 0x50

/*PERSIM*/
.hword 0x008C
.byte 0x04
.byte 0x50

/*LUM*/
.hword 0x008D
.byte 0x02
.byte 0x50

/*SITRUS*/
.hword 0x008E
.byte 0x0E
.byte 0x50

/*FIGY*/
.hword 0x008F
.byte 0x06
.byte 0x50

/*WIKI*/
.hword 0x0090
.byte 0x05
.byte 0x50

/*MAGO*/
.hword 0x0091
.byte 0x07
.byte 0x50

/*AGUAV*/
.hword 0x0092
.byte 0x10
.byte 0x50

/*IAPAPA*/
.hword 0x0093
.byte 0x11
.byte 0x50

/*RAZZ*/
.hword 0x0094
.byte 0x08
.byte 0x50

/*BLUK*/
.hword 0x0095
.byte 0x0A
.byte 0x5A

/*NANAB*/
.hword 0x0096
.byte 0x0B
.byte 0x5A

/*WEPEAR*/
.hword 0x0097
.byte 0x0D
.byte 0x5A

/*PINAP*/
.hword 0x0098
.byte 0x0C
.byte 0x5A

/*POMEG*/
.hword 0x0099
.byte 0x0F
.byte 0x5A

/*KELPSY*/
.hword 0x009A
.byte 0x01
.byte 0x5A

/*QUALOT*/
.hword 0x009B
.byte 0x03
.byte 0x5A

/*HONDEW*/
.hword 0x009C
.byte 0x04
.byte 0x5A

/*GREPA*/
.hword 0x009D
.byte 0x02
.byte 0x5A

/*TAMATO*/
.hword 0x009E
.byte 0x0E
.byte 0x5A

/*CORNN*/
.hword 0x009F
.byte 0x06
.byte 0x5A

/*MAGOST*/
.hword 0x00A0
.byte 0x05
.byte 0x5A

/*RABUTA*/
.hword 0x00A1
.byte 0x07
.byte 0x5A

/*NOMEL*/
.hword 0x00A2
.byte 0x10
.byte 0x5A

/*SPELON*/
.hword 0x00A3
.byte 0x11
.byte 0x5A

/*PAMTRE*/
.hword 0x00A4
.byte 0x08
.byte 0x5A

/*WATMEL*/
.hword 0x00A5
.byte 0x0A
.byte 0x64

/*DURIN*/
.hword 0x00A6
.byte 0x0B
.byte 0x64

/*BELUE*/
.hword 0x00A7
.byte 0x0D
.byte 0x64

/*LIECHI*/
.hword 0x00A8
.byte 0x0C
.byte 0x64

/*GANLON*/
.hword 0x00A9
.byte 0x0F
.byte 0x64

/*SALAC*/
.hword 0x00AA
.byte 0x01
.byte 0x64

/*PETAYA*/
.hword 0x00AB
.byte 0x03
.byte 0x64

/*APICOT*/
.hword 0x00AC
.byte 0x04
.byte 0x64

/*LANSAT*/
.hword 0x00AD
.byte 0x02
.byte 0x64

/*STARF*/
.hword 0x00AE
.byte 0x0E
.byte 0x64

/*ENIGMA*/
.hword 0x00AF
.byte 0x06
.byte 0x64

/*end table*/
.hword 0xFFFF
.hword 0xFFFF

When compiled, the format of this table will be [XX XX] [YY] [ZZ], with XXXX being the index number of the item, YY being the type that Natural Gift will change into, and ZZ being the base power. This table only covers the berries that are in Gen 3, so if you've added new berries then you'll have to add them into the table. MAKE SURE YOU LEAVE THE FOUR FF BYTES AT THE END, DO NOT OVERWRITE IT. (or change them to FE bytes, and in Step 3 modify the line "mov r4, 0xFF" to "mov r4, 0xFE").

Step 3:
Insert this routine into free space, and take note of its offset. We'll refer to this as ASM ROUTINE 1:

Spoiler:

.text
.align 2
.thumb
.thumb_func
.global test

main:
push {lr} Why don't we push r0-r5 ? since we are going to use these ?
ldr r0, .UserBank
ldr r1, .BattleData
ldrb r0, [r0] Here we load a byte from the 0x02023D6B, right ? But it's always 00 in battle when we attack, 01 when it's the opponent
mov r2, #0x58
mul r2, r0 So, if we mul r2 (=0x58) by r0 (=0, because we are attacking now), it's equal to 0, doesn't it ?
add r1, #0x2E Here okay, we looking for the address of the held item
add r1, r2 Why we're doing that here ?
ldrh r0, [r1] /*r0 should now have held item. r1 is the RAM offset of the held item*/ Ok too
cmp r0, #0x0 Check if don't holding item
beq Abort Go to abort and then fail script if so
ldr r2, .NaturalGiftTable Ok
mov r4, #0xFF Ok

loop:
ldrh r3, [r2] /*item ID*/ Load half word to take item ID in our table as Chaos Rush mentioned
ldrb r5, [r2, #0x3] Load type that correspond
cmp r5, r4
beq Abort /*fail if 4th byte is FF*/ Already explained
cmp r0, r3 COmpare if we olding the same item as the one loaded
beq Confirmed If so, go to confirmed
add r2, #0x4 Incrementation (is it the good term btw ?) to redo the loop
b loop

Confirmed:
ldrb r4, [r2, #0x2] /*Type*/ Here r4 is equal to FF, so, why are we doing that ? Ok I'm a dumb, but it should be ldrb r4, [r2, #0x3] or am I wrong ?
ldrb r5, [r2, #0x3] /*Power*/ Aren't we supposed to do ldrb r5, [r2, #0x4] ? Since the type was ldrb r5, [r2, #0x3]
ldr r0, .MemAddress Here we have loaded the .MemAddress, add 13, it seems to be just before the number of the attack of the pokemon (attack 1, attack 2, attack 3, attack 4) EDIT : According to JPAN's battle script document, it's indeed the location of current attack type, or rather the pointer to the address of type
ldr r0, [r0]
add r0, #0x13 So why add 0x13 ? as I said it's one byte before the number of our selected attack
strb r4, [r0] /*change Type*/ From what I found, this byte (MemAddress +0x13) is always 00, so why doing this would change the type of the attack ? EDIT : Ok, it's a pointer, not the direct address.
add r0, #0x7B The memaddress is load in r0, so we're going to change the type, but it's not 0x7B, the type's byte is further
strb r4, [r0]
ldr r0, .BasePower
strb r5, [r0] Is it here that we change base power ? Why use the same register ?
b Attack

Abort:
ldr r0, .CurrentScript
ldr r1, .FailScript
str r1, [r0]

Attack:
End:
pop {r0} As my first question, why don't we pop r0-r5 ? Why we don't pop pc since we used lr ?
bx r0

.align 2
.BattleData: .word 0x02023BE4
.UserBank: .word 0x02023D6B
.BasePower: .word 0x02023F50
.MemAddress: .word 0x02023FE8
.CurrentScript: .word 0x02023D74
.FailScript: .word 0x081D7DF0
.NaturalGiftTable: .word 0x08(OFFSET OF NATURAL GIFT TABLE)

Make sure you put in the offset of the Natural Gift table at the last line.

Step 4:
Now, insert this routine into free space as well, and take note of its offset. We'll refer to this as ASM ROUTINE 2:

Spoiler:

.text
.align 2
.thumb
.thumb_func
.global test

GetOpponentType:
push {lr}
ldr r0, .TargetBank
ldr r1, .BattleData
ldrb r0, [r0]
mov r2, #0x58
mul r2, r0
add r1, #0x21
add r1, r2
ldrb r0, [r1] /*r0 should now have opponent Type 1*/
ldrb r2, [r1, #0x1] /*r2 should now have opponent Type 2*/

GetNaturalGiftType:
ldr r1, .MemAddress
ldr r1, [r1]
add r1, #0x13
ldrb r1, [r1] /*r1 should now have modified Natural Gift type*/
ldr r3, .TypeChart

/*check attacking type*/
Check1:
ldrb r4, [r3] /*r4 has Type Chart attacking type*/
ldrb r5, [r3, #0x1] /*r5 has Type Chart defending type*/
ldrb r6, [r3, #0x2] /*r6 has Type Chart effectiveness*/
cmp r4, #0xFE
beq Abort
cmp r1, r4 /*check NG type with Attacking type*/
bne Recheck
cmp r0, r5 /*check opponent Type 1 with Defending type*/
beq Type1Match
cmp r2, r5 /*check opponent Type 2 with Defending type*/
beq OkNowCheckType1
add r3, #0x3
b Check1

OkNowCheckType1:
ldr r3, .TypeChart
b StillCheckinglol

/*we should be here if Type 2 was a match but Type 1 wasn't*/
StillCheckinglol:
ldrb r4, [r3] /*r4 has Type Chart attacking type*/
ldrb r5, [r3, #0x1] /*r5 has Type Chart defending type*/
ldrb r7, [r3, #0x2] /*r7 has Type Chart effectiveness*/
cmp r4, #0xFE
beq SameOutcome
cmp r1, r4 /*check NG type with Attacking type*/
bne Recheck3
cmp r0, r5 /*check opponent Type 1 Defending type*/
beq Type2Match
add r3, #0x3
b Check2

Type1Match:
ldr r3, .TypeChart
b Check2

Check2:
ldrb r4, [r3] /*r4 has Type Chart attacking type*/
ldrb r5, [r3, #0x1] /*r5 has Type Chart defending type*/
ldrb r7, [r3, #0x2] /*r7 has Type Chart effectiveness*/
cmp r4, #0xFE
beq SameOutcome
cmp r1, r4 /*check NG type with Attacking type*/
bne Recheck2
cmp r2, r5 /*check opponent Type 2 Defending type*/
beq Type2Match
add r3, #0x3
b Check2

Type2Match:
cmp r6, r7
beq SameOutcome
cmp r6, #0x5
beq TOneIsWeak
cmp r6, #0x0
beq Sameoutcome
cmp r6, #0x14
beq TOneIsSuper

TOneIsWeak:
cmp r7, #0x5
beq SameOutcome
cmp r7, #0x0
beq NoDamage
cmp r7, #0x14
beq Abort

TOneIsSuper:
cmp r7, #0x5
beq Abort
cmp r7, #0x0
beq NoDamage
cmp r7, #0x14
beq SameOutcome

Recheck:
add r3, #0x3
b Check1

Recheck2:
add r3, #0x3
b Check2

Recheck3:
add r3, #0x3
b StillCheckinglol

SameOutcome:
cmp r6, #0x5
beq WeakDamage
cmp r6, #0x0
beq NoDamage
cmp r6, #0x14
beq SuperDamage
cmp r7, #0x5
beq WeakDamage
cmp r7, #0x0
beq NoDamage
cmp r7, #0x14
beq SuperDamage

WeakDamage:
ldr r0, .Outcome
mov r1, #0x04
strb r1, [r0]
b End

NoDamage:
ldr r0, .Outcome
mov r1, #0x08
strb r1, [r0]
b End

SuperDamage:
ldr r0, .Outcome
mov r1, #0x02
strb r1, [r0]
b End

Abort:
End:
pop {r0}
bx r0

.align 2
.Outcome: .word 0x02023DCC
.TypeChart: .word 0x0824F050 /*make sure you replace this with the offset of your own type chart*/
.BattleData: .word 0x02023BE4
.TargetBank: .word 0x02023D6C
.MemAddress: .word 0x02023FE8

Note: If you have repointed your type chart, then you will have to put its new offset where I've bolded above.

Step 5:
Now here's the battle script:

Spoiler:

#org @main
attackcanceler
accuracycheck 0x81D695E 0x0
attackstring
ppreduce
callasm 0x8(offset of ASM ROUTINE 1+1)
calculatedamage
callasm 0x8(offset of ASM ROUTINE 2+1)
attackanimation
waitanimation
missmessage
cmd5c 0x0
waitstate
graphicalhpupdate 0x0
datahpupdate 0x0
critmessage
waitmessage 0x40
resultmessage
waitmessage 0x40
jumpifbyte 0x4 0x02023DCC 0x8 0x81D694E
removeitem 0x1
goto 0x81D6947

And here's an animation:

02 24 7B 3E 08 02 05 01 00 01 00 00 00 0A 00 ED 33 05 03 19 34 0B 08 02 00 19 EC 00 C0 04 10 19 EC 00 C0 05 00 97 27 0A 01 0C 0C 08 19 7F 00 3F 02 08 7C 3E 08 02 04 00 00 00 00 01 00 02 00 03 F9 89 09 08 02 05 01 00 03 00 00 00 06 00 01 00 05 0B 01 0D 02 24 7B 3E 08 02 05 01 00 01 00 0A 00 00 00 ED 33 05 0B 03 0D 08

Here's an explanation as to how this works:
So as you can see, "ASM ROUTINE 1" looks up the custom table we inserted and matches your held item to it (the move will fail if you're not holding an item or if you're holding an item that's not in the table), and then updates the type and base power accordingly. Now, with this routine alone, the damage and type calculations are correct, but the outcome message will always act as a regular move (regular as in not super-effective or not not-very-effective) unless if you don't have an item in the table (then it will just fail), and turns out the reason why is for some reason the outcome RAM offset (02023DCC) wasn't getting updated even though the battle engine should theoretically already have done so (if you have the routine be the first thing in the script). So what "ASM ROUTINE 2" does is that it looks up the type chart and the opponent's types and determines the outcome that way (and yes, I checked and double checked and triple checked with various berry & type combinations, so it works). It wasn't ideal, but it was necessary in order to get the correct message to show up.

"But Chaos, couldn't you just look at how Weather Ball and Hidden Power does it"? Well, I did (for anyone curious, the Weather Ball command's routine is at 0802D090, while the Hidden Power command's routine is at 0802B678), and what both do is that they update the value held by the pointer at 02023FE8(a dynamic memory location) + 0x13, usually the pointer at 02023FE8 leads to 02000010, so the type value is (usually) at 02000023. No matter what I tried with updating that value, it always played the normal hit sound (but would still do more or less damage depending on type, such as Electric type Natural Gift doing more damage to Pidgey than Water type Natural Gift), unless if it was a type immunity in which case it worked as expected. For testing reasons I tried giving a new test move Hidden Power's battle script ID, and turns out the correct sound effect doesn't play either (but it does with Hidden Power itself, even though I gave them the same battle script ID), and turns out the outcome offset was only being updated when using the actual Hidden Power, which leads me to believe that Hidden Power and Weather Ball's move ID's are hard-coded to update the outcome offset. So the whole purpose of "ASM ROUTINE 2" is to circumvent that. "ASM ROUTINE 2" manually looks up the type chart and what outcome it should be, and updates the outcome value at 02023DCC accordingly.

My question are principally for the first routine, I mean transform type/get base power. Not the table item.
In all likelihood I'll have question for the second one but for the moment, I'm sure the first one doesn't work correctly for me.
The most important to me is understand what is happening, so I put my question/how I understand in bold.

Last thing, I tried to find the RAM address for emerald and this is what I have

.BattleData: .word 0x02024084
.UserBank: .word 0x0202420B
.BasePower: .word 0x020244E0
.MemAddress: .word 0x0202449C
.CurrentScript: .word 0x02024214
.FailScript: .word 0x082D9F1C
.Outcome: .word 0x0202427C
.BattleData: .word 0x02024084
.TargetBank: .word 0x0202420C

I know this is not the topic but the routine doesn't works for me. Perhaps simply because I don't have the correct offset.

Thank's in advance whoever answer me :)

I tried to make a routine that take my type and transform my attack into this type :

Spoiler:

.text
.align 2
.thumb
.thumb_func
.global test

main:
push {r0-r3,lr}
ldr r0, .BattleData
add r1, #0x21
add r0, r0, r1
ldrb r0, [r0]
ldr r2, .MemAddress
add r3, #0x8F
add r2, r2, r3
ldrb r2, [r2]
lsl r2, #0x3
add r2, r2, r0
strb r0, [r2]
pop {r0-r3,pc}

.align 2
.BattleData: .word 0x02024084
.MemAddress: .word 0x0202449C

It does absolutly nothing, the attack remind regular

There is one good thing in this one, it actually change the type of the attack, but it's a little bit random. Didn't manage to do super effective damages.
EDIT : Actually damages are always neutral, and it's not a question of string displayed. I tested the damage and they are really neutral. I guess it load a value that is too high but can't figured out how to load the good (primary type of my poke) :

Spoiler:

.text
.align 2
.thumb
.thumb_func
.global test

main:
push {lr}
ldr r0, .UserBank
ldr r1, .BattleData
ldrb r0, [r0]
mov r2, #0x58
mul r2, r0
add r1, #0x21
add r1, r2
ldrh r0, [r1]
ldr r0, .MemAddress
ldr r0, [r0]
add r0, #0x13
strb r3, [r0]
add r3, #0x7B
add r3, r0
strb r3, [r0]
pop {r0}
bx r0

.BattleData: .word 0x02024084
.UserBank: .word 0x0202420B
.MemAddress: .word 0x0202449C

I don't know why, but this one works :

Spoiler:

.text
.align 2
.thumb
.thumb_func
.global test

main:
push {lr}
ldr r0, .UserBank
ldr r1, .BattleData
ldrb r0, [r0]
mov r2, #0x58
mul r2, r0
add r1, #0x21
add r1, r0
ldrh r0, [r1]
ldrb r1, [r1]
ldr r0, .MemAddress
ldr r0, [r0]
add r0, #0x13 I said I don't know because of this part, to me it should be 0x8E, to go to the type of the attack used, if someone could explain me it would be awesome
strb r1, [r0]
pop {r0}
bx r0

.BattleData:.word 0x02024084
.UserBank:.word 0x0202420B
.MemAddress:.word 0x0202449C

Change attack in user's primary type

 

[NewDenverCity]

What I'm trying to do is remake the rematch system in an extremely basic way, and here's the code I made for it.

Spoiler:

.text
.align 2
.thumb
.thumb_func
main:
[INDENT] push {r0-r1, lr}
 ldr r0, =(0x23A46C)
 ldr r1, =(0x23A472)
 ldrh r0, [r0]
 ldrh r1, [r1]
 add r0, r0, #0x5
 add r1, r1, #0x5
 ldr r0, =(0x23A46C)
 ldr r1, =(0x23A472)
 pop {r0-r1, pc}
[/INDENT].align 2

I'm only trying to add five levels to the Pokémon's levels(in this instance youngster ben), but after running the script it wasn't working, and his levels remained what they were before. Any idea what's going wrong?

 

[Touched]

What I'm trying to do is remake the rematch system in an extremely basic way, and here's the code I made for it.

Spoiler:

.text
.align 2
.thumb
.thumb_func
main:
[INDENT] push {r0-r1, lr}
 ldr r0, =(0x23A46C)
 ldr r1, =(0x23A472)
 ldrh r0, [r0]
 ldrh r1, [r1]
 add r0, r0, #0x5
 add r1, r1, #0x5
 ldr r0, =(0x23A46C)
 ldr r1, =(0x23A472)
 pop {r0-r1, pc}
[/INDENT].align 2

I'm only trying to add five levels to the Pokémon's levels(in this instance youngster ben), but after running the script it wasn't working, and his levels remained what they were before. Any idea what's going wrong?

I can't even tell what you are trying to do, but I'll do my best. It looks as though you are loading a ROM offset rather than an address. ROM is prefixed by 08/09, you have prefixed it with 00 (BIOS). In fact this address is invalid and will be ignored by VBA - the bios is only 16kb. Hardware will do weird things.

Next, you load two half words, add 5, then load the addresses again? Why? I think what you are trying to do is store to those addresses, but you'd need str, strh or strb to do that. If I'm right about these being ROM offsets, then you clearly don't understand the concept of ROM. You can't right to it. Ever. There are a few bytes of ROM address space reserved for GPIO for sensors, and this is the only exception.

Lastly, you're wasting stack space. Neither R0, R1 or LR need to be pushed.

I suggest you read some tutorials and look at existing code so you actually understand what you're doing, rather than fumbling around in the dark.