Anyway, I went ahead and made two different Character Selection codes. I will discuss on "how" I made them. All I used was the character value list you have gave me earlier to speed up the initial memory search process. Nothing else.
My approach:
Repeat over and over til I had 3 Dynamic Memory results. Wrote them down
IMPORTANT NOTE: This game is odd, it has dynamic memory in mem80 with static memory (instructions) in mem81. This is reverse of games like MKWii.
I noticed that these 3 results also updated live (when hovering over to a new character before pressing A on him/her)
I set a Write BP on the 1st Dynamic Memory Result, got this address w/ corresponding instruction.
815B5234 : stb r5, 0x0498 (r3)
I removed the BP, and set a new Write BP on 2nd result, got this...
81603138 : stb r0, 0x00E8 (r17)
I removed that BP, and set a new Write BP on 3rd/final result, got this...
816035B4 : stw r0, 0x009C (r23)
I wanted to see which one would get triggered first out of all 3. The one that gets triggered first is usually the one that is suitable or best suitable for making the code. I cleared the recent 3rd Write BP, resumed emulation, and then set all 3 Write BPs at once. The one that gets triggered 1st out of the 3 was...
815B5234 : stb r5, 0x0498 (r3)
I then removed all 3 Write BPs, and set the above address as an Instruction BP. Instruction BPs are obviously for Instructions in Static Memory. I wanted to make sure this instruction would break for all 6 characters (3v3). It did. It would always break whenever I hovered over to a new character regardless of what current slot I was choosing it for.
So now I know this address & instruction effects P1 and all CPUs. I then made this basic code...
After a quick test on 3v3 Basketball, I confirmed this works. Now we need to move on to making this customizable for each slot/player..
Wii Games like to place character values of all players/CPUs nearby each other in memory, usually in a some sort of table format. So I decided to go back to the 1st Dynamic Address (out of the 3) I got from the initial memory search. While hovering over diff characters for different slots (P1, CPU1, CPU2, etc), I notice some patterns...
We can concatenate the halfword and 3 bytes and think of it as one whole "packet" that corresponds to each player/CPU.
After selecting and unselected multiple characters for each slot, I notice each player/CPU packet lies nearby each other in memory. They are all 0x28 (40 bytes) from each other. So for example let's say slot0 (P1) packet is at 0x80597000
Then slot1 (CPU1) packet is at 0x80597028
Then slot2 (CPU2) packet is at 0x80597050
etc etc
I noticed also that the in the game itself, it doesn't display the slot orders 100% true. For a 3v3 with one Human Player (P1), the slot orders for the characters on the TV screen, left to right are..
1 0 2 5 3 4
Not a big deal, just noting it.
The current hook address I didn't like because registers such as r11 weren't safe for use (which is very rare). So I needed to find a better hook address nearby.
The current hook address is within what is known as a Function.
When you get more advanced, you will learn about Function Calls -> https://mariokartwii.com/showthread.php?tid=1052
In a nutshell, my hook address was in a small small function, one without a prologue or epilogue. So its easy to know mostly what is going on in this function (form a higher level programming standpoint).
Anyway, if you scroll down a bit, the final instructions of the function are....
Address | Instruction
815b5268 | li r3, 0
815b526C | blr
Basically the function places a zero in r3 and uses the blr to return to its Parent function. It's telling the Parent funciton, "hey everything is good to go, keep doing what we need to do"
So anyway, this is a good hook address. At the end of functions (epilogues), registers r4 thru r12 are safe.
After some more analysis (GVR analysis) I have noticed r27 + 0x496 always points to slot0's packet. Remember that GVRs can hold constants that can be used as reliable address's to always point to a spot in dynamic memory regardless of what the actual value of the address is. It will be updated if the stuff in dynamic memory has been moved.
So I was able to make this.... (code only tested once in 3v3 basketball)
The code utilizes the BL Trick -> https://mariokartwii.com/showthread.php?tid=977
The BL Trick will create my own custom table of just the custom Character Bytes and transfer those into each Packet of the Game's Table in Dynamic Memory which is referenced via r27.
In conclusion, most of this info will just fly right over your head. But as your learn more and more, you can come back to this post for more help.
Assembly coding for cheats in games is not an exact science. You need some intuition and be able to investigate what you are "given".
If you are familiar with stock/forex/crypto trading, think of Wii Coding like Discretionary Trading with sometimes using small amounts of Technical Analysis. It is *not* 100% systematic.
EDIT:
I went ahead and made my own version of Instant SP Bar code and Freeze Timer code. I was unable to make a "Start Game with Full SP" or "SP Never Decrements" code.
Here are the two codes~
RMKE01 Instant Max SP Bar Gain [Vega]
X = Team
0 = Blue
1 = Red
NTSC-U
C218B460 00000003
2C04000X 40820008
FC210824 9421FFE0
60000000 00000000
#Hook Address
#NTSC-U = 8018B460
#Check for slot (r4 arg of func)
cmpwi r4, 0 #Set on Blue Team, adjust to 1 for Red
bne- original_instruction
#rtoc - 0x6474 constants the constant of 1.0
#However f1 is always non-zero, and fdiv is MUCH faster than lfs
#f1 = func 1st float arg, it is next bar level to increment up to
#Always make f1 = 1.0 (max SP bar)
fdiv f1, f1, f1
#OG instruction, make frame for function
original_instruction:
stwu sp, -0x0020 (sp)
============
RMKE01 Freeze Timer [Vega]
Press & hold button to freeze timer. Let go to allow timer to continue.
NTSC-U
0418A468 3C60804D
284CCF12 YYYYZZZZ
0418A468 4E800020
E0000000 80008000
"Source":
Instruction of "lis r3, 0x804D" at address 0x8018A468 is replaced with "blr".
This instruction is the start of a very small function that is called to updates/writes (decrement) the frame count (frames left in game) in dynamic memory. We can simply "cancel" the function with a "blr" at the very start. You could also instead place a nop on the parent function's corresponding "bl XXXXXXXX" instruction, but I'm not 100% sure if any other parent functions call this function. So to be safe, a blr inside the function itself was done.
My approach:
- Choose character (slot 0), do NOT choose next character
- Set value and do initial search
- Press B, reselect with diff/new character
- Change value on memory engine and do next scan
Repeat over and over til I had 3 Dynamic Memory results. Wrote them down
IMPORTANT NOTE: This game is odd, it has dynamic memory in mem80 with static memory (instructions) in mem81. This is reverse of games like MKWii.
I noticed that these 3 results also updated live (when hovering over to a new character before pressing A on him/her)
I set a Write BP on the 1st Dynamic Memory Result, got this address w/ corresponding instruction.
815B5234 : stb r5, 0x0498 (r3)
I removed the BP, and set a new Write BP on 2nd result, got this...
81603138 : stb r0, 0x00E8 (r17)
I removed that BP, and set a new Write BP on 3rd/final result, got this...
816035B4 : stw r0, 0x009C (r23)
I wanted to see which one would get triggered first out of all 3. The one that gets triggered first is usually the one that is suitable or best suitable for making the code. I cleared the recent 3rd Write BP, resumed emulation, and then set all 3 Write BPs at once. The one that gets triggered 1st out of the 3 was...
815B5234 : stb r5, 0x0498 (r3)
I then removed all 3 Write BPs, and set the above address as an Instruction BP. Instruction BPs are obviously for Instructions in Static Memory. I wanted to make sure this instruction would break for all 6 characters (3v3). It did. It would always break whenever I hovered over to a new character regardless of what current slot I was choosing it for.
So now I know this address & instruction effects P1 and all CPUs. I then made this basic code...
Code:
NTSC-U Force Character on All Slots [Vega]
C35B5234 00000002
38A000XX 98A30498
60000000 00000000
XX = Character to Force
li r5, 0xXX #Fill in XX value for Character
stb r5, 0x0498 (r3) #Original Instruction, write Char value to MemoryAfter a quick test on 3v3 Basketball, I confirmed this works. Now we need to move on to making this customizable for each slot/player..
Wii Games like to place character values of all players/CPUs nearby each other in memory, usually in a some sort of table format. So I decided to go back to the 1st Dynamic Address (out of the 3) I got from the initial memory search. While hovering over diff characters for different slots (P1, CPU1, CPU2, etc), I notice some patterns...
- Halfword immediately before the Character Byte represents some bit flags (values here is something like 0x8016, 0x8017, 0x8013, etc). So its obvious that the first bit in this halfword value always gets flipped high when the character HAS been selected. No idea what the other flags represent
- The byte immediately after the Character Byte is 0x00 for non-Mii and 0xFF for Mii
- The byte after that is... 0x00 = Not on this current slot/CPU for character selection, 0x01 = Using this slot at the moment, 0x02 = Character selected/chosen
We can concatenate the halfword and 3 bytes and think of it as one whole "packet" that corresponds to each player/CPU.
After selecting and unselected multiple characters for each slot, I notice each player/CPU packet lies nearby each other in memory. They are all 0x28 (40 bytes) from each other. So for example let's say slot0 (P1) packet is at 0x80597000
Then slot1 (CPU1) packet is at 0x80597028
Then slot2 (CPU2) packet is at 0x80597050
etc etc
I noticed also that the in the game itself, it doesn't display the slot orders 100% true. For a 3v3 with one Human Player (P1), the slot orders for the characters on the TV screen, left to right are..
1 0 2 5 3 4
Not a big deal, just noting it.
The current hook address I didn't like because registers such as r11 weren't safe for use (which is very rare). So I needed to find a better hook address nearby.
The current hook address is within what is known as a Function.
When you get more advanced, you will learn about Function Calls -> https://mariokartwii.com/showthread.php?tid=1052
In a nutshell, my hook address was in a small small function, one without a prologue or epilogue. So its easy to know mostly what is going on in this function (form a higher level programming standpoint).
Anyway, if you scroll down a bit, the final instructions of the function are....
Address | Instruction
815b5268 | li r3, 0
815b526C | blr
Basically the function places a zero in r3 and uses the blr to return to its Parent function. It's telling the Parent funciton, "hey everything is good to go, keep doing what we need to do"
So anyway, this is a good hook address. At the end of functions (epilogues), registers r4 thru r12 are safe.
After some more analysis (GVR analysis) I have noticed r27 + 0x496 always points to slot0's packet. Remember that GVRs can hold constants that can be used as reliable address's to always point to a spot in dynamic memory regardless of what the actual value of the address is. It will be updated if the stuff in dynamic memory has been moved.
So I was able to make this.... (code only tested once in 3v3 basketball)
Code:
NTSC-U Custom Character Selection [Vega]
C35B5268 00000008
7D8802A6 4800000D
RRTTVVXX YYZZ0000
7D6802A6 396BFFFF
38600006 395B0470
7C6903A6 8C0B0001
9C0A0028 4200FFF8
7D8803A6 38600000
60000000 00000000
RR = Character for Slot 0
TT = Character for Slot 1
VV = Character for Slot 2
XX = Character for Slot 3
YY = Character for Slot 4
ZZ = Character for Slot 5
#START ASSEMBLY 1st
#Hook Address's
#NTSC-U = 815b5268
#r3 safe for use if original instruction is last
#Backup LR
mflr r12
#Set Lookup Table
bl table
.byte 0x00 #Values plugged in so Source can compile
.byte 0x01
.byte 0x02
.byte 0x03
.byte 0x04
.byte 0x05
.align 2
table:
mflr r11
#Set Initial Load Address for BL Table
addi r11, r11, -1
#Set Loop Count for 6 character slots (slots 0 thru 5)
li r3, 6
#Set Initial Loop Store Address
#r27 + 0x496 = slot 0's character "packet"
#r27 + 0x498 = slot 0's character byte within packet
#So do... r27 + 0x470
#Each character byte will be 0x28 away from each other
addi r10, r27, 0x470
#Set CTR now
mtctr r3
#Transfer shit
loop:
lbzu r0, 0x1 (r11)
stbu r0, 0x28 (r10)
bdnz+ loop
#Restore LR
mtlr r12
#Original Instruction
#Tell parent function that this child function was a success (always success)
li r3, 0
#END ASSEMBLYThe code utilizes the BL Trick -> https://mariokartwii.com/showthread.php?tid=977
The BL Trick will create my own custom table of just the custom Character Bytes and transfer those into each Packet of the Game's Table in Dynamic Memory which is referenced via r27.
In conclusion, most of this info will just fly right over your head. But as your learn more and more, you can come back to this post for more help.
Assembly coding for cheats in games is not an exact science. You need some intuition and be able to investigate what you are "given".
If you are familiar with stock/forex/crypto trading, think of Wii Coding like Discretionary Trading with sometimes using small amounts of Technical Analysis. It is *not* 100% systematic.
EDIT:
I went ahead and made my own version of Instant SP Bar code and Freeze Timer code. I was unable to make a "Start Game with Full SP" or "SP Never Decrements" code.
Here are the two codes~
RMKE01 Instant Max SP Bar Gain [Vega]
X = Team
0 = Blue
1 = Red
NTSC-U
C218B460 00000003
2C04000X 40820008
FC210824 9421FFE0
60000000 00000000
#Hook Address
#NTSC-U = 8018B460
#Check for slot (r4 arg of func)
cmpwi r4, 0 #Set on Blue Team, adjust to 1 for Red
bne- original_instruction
#rtoc - 0x6474 constants the constant of 1.0
#However f1 is always non-zero, and fdiv is MUCH faster than lfs
#f1 = func 1st float arg, it is next bar level to increment up to
#Always make f1 = 1.0 (max SP bar)
fdiv f1, f1, f1
#OG instruction, make frame for function
original_instruction:
stwu sp, -0x0020 (sp)
============
RMKE01 Freeze Timer [Vega]
Press & hold button to freeze timer. Let go to allow timer to continue.
NTSC-U
0418A468 3C60804D
284CCF12 YYYYZZZZ
0418A468 4E800020
E0000000 80008000
"Source":
Instruction of "lis r3, 0x804D" at address 0x8018A468 is replaced with "blr".
This instruction is the start of a very small function that is called to updates/writes (decrement) the frame count (frames left in game) in dynamic memory. We can simply "cancel" the function with a "blr" at the very start. You could also instead place a nop on the parent function's corresponding "bl XXXXXXXX" instruction, but I'm not 100% sure if any other parent functions call this function. So to be safe, a blr inside the function itself was done.