That Bean's Auto Porter tool unfortunately didn't work at all for me. It doesn't recognise the RAM dumps from Dolphin and complains that input.txt "first line is too short" even though I copied the example layout precisely.
So, I spent a long time yesterday with HxD and the two RAM dumps from Dolphin and painstakingly worked out the new offsets. However, the ported cheat doesn't work entirely correctly. The game does seem to be rendered at the correct 16:9 aspect now, but the actual monkey ball (the player character) isn't. I checked my offsets very carefully by flicking back and forth between the RAM to see that the entire page is very consistent between the two. Some of these codes are in locations which are fairly dissimilar and if you search only for the four byte 32bit number they occur by the hundred, so you have to get very creative as to what your search strings are. Sometimes choosing a chunk before or after your actual target is the only way to find it. Once found flicking the hex view back and forth between the files allows for a reliable confirmation it's a good match. I am very confident I found the correct offsets.
Today though I found a new porting tool which managed to do what took me hours manually in just a few seconds:
Bully's Gecko Code Porter. You have to sign up to that forum to get the download link and then fight through a ton of cookie dialogs and ad-splattered forwarding services etc. Finally you get
Gecko Code Porter.jar. Give it the two RAM dumps and the code you want to port and it does some kind of fuzzy matching that can cope with the source and destination being slightly different. It confirms my own manual work from last night is correct. Here's what I have so far:
Original Super Monkey Ball NTSC code from the
Dolphin emulator Wiki, with my comments - gecko cheat engine functional info from
this guide:
Code: Select all
C20E43B4 00000006 ; prefix C2 means insert the following 6 lines of ASM at offset 0E43B4 from base address
C0030000 3DC03F40
91C20004 C2220004
EC110032 D0030000
C003000C EC110032
D003000C C0030000
60000000 00000000 ; termination for the ASM block
04084A40 4E800020 ; prefix 04 means overwrite offset 084A40 from base address with 32bit word 4E800020
04020ADC C3A2C244 ; repeats
0405C55C 4E800020
04098410 4E800020
04099968 4E800020
040976BC 4E800020
My Ported version (WIP - not working 100%, the monkey ball aspect remains wrong):
Code: Select all
C20F37B4 00000006
C0030000 3DC03F40
91C20004 C2220004
EC110032 D0030000
C003000C EC110032
D003000C C0030000
60000000 00000000
0408CDA4 4E800020
04021B00 C3A2C244
0406023C 4E800020
040A1AD0 4E800020
040A3028 4E800020
040A0D7C 4E800020
It seems this hack isn't simply changing the aspect ratio multiplier for 3D views. It is disabling the map-like overlay in the bottom right of the screen. I'm guessing that's what the ASM code is probably doing, but this is just my speculation. We can see many writes of 4E800020 which is presumably the new aspect ratio.
Looking in more detail at the ASM block, and examining what it's aiming to overwrite in the RAM dump I can see that it appears to be patching:
Code: Select all
C0030000 3DC03F40
91C20004 C2220004
EC110032 D0030000
C003000C EC110032
D003000C C0030000
to:
Code: Select all
C0030000 808D97C8
D0040424 C0030014
808D97C8 D004042C
C0030028 808D97C8
D004043C C003002C
Using a disassembler (
https://onlinedisassembler.com/odaweb/) I
think the original HEX represents the following code (assuming big-endian PowerPC 750 arch) :
Code: Select all
lfs f0,0(r3)
lis r14,16192 ; 0x3f40
stw r14,4(r2)
lfs f17,4(r2)
fmuls f0,f17,f0
stfs f0,0(r3)
lfs f0,12(r3)
fmuls f0,f17,f0
Which again I
think is being patched to:
Code: Select all
fs f0,0(r3)
lwz r4,-26680(r13)
stfs f0,1060(r4)
lfs f0,20(r3)
lwz r4,-26680(r13)
stfs f0,1068(r4)
lfs f0,40(r3)
lwz r4,-26680(r13)
stfs f0,1084(r4)
lfs f0,44(r3)
Since I'm not an assembly language programmer (yet) I've pretty much reached my currently limits. Would anyone else care to chip in and help? My hunch is that the ASM code is referencing address values which will need new offsets to be determined.
, I'm trying to understand how to work with the existing NTSC gecko patch file to unpick what it's actually doing so I can find the memory it's patching. It looks like the Auto-Porter is good for finding equivalent memory addresses in RAM dumps from different versions of the game, but the gecko codes aren't just as simple as RAM addresses from what I can gather. There are different instruction prefixes etc, as documented 