When I divide 35 by 102, the result is roughly 0.343137, so I'd say 34 would be right here. The idea behind adding half of the denominator before dividing is that you essentially increase the quotient by 0.5, and then the decimal places get cut off. So if the digit after the point is 5 or higher, you'll reach a new integer, thus it rounds correctly.
Oh, that's quite nice. I hadn't thought of doing things like that, very nicely done. My only suggestion is that you use div instead of SWI if you're not using the modulo div component (pretty sure it's faster).
.text
.align 2
.thumb
.thumb_func
Main:
push {r0-r6}
[B]ldr r0, =(0x205) @doing this is perfectly fine too[/B]
ldr r3, =(0x806E6D0 +1)
bl linker
cmp r0, #0x0
beq end
ldr r5, =(0x2024284) @change this to storage location if u wish
mov r6, #0x0
Loop:
cmp r6, #0x6
beq end
mov r0, r5
mov r1, #0x64 @size, compressed should be 0x50. Party-swap I made will uncompress them when swapping though.
mul r1, r1, r2
add r0, r0, r1 @pokemon to copy
mov r4, r0
ldr r3, =(0x803E47C +1)
bl linker
ldr r4, =(0x202402C)
add r1, r1, r4 @place to put copied mon
@ here you should call memcpy, check IDA for offsets
add r6, r6, #0x1
b loop
end:
@end, return to hooked section, and restore overwritten instructions
linker:
bx r3
.align 2Hook location is 0x112F8,
.text
.align 2
.thumb
.thumb_func
Main:
push {r0-r6}
ldr r0, =(0x205) @doing this is perfectly fine too
ldr r3, =(0x806E6D0 +1)
bl linker
cmp r0, #0x0
beq end
ldr r5, =(0x203C000) @changed to storage
mov r6, #0x0
Loop:
cmp r6, #0x6
beq end
mov r0, r5
mov r1, #0x50 @changed to compensate for the storage
mul r1, r1, r2
add r0, r0, r1 @pokemon to copy
mov r4, r0
ldr r3, =(0x803E47C +1)
bl linker
ldr r4, =(0x202402C)
add r1, r1, r4 @place to put copied mon
ldr r3, =(0x81e5e78 +1) @memcpy as you requested
bl linker
add r6, r6, #0x1
b loop
end: @ending stuff from hook
pop {r0-r6}
ldr r0, =(0x400)
cmp r1, r0
bne place
mov r0, #0x0
ldr r3, =(0x80116AC +1)
bx r3
place:
ldr r3, =(0x8011304 +1)
bx r3
linker:
bx r3
.align 2.text
.align 2
.thumb
.thumb_func
Main:
push {r0-r6}
ldr r0, =(0x205) @doing this is perfectly fine too
ldr r3, =(0x806E6D0 +1) @flag check
bl linker
cmp r0, #0x0
beq end
ldr r5, =(0x203C000) @changed to storage
mov r6, #0x0
Loop:
cmp r6, #0x6
beq end
mov r0, r5 @storage offset
mov r1, #0x50 @[b]changed to compensate for the storage[/b]
mul r1, r1, r2 @[b]what is r2? is this not meant to be mul r1, r1, r6?[/b]
add r0, r0, r1 @pokemon to copy
mov r4, r0
ldr r3, =(0x803E47C +1) @calc effective stats
@[b]won't this overwrite the first 20 bytes of the next pokemon?[/b]
bl linker
ldr r4, =(0x202402C)
add r1, r1, r4 @place to put copied mon
@[b]r1 will NOT be the same as it was before bl linker[/b]
ldr r3, =(0x81e5e78 +1) @memcpy as you requested
bl linker
add r6, r6, #0x1
b loop
end: @ending stuff from hook
pop {r0-r6}
ldr r0, =(0x400)
cmp r1, r0
bne place
mov r0, #0x0
ldr r3, =(0x80116AC +1)
bx r3
place:
ldr r3, =(0x8011304 +1)
bx r3 @[b]this instruction is unnecessary[/b]
linker:
bx r3
.align 2Push {r0-r7, lr}
.....
pop {r0-r7}Well while not as simple as a misaligned stack, a lot of the issues I was having was caused by the RAM offset I was using. Swapped to 0x0203E000 and now the only issue I have is routine based and probably wont be too hard to fix.
Touched's ASM Tutorial said:
LDR R0, = 0x0202E8C4
LDRH R0, [R0]
CMP R0, #1
BNE FINENo clue on the ram map of ruby (not even the rom map, tbh). But assuming that code is correct, the only logical place would be the 0x0202E8C4. I think that because ruby doesn't use DMA***, you can simply access the variable address directly. Do you have a ram map for ruby? You literally just replace that address with the offset for var 0x4015.
Does the machine automatically read pop's bracket in reverse order? (So it first pops PC, whose content becomes that of LR, then r2, r1, r0?)