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
47
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
47
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
47
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
110
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
47
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
  • The Real Jdbye @ The Real Jdbye:
    really have to buy the top end model to get a tv that doesnt have any of those compromises and that would've had more dimming zones too but i am not made o money
    Gift
  • The Real Jdbye @ The Real Jdbye:
    @Julie_Pilgrim "very bright" is essentially pure white
    Gift
  • The Real Jdbye @ The Real Jdbye:
    pure white doesn't show up all that much it's mainly when looking at a bright sky
    Gift
  • The Real Jdbye @ The Real Jdbye:
    and if the clouds in the sky have slightly less definition to them because i turned on the contrast enhancer who cares
    Gift
  • The Real Jdbye @ The Real Jdbye:
    that's not important
    Gift
  • The Real Jdbye @ The Real Jdbye:
    i can't tell the difference
    Gift
  • The Real Jdbye @ The Real Jdbye:
    but i can certainly tell the difference with black crush if i'm watching a scifi movie and i can't see wtf is going on
    Gift
  • SG854 @ SG854:
    Human vision is logarithmic, it's not linear. And nits doesn't tell the whole story of perceived brightness. OLED'S look brighter then LCD's even when both are set to the same nit values because of the higher contrast ratio on OLED's
    Gift
  • SG854 @ SG854:
    OLED's have a 3D look
    Gift
  • kenenthk @ kenenthk:
    Charging port is more likely to fry up or battery fail before the display tbh lol
    Gift
  • The Real Jdbye @ The Real Jdbye:
    "And nits doesn't tell the whole story of perceived brightness" it's not about perceived brightness it's about all HDR content in TV and movies being mastered for 1000 nits so it doesn't look right with anything lower, it's also about dynamic range
    Gift
  • The Real Jdbye @ The Real Jdbye:
    "OLED's have a 3D look" no they don't lol
    Gift
  • SG854 @ SG854:
    As an owner of a OLED and you saying that you never seen an OLED I think I know what I'm talking about lol. I'm not talking about 3D as in 3D glasses. I'm talking about depth and pop in the picture
    Gift
  • kenenthk @ kenenthk:
    I mean to be fair og vitas are still kicking and not many have suffered from pixel bleed and they're going on nearly 10 years
    Gift
  • SG854 @ SG854:
    OLED's can get away with a lower peak brightness and still provide punchy HDR because of their contrast ratio. Like I said human vision is logarithmic. The higher the peak brightness the diminishing returns in perceived brightness.
    Gift
  • kenenthk @ kenenthk:
    Just get 5 years enjoyment out of it until Nintendy releases something and everyone forgets about switch games lol
    Gift
  • SG854 @ SG854:
    @The Real Jdbye Oleds hit around 750 nits nowadays. The difference between a 1000 nit and a 750 nit isn't huge. It's only about a 4% increase in perceived brightness. Not huge at all. You'll need at least 2000 nit displays to notice a bigger difference.
    Gift
  • SG854 @ SG854:
    Read this thread it explains it. 1000 nits is not a huge jump from 750 the LG OLEDs can hit. As I said human vision is non linear.
    +2
    Gift
  • Gift
  • mr_switch @ mr_switch:
    Not exactly 3D but the colors does pops out more
    Gift
  • mr_switch @ mr_switch:
    I just want a true dark mode theme
    for OLED Switch
    Gift
  • Julie_Pilgrim @ Julie_Pilgrim:
    yeah honestly i hate how the only two switch theme options are blinding holy light of god or grey
    Gift
  • El_Doot @ El_Doot:
    Kill eyes OR bore eyes to death
    +1
    Gift
  • Julie_Pilgrim @ Julie_Pilgrim:
    switch dark mode is ok i just wish it was a bit darker
    Gift
  • F @ Forseenink3938:
    Can anyone here please help me on how to use TickCrypt 2.0?
    Gift
    F @ Forseenink3938: Can anyone here please help me on how to use TickCrypt 2.0?