Mini Turbo Charge Meter
#1
Mini Turbo Charge Meter 

Works in TT mode, and in any VS type Online Racing. When in TT mode, only do Solo Racing. Does NOT work in Grand Prix, Offline VS, or any type of Battle.

This code will read the output value of your MT charge (including Orange MT for Karts) on the millisecond section of your timer. Works for all vehicles.

For Bike Usage: A reading of '270' indicates MT is fully charged ready for boost.
For Kart Usage: Once the first/initial reading reaches 270 (blue MT is fully charged), the milliseconds recycle. Then a reading of '300' indicates the Orange MT is fully charged ready for boost.

NOTE: This code makes use of memory addresses 0x80001650 thru 0x80001653. Make sure no other codes in your GCT/Cheat-Manager are using those addresses.

NTSC-U
C25310A0 00000004
3D808000 818C1650
A0AC0100 2C050000
40820008 A0AC00FE
60000000 00000000
C2590F20 00000002
B36300C8 3D808000
906C1650 00000000

PAL
C2535BE8 00000004
3D808000 818C1650
A0AC0100 2C050000
40820008 A0AC00FE
60000000 00000000
C2597744 00000002
B36300C8 3D808000
906C1650 00000000

NTSC-J
C2535568 00000004
3D808000 818C1650
A0AC0100 2C050000
40820008 A0AC00FE
60000000 00000000
C25970C4 00000002
B36300C8 3D808000
906C1650 00000000

NTSC-K
C2523C40 00000004
3D808000 818C1650
A0AC0100 2C050000
40820008 A0AC00FE
60000000 00000000
C258579C 00000002
B36300C8 3D808000
906C1650 00000000



List of Sources:

(First ASM; Millisecond Modifier)
.set _mtc , 0xFE #MT Charge
.set _omtc, 0x100 #Kart Only Orange MT Charge
.set _mtb, 0x102 #Boost from MT Release
.set _ssmtb, 0x10C #Boost from both Stand Still Charge & MT's
.set _mushb, 0x110 #Mushroom Boost
.set _trikb, 0x114 #Trick Boost
.set _ssc, 0x14C #Stand Still Charge
.set _air, 0x21A #Air Time

lis r12, 0x8000 #Set first half address of r12 to 0x8000 to load dynamic memory address location
lwz r12, 0x1650 (r12) #Load the pointer from 0x80001650
lhz r5, _omtc (r12) #Load the current Orange MT charge value into r11

cmpwi r5, 0x0 #Compare value of Orange MT charge value to 0x0
bne- skip_blue #If not equal to 0x0, we need to display the Orange MT charge, NOT the blue MT. This branch is LESS likely to occur, hence the minus symbol

lhz r5, _mtc (r12) #If equal to 0x0, we need to display the Blue MT charge, NOT the Orange MT. Load Blue MT value into r11

skip_blue: #Label placed purely for branch offset auto-calculation by compiler

==========================================================

(Second ASM; Store Pointer to Crash Handler)
sth r27, 0x00C8 (r3) #Default Instruction
lis r12, 0x8000 #Set 1st half address to store the dynamic mem location word to
stw r3, 0x1650 (r12) #Store the Default Instruction's Pointer to 0x80001650



Code creator: zak
Code credits: mdmwii (address founder for first ASM)
Reply
#2
Trying to dig up where the variable this modifies is located. Do we know if there is one for Blue and one for Orange sparks? Or one for Karts and one for Bikes?
Reply
#3
(01-18-2019, 04:33 AM)TheCape Wrote: Trying to dig up where the variable this modifies is located. Do we know if there is one for Blue and one for Orange sparks? Or one for Karts and one for Bikes?

You need to add a few extra lines to the code

addi r12, r3, 0x101 # add 0x101 to the address of r13 and store the result in r 12
stw r12, 0x1650 (r11)
then it should output the Orange MT Charge as well
Reply
#4
(01-18-2019, 01:24 PM)SwareJonge Wrote:
(01-18-2019, 04:33 AM)TheCape Wrote: Trying to dig up where the variable this modifies is located. Do we know if there is one for Blue and one for Orange sparks? Or one for Karts and one for Bikes?

You need to add a few extra lines to the code

addi r12, r3, 0x101 # add 0x101 to the address of r13 and store the result in r 12
stw r12, 0x1650 (r11)
then it should output the Orange MT Charge as well

I plan to be learning more about ASM to figure this stuff out, but the main idea is to be able to edit Kart blue and orange independently of in place MT and bike MT if possible.
Reply
#5
That source might not work Jonge, I cba to test.

@TheCape

The 'variables' reside in dynamic memory, meaning they are not at the same address per race. Hence why an ASM was created utilizing an address (ASM function) that the value in r3 is always nearby the variables when the function is called.
Reply
#6
(01-18-2019, 08:47 PM)zak Wrote: That source might not work Jonge, I cba to test.

@TheCape

The 'variables' reside in dynamic memory, meaning they are not at the same address per race. Hence why an ASM was created utilizing an address (ASM function) that the value in r3 is always nearby the variables when the function is called.

Makes sense, will need to create a new ASM code to adjust this then. Are you aware if it's possible to differentiate the blue and orange Mts, or the blue Mts between Karts and Bikes?

Might be best to just adjust the amount required for the orange MT. Is it also a 270 value or is it out of 540?

Edit: I think the reason I thought it was a specific variable is because it may be coded that the current is X and the max is 270. So X will constantly update, but the 270 doesn't change.
Reply
#7
Went ahead and upgraded the code to include Orange MT reading for karts. Even though you are new to ASM, please read the source. You may have somewhat of an understanding of how I made the code work.

For a visual perspective... view the following image...
https://i.ibb.co/Yc5WsCx/meterdynamic.png

Dolphin was running when I took the screenshot, hence why the Code View is disabled. Anyway, address 0x80E495A2 holds the halfword value for Blue MT. Address 0x80E495A4 holds the halfword value for Orange MT. Also, address 0x80E495A1 holds a byte indicator (which I didn't need to use at all for the code, this is just a little fyi if you ever need it) which shows 0 for no charging of an MT, 1 for charging blue MT, 2 for blue MT charge full/charging orange MT, and 3 for orange MT charge full.

If at that moment of the screenshot, I set an instruction breakpoint (NTSC-U) for static function address 0x80590F20 (address of second ASM), Register 3 would hold the value of 0x80E494A4. If you add 0xFE to that address, you get 0x80E495A2 (location of blue MT). Hopefully that will help you understand the source for the second ASM, of why I added 0xFE to r3.

Ofc, these MT value locations/addresses are all dynamic (as I mentioned earlier). The very next race, all the MT values will be at a different spot (still high mem80 though).
Reply
#8
(01-19-2019, 03:17 AM)zak Wrote: Went ahead and upgraded the code to include Orange MT reading for karts. Even though you are new to ASM, please read the source. You may have somewhat of an understanding of how I made the code work.

For a visual perspective... view the following image...
https://i.ibb.co/Yc5WsCx/meterdynamic.png

Dolphin was running when I took the screenshot, hence why the Code View is disabled. Anyway, address 0x80E495A2 holds the halfword value for Blue MT. Address 0x80E495A4 holds the halfword value for Orange MT. Also, address 0x80E495A1 holds a byte indicator (which I didn't need to use at all for the code, this is just a little fyi if you ever need it) which shows 0 for no charging of an MT, 1 for charging blue MT, 2 for blue MT charge full/charging orange MT, and 3 for orange MT charge full.

If at that moment of the screenshot, I set an instruction breakpoint (NTSC-U) for static function address 0x80590F20 (address of second ASM), Register 3 would hold the value of 0x80E494A4. If you add 0xFE to that address, you get 0x80E495A2 (location of blue MT). Hopefully that will help you understand the source for the second ASM, of why I added 0xFE to r3.

Ofc, these MT value locations/addresses are all dynamic (as I mentioned earlier). The very next race, all the MT values will be at a different spot (still high mem80 though).

I was actually playing around with the code on multiple occasions and working on learning how this works, but the dynamic nature of the values makes this difficult.

It seems to me that the 270 value for a blue MT and the 300 value for an orange MT should have hard coded values. The amount it currently has of that 270 or 300 I can see changing, but it's top limit I feel should have a hardcoded amount somewhere. Essentially changing 270 to 150 would make anytime you hit 150 with the drift it would generate the blue MT.
Reply
#9
(01-22-2019, 03:46 AM)TheCape Wrote:
(01-19-2019, 03:17 AM)zak Wrote: Went ahead and upgraded the code to include Orange MT reading for karts. Even though you are new to ASM, please read the source. You may have somewhat of an understanding of how I made the code work.

For a visual perspective... view the following image...
https://i.ibb.co/Yc5WsCx/meterdynamic.png

Dolphin was running when I took the screenshot, hence why the Code View is disabled. Anyway, address 0x80E495A2 holds the halfword value for Blue MT. Address 0x80E495A4 holds the halfword value for Orange MT. Also, address 0x80E495A1 holds a byte indicator (which I didn't need to use at all for the code, this is just a little fyi if you ever need it) which shows 0 for no charging of an MT, 1 for charging blue MT, 2 for blue MT charge full/charging orange MT, and 3 for orange MT charge full.

If at that moment of the screenshot, I set an instruction breakpoint (NTSC-U) for static function address 0x80590F20 (address of second ASM), Register 3 would hold the value of 0x80E494A4. If you add 0xFE to that address, you get 0x80E495A2 (location of blue MT). Hopefully that will help you understand the source for the second ASM, of why I added 0xFE to r3.

Ofc, these MT value locations/addresses are all dynamic (as I mentioned earlier). The very next race, all the MT values will be at a different spot (still high mem80 though).

I was actually playing around with the code on multiple occasions and working on learning how this works, but the dynamic nature of the values makes this difficult.

It seems to me that the 270 value for a blue MT and the 300 value for an orange MT should have hard coded values. The amount it currently has of that 270 or 300 I can see changing, but it's top limit I feel should have a hardcoded amount somewhere. Essentially changing 270 to 150 would make anytime you hit 150 with the drift it would generate the blue MT.

There is no hardcoded set limit that this code/function is reading from (like a number simply listed somewhere in RAM) as a means to set a maximum. The functions (list of addresses in subroutines responsible for writing/reading the increase/decrease of MT) is hardcoded. These functions have some sort of equation done to prevent a number higher than 270 for blue MT and a number higher than 300 for orange MT.

To manipulate this responsible equation would be tricky. It would probably be a code of multiple semi-complex ASMs. Definitely something I have no desire to solve. There's probably an easier way, but it's late right now lol.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)