Porting Super Monkey Ball NTSC 16:9 code to PAL (learn along with me)

[patters]

There are a few games that still don't have satisfactory 16:9 patches for all regions, so I'm interested to try to port some existing codes. For instance, Super Monkey Ball has a 16:9 code for NTSC (from the Dolphin emulator wiki), but not for PAL. My historic save for SMB is for the PAL version so I'd prefer to play that version. In doing a bit of research I have seen several mentions of a tool that can automate this process, though not always reliable. It's called "Bean's Auto Porter" but I haven't been able to find much info on it at all. Is anyone familiar with it - could someone upload it to the Software section of this forum perhaps?

[Andross89]

There are a few games that still don't have satisfactory 16:9 patches for all regions, so I'm interested to try to port some existing codes. For instance, Super Monkey Ball has 16:9 codes for NTSC (via @Ralf here, and a longer one over at the Dolphin emulator wiki), but not for PAL. My historic save for SMB is for the PAL version so I'd prefer to play that version. In doing a bit of research I have seen several mentions of a tool that can automate this process, though not always reliable. It's called "Bean's Auto Porter" but I haven't been able to find much info on it at all. Is anyone familiar with it - could someone upload it to the Software section of this forum perhaps?

If you can import and export the save, it's easy to change it to be compatible with another region. If the game allows.

And it can be much faster to find out the addresses with the RAW generated by Dolphin.

Unfortunately, I never hear of the tool you are looking for.

[patters]

I did try that save conversion method, but it didn't work in this case. Looks like I'll have to export RAM dumps from Dolphin and try to find the new offset locations.

EDIT - aha! I found it. Looks like it may be a Wii tool primarily, but since Gecko codes appear to be shared between the platforms then hopefully it remains useful for GameCube.
https://mkwii.com/showthread.php?tid=17 ... an#pid6967

Uploading in case it vanishes forever. Doesn't come up at all in Google searches.
VirusTotal analysis of the file is clean for 63 different scanning engines:
https://www.virustotal.com/gui/file/d29 ... /detection

[Andross89]

I did try that save conversion method, but it didn't work in this case...

Have you used Hex editor and changed the first save values to be recognized by another region? Strange... I remembered that this works with any game.

What I couldn't do was rename a profile of a specific game. But I don't think I tried enough.

Anyway, the problem was solved in the end.

[patters]

It was a few months ago. When I tried it though, the game just behaved as if the save was corrupt.

Anyway, the problem was solved in the end.

Not quite , 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 here.

[Andross89]

Not quite , 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 here.

Have you tested this tool by converting a simple address? I have my doubts if this can really work.

I have always used Dolphin + Hex editor to convert codes between region and just can't find the joker address inside the ASM and the pointer.

[patters]

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.

[Andross89]

I don't own that game. Assuming the address 800E43B4, 80084A40 and their sequence is correct, the only thing I can say is to try this forced game on 480 with the code activated.

And if you can, make the ARM version of that code. I know Swiss doesn't like the ASM version of Wiird very much.

[patters]

Not sure I follow you. ARM is a different CPU architecture. The ASM code is for the PowerPC gecko processor, not for Wiird. Did you mean AR as in Action Replay? I've never had any issue with the Wiird implementation built into Swiss. There were some lack of spare RAM issues recently when multiple Swiss graphics hacks were combined but the latest builds have that fixed now. I am always running in 480p.

Holy crap! I've solved it. I tested this quite late last night and I failed to realise that I still had the Swiss widescreen hack enabled at the same time. With that turned off I can confirm that the code is successfully ported to PAL. Yahoo!

It has been an interesting exercise - getting to understand how this all works. I'll started new forum threads for the actual codes (following Ralf's standard template), since this game doesn't currently have any here.

[Andross89]

Great. Now we have an ending.

Just to confirm:

ARM = Action Replay Max

[patters]

I don't know how I would test AR codes though (I just use Swiss on real GameCube hardware), so I'll leave that conversion to someone else. From what I gather though, WIIRD -> unencrypted AR is pretty easy once you have codes for each region successfully ported. I think the port is the hardest part.

And now for my next endeavour - a 16:9 code for Legend of Zelda:Twilight Princess PAL. Conspicuously missing from the Dolphin wiki.

[Andross89]

In theory, and if there is no conflict in the 80003200 area, ARM it would look like this:

NTSC

Code: Select all

04003200 C0030000
04003204 3DC03F40
04003208 91C20004
0400320C C2220004
04003210 EC110032
04003214 D0030000
04003218 C003000C
0400321C EC110032
04003220 D003000C
04003224 480E1194
040E43B4 4BF1EE4C
04084A40 4E800020
04020ADC C3A2C244
0405C55C 4E800020
04098410 4E800020
04099968 4E800020
040976BC 4E800020

TDEK-KH7E-G1NQC
JAW4-QCUG-0KUFY
CTGK-UGZN-RUFV3
QKXV-5C66-RZZX4
4942-P0ZZ-VJ3YX
1D1K-9KDB-FZK49
ZBV6-M2MA-C1U7H
QWY2-G813-2670G
AH51-YXN2-G9DB6
D31Y-X92H-PZ8RF
JH46-ZBKJ-1NX0C
6EJY-3KVB-D3RW4
GKQ0-F4A8-494M9
BC29-XTRQ-B9DFZ
FRP6-RWC9-X62Z9
GU92-GXV4-4HPEM
16F1-ZN62-F5AQW
189M-DJ0F-CBUPY

PAL

Code: Select all

04003200 C0030000
04003204 3DC03F40
04003208 91C20004
0400320C C2220004
04003210 EC110032
04003214 D0030000
04003218 C003000C
0400321C EC110032
04003220 D003000C
04003224 480F0594
040F37B4 4BF0FA4C
0408CDA4 4E800020
04021B00 C3A2C244
0406023C 4E800020
040A1AD0 4E800020
040A3028 4E800020
040A0D7C 4E800020

7XN9-CC1N-042VJ
JAW4-QCUG-0KUFY
CTGK-UGZN-RUFV3
QKXV-5C66-RZZX4
4942-P0ZZ-VJ3YX
1D1K-9KDB-FZK49
ZBV6-M2MA-C1U7H
QWY2-G813-2670G
AH51-YXN2-G9DB6
D31Y-X92H-PZ8RF
08W1-4MVR-EM985
06V2-71V5-Z17TW
KGZU-XAAV-9P45V
6JUQ-FA2G-2HER2
8V55-F3ET-1BZZ7
Y06C-QF0D-EK5GC
ENNK-3EQU-23RWV
4PYQ-K9F7-0WDAC

I always use it like this in Swiss. And also on real hardware.

In the future, you may want to use these tools:

viewtopic.php?f=24&t=4763&p=47928#p47928

[Papy.G]

And now for my next endeavour - a 16:9 code for Legend of Zelda:Twilight Princess PAL. Conspicuously missing from the Dolphin wiki.

That would be really awesome, I can't wait!

[patters]

Unfortunately, it didn't work. The NA 16:9 code for Twilight Princess is ridiculously long. Looks like gamemasterplc decided to hack the HUD elements to the corners of the screen, while maintaining the 4:3 aspect, so there is a lot of altered code. The porting tool was able to find all the addresses except for one. And the RAM dumps look very different around that target region so I couldn't find it manually. Many small (e.g. 4byte) searches for the problematic NA target data (and data near the target) simply don't exist at all in the EU RAM dump. I also decided to try comparing the JP RAM dump and that had even more unsuccessful addresses.

I tried removing that one problematic (and small) C2 block from near the end of the code. The game booted but all the 2D elements on screen ended up squished into the first half of the screen width unfortunately, so it seems like it's not some small detail that could be left out.

So, then I thought - maybe I can port the smaller JP 16:9 code from the Dolphin wiki, but that would simply crash the porting tool. Looking at the code it looks corrupt to me. The gecko specs state that a C2 ASM insert code should be terminated by a 00000000, but there isn't one in that block. Needless to say, the JP game wouldn't even boot with that code enabled, so it's a non-starter. I think it would be great if we could contact gamemasterplc and isolate specifically the frustrum culling patch (presuming there is one), because Ralf's 16:9 code is fine but for that one detail really.

What confuses me, is that I'm sure at one point a few months ago I played Twilight Princess in 16:9 and with a 4:3 HUD, like how the best Wind Waker code does it. Did I imagine this? The Swiss widescreen hack for 2D+3D doesn't help here (though it does for Wind Waker). Perhaps I used the US version of Twilight Princess at one point when I tested, then decided to use EU region to play, since I have the EU disc.