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

Phrankles

Active Member
OP
Newcomer
Joined
Sep 22, 2021
Messages
26
Trophies
0
Age
28
XP
50
Country
United States
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

Active Member
OP
Newcomer
Joined
Sep 22, 2021
Messages
26
Trophies
0
Age
28
XP
50
Country
United States
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

Active Member
OP
Newcomer
Joined
Sep 22, 2021
Messages
26
Trophies
0
Age
28
XP
50
Country
United States
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

Member
Newcomer
Joined
Jan 15, 2021
Messages
14
Trophies
0
Age
32
XP
116
Country
Netherlands
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!
 
  • Like
Reactions: Phrankles

Phrankles

Active Member
OP
Newcomer
Joined
Sep 22, 2021
Messages
26
Trophies
0
Age
28
XP
50
Country
United States
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.
 
General chit-chat
Help Users
  • No one is chatting at the moment.
    KennieDaMeanie @ KennieDaMeanie: I couldn't really get into moon it's too different for my likes