Development: Porting TM/HM expansion to Emerald UPDATED!!!

[Starfall321]

Before anyone asking about doing this Kanto , pls take a look on this post

Spoiler:

https://www.pokecommunity.com/showthread.php?p=8580286#8580286

Although he don't really give us much explanation, his post definitely useful for further development.

The purpose of this thread is to port and fix the routine to Emerald. I cant do this alone, so any help is appreciated.

Let this picture speak everything

Done
In progress/Need help!!!

Things we need to do:
0. Expand the TM/HM move table

Spoiler:

TMData=616040
Repoint the old table, quite easy to do so.

1.Expand the item number.(alternative)

Spoiler:

https://www.pokecommunity.com/showpost.php?p=9252580&postcount=3

2.Expand the pocket slot.

Spoiler:

.text
.align 2
.thumb
.thumb_func
.global emerald_tm_slots_hack

main:
ldr r0, ram
str r0, [r1, #0x10]
mov r0, #0x80 @128 slot
strb r0, [r1, #0x14]
ldr r0, return
bx r0

.align
ram: .word 0x0203d900 @you will need 4x128= 512bytes
return: .word 0x080D6628+1

@Goto 0xD6620 :00 48 00 47 [reverse routine pointer+1]

2.5.Fix Bag maximum size

Spoiler:

@credit to azurile13
.org 0x00000B38
malloc:
push {lr}
mov r1, r0

.org 0x001AB218
main:
push {r4, lr}
ldr r4, =0x0203CE74
mov r0, #0x81 @(maximum pocket size+1)
lsl r0, r0, #0x3
bl malloc
str r0, [r4, #0]
ldr r0, =0xC18 @(maximum pocket size+1)*24
bl malloc
str r0, [r4, #4]
pop {r4}
pop {r0}
bx r0

3.Fix TM/HM index routine.

Spoiler:

.align 2

ldr r1, =0x17B @new TM01 index
sub r0, r0 ,r1
lsl r0, r0, #0x1
ldr r1, =0x08XXXXXX @TM/HM move table offset
add r0, r0, r1
ldrh r0, [r0]
bx lr

@Go to 0x1B6CFC: 00 00 00 00 00 49 08 47 CC BB AA 08, replace CC BB AA 08 to your asm offset+1 in reverse pointer.

4.Fix No.? thing

Spoiler:

.align 2
ldr r0, =0x1F2 @HM01_INDEX-1
cmp r5, r0
bls isTM
sub r1, r5, r0
ldr r0, =0x02021CC4
ldr r2, =0x081AB3E8+1 @return_place1
bx r2

isTM:
ldr r0, =0x17A @TM01_INDEX-1
sub r1, r5, r0
ldr r0, =0x02021CC4
ldr r2, =0x081AB408+1 @return_place2
bx r2

@Go to 0x1AB3DA: 00 00 00 48 00 47 CC BB AA 08, replace CC BB AA 08 to your asm offset+1 in reverse pointer.

4.5.Fix 3 digit number not showing properly

Spoiler:

@Fix 3 digit number not showing properly, thx azurile13 for hint
.align 2
cmp r1, #100
blt two_digit
mov r3, #3
b exit

two_digit:
mov r3, #2

exit:
ldr r2, =0x081ab410+1
bx r2

@Go to 0x1AB408: 00 4A 10 47 CC BB AA 08, replace CC BB AA 08 to your asm offset+1 in reverse pointer.
@Go to 0x1AB3EA: 02 23, to fix HM 2 digit not showing properly.

5.Fix HM icon thing

Spoiler:

.org 0x1AB5FC
.word -0x17B-120 @-new TM01 index-120

6.Fix TM/HM compatibility table

Spoiler:

@again credit to azurile13, his routine for fire red seems more efficient than mine, so I choose to port it to emerald
.org 0x0006E02E
lsl r1, r1, #4 @or a mul for bytes not a power of 2(modify this line if you want more TM)
ldr r0, TMHM_compatibility @new TMHM compatibility table
add r0, r1
ldr r4, get_tm01
sub r4, r7, r4
lsr r1, r4, #0x3 @div 8, round down
ldrb r0, [r0, r1]
lsl r1, r4, #0x1D
lsr r1, r1, #0x1D
lsr r0, r1
lsl r0, r0, #0x1F
lsr r0, r0, #0x1F
pop {r4-r5}
pop {r1}
bx r1
.align
get_tm01: .word 0x17B
TMHM_compatibility: .word 0x0F00000

7. Fix "Booted up an HM."

Spoiler:

@Fix "Booted up an HM."
.align 2

ldrh r1, [r0]
ldr r0, HM01_index
cmp r1, r0
bls TMstring
ldr r2, HMstring_return
bx r2

TMstring:
ldr r2, TMstring_return
bx r2

.align
HM01_index: .word 0x1F2
HMstring_return: .word 0x080FDF5A+1
TMstring_return: .word 0x080FDF74+1

@Go to 0xFDF50: 00 4A 10 47 CC BB AA 08, replace CC BB AA 08 to your asm offset+1 in reverse pointer.

I move the bunch of TM item data to expanded slot and move HM data backward so I could have extra 78 TM between them.
You can actually use alternative way to do this(without moving original item data), but you need to modify the routines above and the item arrangement routine yourself, so I suggest to use my way.

 

[azurile13]

My blind guesses based on the FR expansion.

2. I suspect that since there is no TM Case, you're running into this problem: https://www.pokecommunity.com/posts/9090677/
The malloc size is a specific hard coded number, rather than a multiple of the quantity of items. Look for the equivalent Emerald routine and fix it to the new max TM + HM quantity. If you want to go beyond 0x7F items in a single pocket, there's the further annoyance of the bag slot items being programmed as signed bytes for who knows what reason. Not a big problem - just another tiny thing to account for.

5. You already know how FireRed does this, so I don't really know, and don't feel like looking at Emerald :D good luck?

6. I can't imagine this one being too difficult. Just look for pointers to the current table, and you'll find the routine you need to change. FireRed example and routine location: https://www.pokecommunity.com/posts/9165280/

 

[Starfall321]

My blind guesses based on the FR expansion.

2. I suspect that since there is no TM Case, you're running into this problem: https://www.pokecommunity.com/posts/9090677/
The malloc size is a specific hard coded number, rather than a multiple of the quantity of items. Look for the equivalent Emerald routine and fix it to the new max TM + HM quantity. If you want to go beyond 0x7F items in a single pocket, there's the further annoyance of the bag slot items being programmed as signed bytes for who knows what reason. Not a big problem - just another tiny thing to account for.

5. You already know how FireRed does this, so I don't really know, and don't feel like looking at Emerald :D good luck?

6. I can't imagine this one being too difficult. Just look for pointers to the current table, and you'll find the routine you need to change. FireRed example and routine location: https://www.pokecommunity.com/posts/9165280/

2. I will probably take some time on this, right now my new pc has very limited resource to do this.

6. Actually I complete the routine but I mess up my record, I will post it later.

Interesting fact, indeed Emerald without any change has 64 slots, but you have only 58 TM/HM atm in Emerald.
080D6624 2040 mov r0,#0x40
080D6626 7508 strb r0,[r1,#0x14]
Maybe the Emerald was originally designed to have more TM.

 

[azurile13]

2. I will probably take some time on this, right now my new pc has very limited resource to do this.

6. Actually I complete the routine but I mess up my record, I will post it later.

Interesting fact, indeed Emerald without any change has 64 slots, but you have only 58 TM/HM atm in Emerald.
080D6624 2040 mov r0,#0x40
080D6626 7508 strb r0,[r1,#0x14]
Maybe the Emerald was originally designed to have more TM.

Can't you just use a debugger? Set a breakpoint on malloc, then open that bag. That's all I did to find the fix for FireRed.

 

[Starfall321]

Can't you just use a debugger? Set a breakpoint on malloc, then open that bag. That's all I did to find the fix for FireRed.

Yeah, I am actually a newbie in Emerald hacking, so I never know where the malloc is until I found this thread half an hour ago.
https://pokemonhackersonline.com/archive/index.php/t-13724.html

Thx azurile again,now I manage to do this with some byte change, I will update the op ASAP after I complete the routine. Updated!!

The routine is located at 0x81AB218
1 step more to succeed.

 

[Starfall321]

I found something interesting while hacking daycare.
080705C2 seems to be the routine of TM move passing down to child.
Change the byte at 0x706C8 here to your new TM01 ID.

 

[DizzyEgg]

stuff

Always wanted to do it, but lacked the motivation. Anyway, good job on the progress.
I've a question tho. Where are you going to put new TMs data? Bag size is limited and can only hold 64 TMs/HMs. What I'm asking is where you store the new items data.

 

[Starfall321]

Always wanted to do it, but lacked the motivation. Anyway, good job on the progress.
I've a question tho. Where are you going to put new TMs data? Bag size is limited and can only hold 64 TMs/HMs. What I'm asking is where you store the new items data.

I update the stuff, bag size was fixed so it suppose could have a maximum of 128 item inside one pocket (check step 2.5)
Not sure what you are asking, I store the TM/HM slotsitem somewhere on the extended saveblock.
.align 2

main:
ldr r0, ram
str r0, [r1, #0x10]
mov r0, #0x80 @128 slot
strb r0, [r1, #0x14]
ldr r0, return
bx r0

.align
[S-HIGHLIGHT]ram: .word 0x0203d900 @you will need 4x128= 512bytes[/S-HIGHLIGHT]
return: .word 0x080D6628+1

@Goto 0xD6620 :00 48 00 47 [reverse routine pointer+1]

 

[DizzyEgg]

I update the stuff, bag size was fixed so it suppose could have a maximum of 128 item inside one pocket (check step 2.5)
Not sure what you are asking, I store the TM/HM slotsitem somewhere on the extended saveblock.
.align 2

main:
ldr r0, ram
str r0, [r1, #0x10]
mov r0, #0x80 @128 slot
strb r0, [r1, #0x14]
ldr r0, return
bx r0

.align
[S-HIGHLIGHT]ram: .word 0x0203d900 @you will need 4x128= 512bytes[/S-HIGHLIGHT]
return: .word 0x080D6628+1

@Goto 0xD6620 :00 48 00 47 [reverse routine pointer+1]

Ah you extend saveblock, alright.

 

[LCCoolJ95]

Hey, this may be off-topic, but I noticed that you expanded the pocket size for TMs. Is there a way to expand the pocket size for Items pocket? And if so, could you show me what I should do?

 

[Starfall321]

Hey, this may be off-topic, but I noticed that you expanded the pocket size for TMs. Is there a way to expand the pocket size for Items pocket? And if so, could you show me what I should do?

Yes, the bag routine is located at 080D65F0.
You can rewrite the routine or branch somewhere to change the value and pointer to be store to 0x2039DD8 region.

 

[LCCoolJ95]

Yes, the bag routine is located at 080D65F0.
You can rewrite the routine or branch somewhere to change the value and pointer to be store to 0x2039DD8 region.

Is the above routines only meant for the TM pocket, or is it meant for any of the pockets? If so, how would I rewrite the routine to have it expand the Items pocket?

 

[Starfall321]

Is the above routines only meant for the TM pocket, or is it meant for any of the pockets? If so, how would I rewrite the routine to have it expand the Items pocket?

Any of the pockets.
Check my step 2, your routine will be something similar like that.

 

[Starfall321]

After some break for my exam nightmare , I decide come back and finish this thing in my holiday.

The road so far,
I wrote the routines into a piece using kleenexfeu's trick(So you can compile everything in one step and make a patch)
I also done TM/HM Compatibility of ORAS TM/HM set for all 0-774(Missing No. to Volcanion) pokemon and I will include it in next update.
I also fix HM icon thing with some byte change:

Another tricky thing is when you try to use newly created TM, it will come out a string "Booted up an HM." instead of "Booted up an TM."
I also fix this with some byte change:

As you can see I almost done, I will update the thread soon.

Btw I found my step 6 "Fix TM/HM compatibility table" routine at op is not working at all,
suprisingly nobody tell me about this about a month so I assume only quite a little number of you concern about this feature.

Here is the fix

Spoiler:

.org 0x0006E02E
lsl r1, r1, #4 @or a mul for bytes not a power of 2(modify this line if you want more TM)
ldr r0, TMHM_compatibility @new TMHM compatibility table
add r0, r1
ldr r4, get_tm01
sub r4, r7, r4
lsr r1, r4, #0x3 @div 8, round down
ldrb r0, [r0, r1]
lsl r1, r4, #0x1D
lsr r1, r1, #0x1D
lsr r0, r1
lsl r0, r0, #0x1F
lsr r0, r0, #0x1F
pop {r4-r5}
pop {r1}
bx r1

.align
get_tm01: .word 0x17B
TMHM_compatibility: .word 0x0F00000

 

[Xencleamas]

I've tested it and it works. But, what about for editing TM/HM compatibility? That's the only problem left for me. I tried tools to edit compatibility but gives an error. Do you have guides for that?

 

[AtecainCorp.]

I start remade that code for Pokemon Ruby

 

[Delta231]

I start remade that code for Pokemon Ruby

You are just wasting your time doing binary hacking in Ruby, switch to Decomps. This thing would be a lot easier instead of finding appropriate routines and ram address.

 

[BluRose]

You are just wasting your time doing binary hacking in Ruby, switch to Decomps. This thing would be a lot easier instead of finding appropriate routines and ram address.

while you aren't entirely wrong, there's no such "waste of time" thing involved anywhere
hack what you're comfortable with, there's no "correct" way; people still binary hack crystal