ROM Hack Help hacking rumble of Omega DE into Pokemon Pinball Ruby & Sapphire (Potential Bounty)

Phrankles · Sep 22, 2021

I have an EZ Flash Omege DE and I have been working on hacking the rumble feature of the cart into the game. Fortunately, I know the game has rumble built in for the gamecube gameboy player. I also know from a previous comment that the way these games work is by detecting the gameboy player and setting a flag in memory to enable the rumble option. I believe this should be as simple as finding the flag, enabling it, and swapping the rumble function to the one provided by ez flash. I have been desperately trying to debug the assembly in no$gba but have not had any luck finding either the flag or the function location. If anyone could provide me a better debugging strategy in no$gba that would be most righteous. Alternatively, if anyone can find the flag and function, or is willing to create the patch themself I would be willing to pay a $20 pay-pal bounty. For reference the guide to adding the Omega DE rumble code can be found by searching "rumble_tutorial gba temp" in google, this site won't allow me to add hyperlinks as a new user.

Phrankles · Sep 24, 2021

Update: I now know the exact address of the arm op code I need to replace with a jump statement: 0x080011b0

and the location I have decided to place the ezflash provided rumble function: 0x0817d7c0

At this point, all I need is to perform the calculation to get the correct jump offset, and it has been giving me hell.

This is the provided example:

Code:

Calculate the jump address from 0xA20C0 to 0x3E7900. Here it is important to distinguish between arm32bit
code or thumb16bit code. This game is 16bit.
0x3E7900-0xA20C0=0x345840
0x345840-4=0x34583C
High=0x34583C>>12=0x345
Low=(0x34583C&0xFFF)/2=0xC1E
machineCode = ((0xFF00 | low) << 16) | (0xF000 | high)= 0xFC1EF345

However, I have not been able to reproduce the result of the example, let alone produce my own offset. If someone can walk me through this calculation it would be most appreciated.

Phrankles · Sep 25, 2021

I used the debugger of no$gba in order to write the instruction manually into memory and see how it interprets the jump offset, was able to determine it from there. I now have a ROM that is working, however I had to replace some of the original assembly code in order to prevent an infinite loop within what I believe to be the rumble subroutine. I believe the code is related to rumble anyway so it probably doesn't matter, but I'm going to test for several rounds on both tables to see if anything is broken. Should have a public patch available in a few days.

djedditt · Sep 28, 2021

Phrankles said:
Update: I now know the exact address of the arm op code I need to replace with a jump statement: 0x080011b0

and the location I have decided to place the ezflash provided rumble function: 0x0817d7c0

At this point, all I need is to perform the calculation to get the correct jump offset, and it has been giving me hell.

This is the provided example:

Code:

Calculate the jump address from 0xA20C0 to 0x3E7900. Here it is important to distinguish between arm32bit code or thumb16bit code. This game is 16bit. 0x3E7900-0xA20C0=0x345840 0x345840-4=0x34583C High=0x34583C>>12=0x345 Low=(0x34583C&0xFFF)/2=0xC1E machineCode = ((0xFF00 | low) << 16) | (0xF000 | high)= 0xFC1EF345

However, I have not been able to reproduce the result of the example, let alone produce my own offset. If someone can walk me through this calculation it would be most appreciated.

Calculating the jump offset has been giving you hell, because the calculation provided by EZ-Flash for encoding the offset in the bl instruction is wrong. The low part calculation example says (0x34583C&0xFFF)/2, but that should be (0x34583C/2)&0xFFF = 0xC1E. Even with that fixed, the calculation still doesn't always work out as valid instruction - just forget about it.

Instead, it's easier and much more reliable to write a few lines of code with hardcoded addresses (use a relative offset, much faster) and then let a compiler handle it. Grep the non-zero lines from the binary data and voilà - you have a perfect bl opcode every time.

Let's take your jump offset as example, 0x0817d7c0 - 0x080011b0 = 0x17c610:

Code:

.thumb
.org 0x0
bl test
.org 0x17c610
test:

Compile and check objdump -s or the binary with grep:

Code:

Contents of section .text:

 000000 7cf106fb 00000000 00000000 00000000  |...............

That's it!

Phrankles · Sep 28, 2021

djedditt said:
Calculating the jump offset has been giving you hell, because the calculation provided by EZ-Flash for encoding the offset in the bl instruction is wrong. The low part calculation example says (0x34583C&0xFFF)/2, but that should be (0x34583C/2)&0xFFF = 0xC1E. Even with that fixed, the calculation still doesn't always work out as valid instruction - just forget about it.

Instead, it's easier and much more reliable to write a few lines of code with hardcoded addresses (use a relative offset, much faster) and then let a compiler handle it. Grep the non-zero lines from the binary data and voilà - you have a perfect bl opcode every time.

Let's take your jump offset as example, 0x0817d7c0 - 0x080011b0 = 0x17c610:

Code:

.thumb .org 0x0 bl test .org 0x17c610 test:

Compile and check objdump -s or the binary with grep:

Code:

Contents of section .text: 000000 7cf106fb 00000000 00000000 00000000 |...............

That's it!

Thanks! This should be super helpful for future hacks.

ROM Hack Help hacking rumble of Omega DE into Pokemon Pinball Ruby & Sapphire (Potential Bounty)

Active Member

Active Member

Active Member

Member

Active Member

Similar threads

Popular threads in this forum