Question Concerning Assemble ARM

[Kngt_Of_Titania]

I've finally managed (I think) to learn enough assembly to pull off my hack, but when I go to test the ARM Assembler, things go awry. Since a picture is worth a thousand words:

This happens whenever I drag and drop Hector Hard Mode.asm (not my hack; just a famous old one I know is formatted correctly to test that everything is working right) on Assemble ARM. I have devkitpro dowloaded, have restarted my computer, uninstalled and reinstalled multiple times, and yet I still get this. Windows 7 OS, if that is relevant.

Does anybody know what's going on here, and how to fix it?

[Crimson Red]

As I mentioned in the tutorial, I'm really not sure, but check the aforementioned directory/files to see if they actually exist. Supposedly someone had luck by moving the folder to their desktop (no idea how this would work), but tbh I really don't know why it's such a pain for people to install, and I did it myself ages (well, I think more like years but exaggerating is fun) ago so I don't remember how I did it.

Edited April 2, 2013 by Burning Gravity

[Kngt_Of_Titania]

As I mentioned in the tutorial, I'm really not sure, but check the aforementioned directory/files to see if they actually exist. Supposedly someone had luck by moving the folder to their desktop (no idea how this would work), but tbh I really don't know why it's such a pain for people to install, and I did it myself ages (well, I think more like years but exaggerating is fun) ago so I don't remember how I did it.

Yeah, I read that. Tbh, I was actually following your tutorial. :D

P.S. I managed to find the FE7 Crit function on an obscure link, found similar code in FE8, and then used breakpoints it to backtrack to the variable that calculates base crit; the whole process took forever, but your last post helped me tremendously.

I could not, for the life of me, go from Eirika's LUK stat to where I needed to go, simply because WAY too many things called it even when I sent Eirika to attack an enemy -- it would've taken forever (for ME) to sort through the mess.

EDIT: I tried both of these options (files DO in fact exist; moved the folder to desktop). Neither of them worked. Not sure where to go from here. Anybody else have any ideas or would be willing to run it through the assembler for me?

Edited April 2, 2013 by Kngt_Of_Titania

[CT075]

if you're using the most recent build of devkitPro, the file is named "arm-none-eabi-[TOOLNAME]"

[Kngt_Of_Titania]

if you're using the most recent build of devkitPro, the file is named "arm-none-eabi-[TOOLNAME]"

I have v1.5.3, which should be the latest version. Downloaded it from the link in Burning Gravity's tutorial.

So, understanding you correctly, I should have them (files referenced in DOS are in black; folder location is in red):

Confirming that they are there, I then went to "Environment Variables" and changed "Path" under "System Variables."

Old Path: c:\devkitPro\msys\bin; etc.

New Path: c:\devkitPro\msys\bin;c:\devkitPro\devkitARM\bin;c:\Users\Ryan\Desktop\devkitPro\devkitARM\arm-none-eabi\bin; etc.

The bolded is from the red box from the first picture. Italicized is a guess.

However, despite this, things still won't work. Am I doing something wrong here? Missing something? I feel so close to finishing this, yet so far away.

Edited April 3, 2013 by Kngt_Of_Titania

[Crimson Red]

ASM is a lot of trial and error, doubt you'll simply be able to get someone to constantly assemble them for you. Try a different computer or even looking up info on getting devkitARM to work on Google or something (though you may have already done so...).

[Kngt_Of_Titania]

ASM is a lot of trial and error, doubt you'll simply be able to get someone to constantly assemble them for you. Try a different computer or even looking up info on getting devkitARM to work on Google or something (though you may have already done so...).

Yeah, I'd rather not have to rely on somebody else to assemble, but if I have no other choice, I don't know what else to do.

Sad part is I get the exact same problem when I try it on my other computer.

Is devkitPRO the only thing that needs to be installed for this assembler to work?

EDIT: On a side note, is there anything really fishy with this code? Should be pretty simple, but I'm not *entirely* sure about a couple aspects of it. It's essentially what I'm trying to insert.

.thumb

.org 0x02AC2A

bl Lucky @0802AC2A is the area near where crit formula is calculated

Initial:

.org 0x855060 (I THINK this is free space on the ROM)

Lucky:

push {r4,r5,lr} @Safe to push these

add r1, r1, r2 @First two lines

asr r1, r1, #0x1 @Are from old program

ldrb r4, [r7, #0x19] @r7 is where character's stat starts at 0802AC2A; 0x19 is to pull up LUK

mov r5, #0x5555 @0x5555 is approx. 2^16 divided by 3

mul r4, r5 @Multiply r4 by r5

lsr r4, r4, #0x10 @Divide by 2^16, these three lines effectively divide r4 by 3

add r1, r1, r4 @r1 is base crit, r4 is extra crit from LUK

pop {r4,r5,pc} @Standard pop

bl Initial

Edited April 3, 2013 by Kngt_Of_Titania

[CT075]

you completely misinterpreted what i said

open up the "assemble ARM.bat" in notepad

in every place where you see "arm-eabi" replace it with "arm-none-eabi"

.thumb
.org 0x02AC2A

@-----------------
@ I am about 60% sure that bl doesn't reach far enough for this.		
@		bl Lucky				@0802AC2A is the area near where crit formula is calculated
               ldr             r0, =Lucky
               bx              r0

@		Initial:
@ Unnecessary

.org 0x855060 (I THINK this is free space on the ROM)
	Lucky:
	push	{r4,r5,lr}  	@Safe to push these
	add		r1, r1, r2  	@First two lines
@-----------------
@ This effectively divides r1 in half. If you had something along the lines of lsl #0x1
@ right after I would recommend that you put that back in.
	asr		r1, r1, #0x1 	@Are from old program
	ldrb	r4, [r7, #0x19]	@r7 is where character's stat starts at 0802AC2A; 0x19 is to pull up LUK
	mov		r5, #0x5555		@0x5555 is approx. 2^16 divided by 3
	mul		r4, r5			@Multiply r4 by r5
	lsr 	r4, r4, #0x10	@Divide by 2^16, these three lines effectively divide r4 by 3
	add		r1, r1, r4		@r1 is base crit, r4 is extra crit from LUK
	pop		{r4,r5,pc}		@Standard pop
@-----------------
@ popping PC already returns you to the initial state               
@		bl		Initial

Edited April 3, 2013 by CT075

[Kngt_Of_Titania]

you completely misinterpreted what i said

open up the "assemble ARM.bat" in notepad

in every place where you see "arm-eabi" replace it with "arm-none-eabi"

This worked perfectly. Thank you!

.thumb
.org 0x02AC2A

@-----------------
@ I am about 60% sure that bl doesn't reach far enough for this.		
@		bl Lucky				@0802AC2A is the area near where crit formula is calculated
               ldr 			r0, =Lucky
               bx              r0

@		Initial:
@ Unnecessary

.org 0x855060 (I THINK this is free space on the ROM)
	Lucky:
	push	{r4,r5,lr}  	@Safe to push these
	add		r1, r1, r2  	@First two lines
@-----------------
@ This effectively divides r1 in half. If you had something along the lines of lsl #0x1
@ right after I would recommend that you put that back in.
	asr		r1, r1, #0x1 	@Are from old program
	ldrb	r4, [r7, #0x19]	@r7 is where character's stat starts at 0802AC2A; 0x19 is to pull up LUK
	mov		r5, #0x5555		@0x5555 is approx. 2^16 divided by 3
	mul		r4, r5			@Multiply r4 by r5
	lsr 	r4, r4, #0x10	@Divide by 2^16, these three lines effectively divide r4 by 3
	add		r1, r1, r4		@r1 is base crit, r4 is extra crit from LUK
	pop		{r4,r5,pc}		@Standard pop
@-----------------
@ popping PC already returns you to the initial state   			
@		bl		Initial

For this code, I'm having one last problem (I know, I know, but basically I can't imagine anything going wrong past this):

[spoiler=My Issue]

This is the code based off of revisions you gave me (sorry, the .org 0x02AC2A in this pic should be 0x02AC28):

Those two lines of code? I'm trying to add them to 0802AC28 -- I'm utilizing the fact that, when this ASM is called, r1 stores base crit and r7 stores the offset where the character's stats begin, which I'm about 75% sure will work since I don't push either r1 or r7. Here's a pic of the ASM code around where I'm trying to stick the bx opcode:

It gives this error message:

Am I trying to branch too far even for the "bx" command? And if so, where can I find room in the ROM that is closer to 0x02AC2A (or at least close enough to branch to)?

Edited April 3, 2013 by Kngt_Of_Titania

[CT075]

oh

that was my bad, i forgot that you were using .org (the notation I used doesn't work unless you use the assembly patcher format i'm used to)

incidentally in the future it helps to note what line is line 4 (in this case it doesn't matter since 4 is a small number but if it's like line 19 i'm too lazy to count)

change the first ldr from =Lucky to =0x08855060

EDIT

it is also literally impossible to outrange bx since it branches to a register

Edited April 3, 2013 by CT075

[Kngt_Of_Titania]

oh

that was my bad, i forgot that you were using .org (the notation I used doesn't work unless you use the assembly patcher format i'm used to)

incidentally in the future it helps to note what line is line 4 (in this case it doesn't matter since 4 is a small number but if it's like line 19 i'm too lazy to count)

change the first ldr from =Lucky to =0x08855060

EDIT

it is also literally impossible to outrange bx since it branches to a register

Yep, works now. All the code has transferred perfectly except for this =0x08855060 part. Basically, I'm taking the hex values from the .dmp file and copying and pasting them in the proper sections of the FE8 ROM. Unfortunately, everything is transcribing perfectly (checking the No$GBA debugger) EXCEPT for that one line. Essentially it's transcribing the opcode as ldr r6 =#0x43086AA1 instead of ldr r6 =0x08855060. Don't know why this is happening, but once this is fixed, my hack is officially finished.

I am, however, confused as to exactly ldr works. How can you allow for every permutation of every word you can load in only...two bytes?

Edited April 4, 2013 by Kngt_Of_Titania

[CT075]

you can't

ldr r0, =0xDEADBEEF

is pretty much the same thing as

ldr r0, [pc, #0xNN]

@ 0xNN bytes later

.long 0xDEADBEEF

EDIT

it's not being written properly because the data in the ROM is wrong (or at least the relevant data isn't being written correctly, if I had to guess you'd find 60 50 85 08 around the area you wrote the actual code to)

i can't tell you how to fix it (Blazer would know better) because i don't use .org in my hacks

EDIT2:

also on further inspection that code won't work at all

you're pushing and popping lr into pc which returns you to wherever the original routine came from, which is potentially not where you want to go (based on what you were trying to do earlier it isn't)

there are a couple ways to fix it

1) stick a bl code to your own stuff (like this:)

@ These two lines are at about the same place
CODE_ST:
   bl      ext_func
   b       label1

ext_func:
   ldr     r0, =0xDEADBEEF
   bx      r0

label1:
@ rest of code

2)

CODE_ST:
   ldr     r0, =0xDEADBEEF
   bx      r0

@ This the a known offset where the code needs to continue, that is, you determined it by looking at the original routine
.L_known:
   @ ...

.org     0xDEADBEEF

ext_func:
   @ ....
   ldr     r0, =.L_known       @ .L_known isn't going to be a label, it's going to be an actual number
   bx      r0

3)

just rewrite the entire damn routine in the new place, thus bypassing the issue altogether

I would personally use the third option.

And FINALLY, you're clobbering r6. That's dangerous, don't do that.

Edited April 4, 2013 by CT075

[Crimson Red]

I'm pretty sure you don't do "=Lucky", just "Lucky"...

Cam knows more proper ASM stuff, if you can you should learn from him

Don't use r6 for the bx code as he said

And as the tutorial explains it appends values to the end (or else you append the values manually)

e.g.

ldr r0, Offset

...

Offset:

.long 0x0202BC50

I'm sure one of the parts of the tutorial talk about this... If not I have more work to do >_<

Edit: on my phone as usual so sorry I'm advance for any mistakes

Edited April 4, 2013 by Burning Gravity

[Kngt_Of_Titania]

Sorry for the late delay, but I FINALLY got it all ironed out. Yes, the patch is done!

After this much effort, I might post my code here in on Serenes for people to use/test. I have two versions: One that adds (LUK/2) to the crit chance, and one that adds (LUK/3). It's a bit sketchy how I got around all of the technical difficulties, but it seems to work perfectly -- I have yet to get it to act weird, but it's still possible.

Special thanks, of course, to Burning Gravity and CT075 for making this possible, and for the patience to walk me through my first ASM hack. When I finally get around to posting the thread for my remake, you guys will definitely have your own special section.

EDIT: Oh yeah, it turns out that CT075 was right the first time; it is r0, =Lucky. What seems to have happened is a limitation of the .org format, although it's hard for me to explain.

[spoiler=Me Failing to Explain]As CT075 said:

ldr r0, =0xDEADBEEF

is pretty much the same thing as

ldr rY, [pc, #0xNN]

@ 0xNN bytes later

.long 0xDEADBEEF

From playing around, it seems that the two bytes in Hex end up being MM 4X. It looks like the system basically says "Alright, after [2 + (4*MM)] = NN bytes, treat the next four bytes as a word and load it to the register in question." It seems that the fourth digit, X, is used to determine which register is used.

The Assembler looks like it is sticking all the .long 0x00000000 at the end of the code for the ldr opcodes and then putting in values of MM to make it work. The problem comes with the fact that MM is only one byte, which means that the distance it can go to pull up the .long is very limited. For almost all hacks (i.e. those added to the ROM rather than REPLACING CODE IN THERE), this would never come into play, as they would never be long enough to run into the problem.

However, since I'm putting in the ldr & bx at offset =0x02AC24 but inserting the main section of the code at offset =0x855060, the assembler is sticking the .long at the end of the code around =0x855089 but trying to link it to the ldr at around =0x02AC24, which isn't going to happen. This means that I have to insert the .long called by ldr manually, tell the assembler that the main section of my code is close to =0x02AC24 (but it's not) so it won't go berserk, paste the code from the .dmp file instead at =0x855060, and then go into the Hex editor and adjust MM so that the ldr properly calls the .long I inserted into my code instead of whatever the assembler told it to do. Not that big of a deal, IF YOU KNOW WHAT THE HELL IS GOING WRONG. I didn't.

And this is why I thought bx had a limited range. Essentially, it wasn't bx that was the problem, it was the limitations of ldr rY =0xDEADBEEF and the way the assembler coded the .dmp file that was giving me shit.

I think.

On a side note, I just read through this and realized that a week ago I didn't even know what ASM was. Yay for the Ultimate Tutorial and people willing to help me out~

Edited April 5, 2013 by Kngt_Of_Titania

[CT075]

you know it would be way easier to get around that problem if people would follow hextator/my example and just use the assembly patcher format

[CT075]

asdf

Edited April 7, 2013 by CT075

[Crimson Red]

...probably...

Meh, I'm really not interested but I'll think about it. (Explaining your thing, that is...)

EDIT: Regarding your problem, you just had to tuck the .long with the ldr code (at the end of it). Meaning you'd need to replace 8 bytes total.

Edited April 7, 2013 by Burning Gravity

[CT075]

i was kidding but i'd put an explanation/example for it if you were too lazy/didn't feel like doing it