• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • 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.

Help Thread: ASM & Disassembly

Status
Not open for further replies.
OK, I will try. After that I will update the post.
But why shouldn't my code work? I think there's no problem as it simply changes r4.

Because at this line:
Code:
ROM:08108458                 LDR     R0, [R5]

Is overwritten by the hook.
Code:
ldr rX, =(0xOffset +1)
bx rX
The hook takes 8 bytes. So if you hooked at 08108450 then the hook bytes take upto 08108458 inclusive. Also you've overwritten r0 for the "bx" back to the original routine.

If you examine further down:
Code:
ROM:0810845E                 LDR     R1, [R3]
R1 is overwritten and completely free to use for a bx.
 
Because at this line:
Code:
ROM:08108458                 LDR     R0, [R5]

Is overwritten by the hook.
Code:
ldr rX, =(0xOffset +1)
bx rX
The hook takes 8 bytes. So if you hooked at 08108450 then the hook bytes take upto 08108458 inclusive. Also you've overwritten r0 for the "bx" back to the original routine.

If you examine further down:
Code:
ROM:0810845E                 LDR     R1, [R3]
R1 is overwritten and completely free to use for a bx.

Thank U very much for Ur help, but I really don't think so...

[PokeCommunity.com] ASM & Disassembly


For the first problem, @0x08008454 is the pointer so it didn't overwrite 0x08108458 as the picture showed.

For the register used, you can find @0x08108458 R0 will be refreshed by the content in the pointer in r5 so I think I can use it to get back to the original routine.

In addition, I modified the second routine in my previous reply (Just to fix some silly mistakes).
P.S. I've added your skype.
Hoping that you will point out my mistake, thank you!
 
Last edited:
Thank U very much for Ur help, but I really don't think so...

[PokeCommunity.com] ASM & Disassembly


For the first problem, @0x08008454 is the pointer so it didn't overwrite 0x08108458 as the picture showed.

For the register used, you can find @0x08108458 R0 will be refreshed by the content in the pointer in r5 so I think I can use it to get back to the original routine.

In addition, I modified the second routine in my previous reply (Just to fix some silly mistakes).
P.S. I've added your skype.
Hoping that you will point out my mistake, thank you!

Well, that's embarrassing. Sorry, I forgot how to count 8 bytes :)

Anyways, if that wasn't it, I don't know! Can I see a screenshot of the compiled version of your code? Just like the one previous where you showed me that those two bytes weren't overwritten.

The registers are safe, and the source code looks correct. The only other possibility I can think of is miscompilation/word alignment in the routine you've said you've added.
 
Well, that's embarrassing. Sorry, I forgot how to count 8 bytes :)

Anyways, if that wasn't it, I don't know! Can I see a screenshot of the compiled version of your code? Just like the one previous where you showed me that those two bytes weren't overwritten.

The registers are safe, and the source code looks correct. The only other possibility I can think of is miscompilation/word alignment in the routine you've said you've added.

108450
[PokeCommunity.com] ASM & Disassembly

10848C
[PokeCommunity.com] ASM & Disassembly

800070
[PokeCommunity.com] ASM & Disassembly

800100
[PokeCommunity.com] ASM & Disassembly
 
HELLO AGAIN

So I've been trying to implement some (hopefully simple) bits of ASM to my hack to help enhance the FAME mechanics I have. Scripting does well with this, but I'm hoping ASM can help establish some of the mechanics without me having to repeat myself in scripts.

So the first thing I was looking to do was to lower the value of a var by 3 when you lose. To do this I found the loser text and tracked it back to this routine - since my own routine is short and just involves tweaking a variable I figured I could put it before this text was generated(?) so hooked over to my routine before passing it back.

Spoiler:

However the battle freezes as soon as the trainer sprite scrolls on to the screen at the start of the battle, rather than when a victor is decided.
 
HELLO AGAIN

So I've been trying to implement some (hopefully simple) bits of ASM to my hack to help enhance the FAME mechanics I have. Scripting does well with this, but I'm hoping ASM can help establish some of the mechanics without me having to repeat myself in scripts.

So the first thing I was looking to do was to lower the value of a var by 3 when you lose. To do this I found the loser text and tracked it back to this routine - since my own routine is short and just involves tweaking a variable I figured I could put it before this text was generated(?) so hooked over to my routine before passing it back.

Spoiler:

However the battle freezes as soon as the trainer sprite scrolls on to the screen at the start of the battle, rather than when a victor is decided.

Alright, a few notes:

I suppose you're using 080D7884 for the hook, and not 08D7884. :P
A hook like that takes eight bytes, which means you're also overwriting the cmp r1, #0xFD which comes after the bl.
r6 is not safe to use in this routine, since you can see its original value is still needed after you return from your routine.
You can't bl like that from your routine, use a bx instead.
You can't ldrh a label. :/ Also, you're substracting 3 from the var address and trying to store it in itself. :\
Finally, How will this routine react if the fame var contains a value less than 0? Do you want it to become 0xFFFX?

Fix these and you should be fine :b

EDIT: I haven't checked the viability of your hooking offset though, so I hope you got that one right.
 
I suppose you're using 080D7884 for the hook, and not 08D7884. :P

Whoops, typo in my post. ><

A hook like that takes eight bytes, which means you're also overwriting the cmp r1, #0xFD which comes after the bl.

Don't you hate it when counting to 8 becomes difficult ;-; my brain. So would it be better to hook from 080d7880? Including the lsr up to the bl/bx in my part of the routine.

[PokeCommunity.com] ASM & Disassembly


r6 is not safe to use in this routine, since you can see its original value is still needed after you return from your routine.

Hmm, I was a bit confused as to which ones were viable - since r6 is moved to 0 further up. If I move it back to zero afterwards would it be OK then.

You can't bl like that from your routine, use a bx instead.

Ah, me being lazy - should I changed that one. So I need another register clear for this too.

You can't ldrh a label. :/ Also, you're substracting 3 from the var address and trying to store it in itself. :\

Ah it should be
Code:
ldr r6, var4080
	ldrh r6, [r6]
etc. I'm not sure why I thought I needed a store. I'd only need that if I were copying it elsewhere right?

Finally, How will this routine react if the fame var contains a value less than 0? Do you want it to become 0xFFFX?

I'll sort that one out later lmao.
 
Whoops, typo in my post. ><



Don't you hate it when counting to 8 becomes difficult ;-; my brain. So would it be better to hook from 080d7880? Including the lsr up to the bl/bx in my part of the routine.

That one could work.

Hmm, I was a bit confused as to which ones were viable - since r6 is moved to 0 further up. If I move it back to zero afterwards would it be OK then.

It should be.

Ah, me being lazy - should I changed that one. So I need another register clear for this too.

yup

Ah it should be
Code:
ldr r6, var4080
	ldrh r6, [r6]
etc. I'm not sure why I thought I needed a store. I'd only need that if I were copying it elsewhere right?

Of course you do need a strh. You just need not to overwrite the register containing the address of the var so you can store it after substracting three from it.

I'll sort that one out later lmao.

Just don't forget to.
 
Hmm I made the adjustments and rather than freezing the ROM reset.

I tried slimming my routine down to the basics and the resetting continued think it might be conflicting registers in my hook or bx back?... Hmm ;-;. Might look for another place to hook.

Weird how this is all happening at the beginning of battles rather than the end. Must be a better place.
 
Hmm I made the adjustments and rather than freezing the ROM reset.

I tried slimming my routine down to the basics and the resetting continued think it might be conflicting registers in my hook or bx back?... Hmm ;-;. Might look for another place to hook.

Weird how this is all happening at the beginning of battles rather than the end. Must be a better place.

Show me the routine and hook you're using please. And yeah, that might mean you should choose a better hook location.
 
Show me the routine and hook you're using please. And yeah, that might mean you should choose a better hook location.

Here's what I'm working with atm.

Spoiler:
 
Last edited:
I can see you forgot the +1 when returning through r5. Don't have the time to look at the rest now though, will do tomorrow if you're still experiencing problems.
 
I can see you forgot the +1 when returning through r5. Don't have the time to look at the rest now though, will do tomorrow if you're still experiencing problems.

Ah I didn't even think of that, unfortunately it still resets. Thanks for your help though! I'll let you know if I'm still hitting my head against the wall tomorrow :').

Spherical helped spot a huge mistake anyway. I might get lucky and fix this in the morning.
 
Last edited:
Here's what I'm working with atm.

Try this:

Code:
.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, r0, #0xC0
	ldr r3, =(0x806E454 +1)
	bl linker
	ldrh r3, [r0]
	sub r3, #0x3
	strh r3, [r0]
	pop {r0-r3}
	ldr r2, =(0x80d83f0 +1)
	bx r2


Remember when you call a function, it must be assumed that the function will change what's in register's less than 4. So we need to push them into the stack. Secondly, you're using higher registers when they're not needed. r5 isn't a safe register in this case, nor is r6.

Finally, when a function has a return value, the return value is in r0, rather than the register you use to call the function.
 
Idk what happened but it was hilarious. The game didn't like that routine.

Spoiler:
 
Idk what happened but it was hilarious. The game didn't like that routine.

Spoiler:
lol, sorry. I haven't even read anything you two have been talking about, I just noticed a few errors in the routine and fixed them :c

Use r0 to bx to (0x80d83f0 +1)
 
lol, sorry. I haven't even read anything you two have been talking about, I just noticed a few errors in the routine and fixed them :c

Use r0 to bx to (0x80d83f0 +1)

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!

Code:
.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
 
Status
Not open for further replies.
Back
Top