Super Monkey Ball 2: Syncing pad data appears to crash game
Last night, I messed with Super Monkey Ball 2 with my recorder. I determined that it will crash on boot (not even getting to the Sega screen) if the only codes in the script are the second set of controller data, or both sets of controller data. Only the first set of controller data resulted in it booting fine, but not syncing at all. For some reason, though, it gets slightly farther when more of the script is entered. With the following script: 04145120 00000000 // Controller data 04145124 00000000 // Controller data 04145128 00000000 // Controller data 041A9E6C 00000000 // Controller data 041A9E70 00000000 // Controller data 041A9E74 00000000 // Controller data 0254DF20 00000000 // Mode Select and Party Game Select menu modifier 0054DF2F 00000000 // Monkey Race 2 -> Mode Select menu modifier 0054DF24 00000000 // Monkey Race 2 -> One Course Race -> Number of Players menu modifier * 0054DF30 00000000 // Race - Level Selected Modifier 0454E058 00000000 // X coord 045BC9A4 00000000 // X coord 0454E05C 00000000 // Y coord (not -*test*-('")ed but should work) 045BC9A8 00000000 // Y coord (not -*test*-('")ed but should work) 0454E060 00000000 // Z coord 045BC9AC 00000000 // Z coord * 045BC9BC 00000000 // X Velocity (un-*test*-('")ed, by Jay007) * 045BC9C0 00000000 // Y Velocity (un-*test*-('")ed, by Jay007) * 045BC9C4 00000000 // Z Velocity (un-*test*-('")ed, by Jay007) 005BD7BB 00000000 // Character Modifier (by Jay007) 0054DF78 00000000 // Character Selected Modifier * 009249D9 00000000 // Race - Item #1 * 009249DB 00000000 // Race - Item #2 * 009249DD 00000000 // Race - Item #3 With this script, the game crashed at the Sega screen (showed Sega logo, and then froze). All -*test*-('")ing was done with 60 updates per second. I used a development beta of my recorder, which compiles to native code, and as such is much faster than the released version. If anyone wants it, I can release it. Fuzziqer, do you have any idea what's wrong?

Try lowering the updates per second (set frames to 2 or 3). For the pad data problem, try this (I think my ASM is right; if you're not sure, disassemble the code): 0401E88C 4BFE2F74 // b 80001800 04001800 7CA802A6 // mflr 5 04001804 497F67FC // bl 0x817F8000 # GCARS-CS entry 04001808 7CA803A6 // mtlr 5 0400180C 3DC08014 // lis 14,0x8014 04001810 3DE0801B // lis 15,0x801B # the 801B is not a mistake 04001814 800E5120 // lwz 0,0x5120(14) 04001818 900F9E6C // stw 0,0x9E6C(15) 0400181C 800E5124 // lwz 0,0x5124(14) 04001820 900F9E70 // stw 0,0x9E70(15) 04001824 800E5128 // lwz 0,0x5128(14) 04001828 900F9E74 // stw 0,0x9E74(15) 0400182C 4E800020 // blr Use that as your enable code. Remove both sets of pad data from the script, and set the game's pad address to 80145120. I'm sorry the code is so long; there's a Memory Copy code in GCARS-CS but I forget how to use it.... if you remember how, just set it up to copy 12 bytes from 80145120 to 801A9E6C. <edit> These enable codes *might* work; I don't recall if I implemented the newest Memory Copy code type or not. One of the following should work: C401E88C 0000FF00 00000000 861A9E6C 80145120 0000000C C401E88C 0000FF00 00000000 201A9E6C 80145120 0000000C

Thanks for the reply. I tried your enable code (the long one) and the pad address you gave me, and started up PadSim. PadSim doesn't seem to do anything, and I can still use the controller on the GameCube (GCN was set to P2, with PadSim as P1, but P1 works on the GCN and not on PadSim). I'm guessing this means that the pad address or enable code is wrong. My recorder does log packets coming from the GameCube, so the hook is running. I set the update speed to 4, to avoid too many packets crashing the game. I've never used PadSim before, so I'm not very familiar with it. Any ideas?

My mistake, sorry. Change the following line (notice the 'D'): 04001804 497F67FD // bl      0x817F8000 # GCARS-CS entry

In that case, the problem is one of three things: 1. I used a register that the game needs 2. I compiled my code improperly 3. The game just won't launch if its pad data is being modified #3 is highly unlikely, and I don't see an error in my code, but to be sure, I'd have to disassemble it and compare the results to the original. To really troubleshoot this, I'd have to use my PC and a copy of the game...... I'll be able to use my PC next Saturday, but I'll have to rent the game.

Saturday is tomorrow . . . so . . . are you going to be able to rent SMB2 and possibly figure this out? :)

Did you have any luck figuring out what was wrong with SMB2 over the weekend? :)

No..... I couldn't rent it. I really have almost no time these days, and I probably won't be able to rent it soon. One thing you could do is make a separate enable code..... find out which set of pad data is "current", i.e., pause the game, unplug a controller, and advance frame by frame to see which one changes first. If they both change at the same time, then it might need an enable code similar to that of SSBM.

I just did a little more -*test*-('")ing. Apparently, even when PadSim isn't sending pad data, and no data is being sent to the Cube, when SMB2 is booted with a local player # of 2, the game doesn't boot. My recorder also shows no packets coming from the Cube. The only data that was sent to the Cube was the Ready command and the Start command.

That helps a bit.... it says to me that maybe pad data is stored in a different format. That could be a real pain later on..... but we'll see. Did you find out which on is "current"? If it turns out they're the same, set a BPX on the hook address and look for one of the two pad addresses in the register value list. If neither or both are there, it'll be kinda difficult. If just one is there, then you *should* be able to set a BPW on the other one and backtrace a bit to find a good hook location.

Ah..... damn..... well, SMB2 either uses a weird version of the SDK or has some kind of padread() hook. I'll have to examine it more in-depth when I can actually get the game. You might try asking Parasyte on gscentral.org; he might have the game and know what the deal is.