Mini Turbo Charge Meter [Vega]

[Vega]

Mini Turbo Charge Meter [Vega]

NOTE: Outdated by my version in main codes forum. The version in main forum works everywhere except Battle.

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.

NTSC-U
C2590F20 00000005
B36300C8 A1630100
2C0B0000 40820008
A16300FE 3D808053
3D6B38A0 916C10A0
60000000 00000000

PAL
C2597744 00000005
B36300C8 A1630100
2C0B0000 40820008
A16300FE 3D808053
3D6B38A0 916C5BE8
60000000 00000000

NTSC-J
C25970C4 00000005
B36300C8 A1630100
2C0B0000 40820008
A16300FE 3D808053
3D6B38A0 916C5568
60000000 00000000

NTSC-K
C258579C 00000005
B36300C8 A1630100
2C0B0000 40820008
A16300FE 3D808052
3D6B38A0 916C3C40
60000000 00000000

---

Source:
#Values per Region

.set region, '' #Must set region value, or else source will not compile

.if (region == 'E' || region == 'e') # RMCE
    .set _1sthalf, 0x8053
    .set _2ndhalf, 0x10A0
.elseif (region == 'P' || region == 'p') # RMCP
    .set _1sthalf, 0x8053
    .set _2ndhalf, 0x5BE8
.elseif (region == 'J' || region == 'j') # RMCJ
    .set _1sthalf, 0x8053
    .set _2ndhalf, 0x5568
.elseif (region == 'K' || region == 'k') # RMCK
    .set _1sthalf, 0x8052
    .set _2ndhalf, 0x3C40
.else # Invalid Region
    .abort
.endif

sth r27, 0x00C8 (r3) #Default Instruction

lhz r11, 0x0100 (r3) #Load Orange MT. If Zero, load Blue MT instead.
cmpwi r11, 0x0
bne- skip_blue

lhz r11, 0x00FE (r3) #Load Blue MT

skip_blue: #Replace Instruction, which contains MT value, at address of Millisecond Display Mod
lis r12, _1sthalf
addis r11, r11, 0x38A0 #Add 0x38A00000 to r11
stw r11, _2ndhalf (r12)

---

Code creator: Vega
Code credits: Bully (Millisecond Display Modifier Code creator); mdmwii (subroutine founder for Millisecond Display)

[TheCape]

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?

[SwareJonge]

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

[TheCape]

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.

[Vega]

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.

[TheCape]

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.

[Vega]

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).

[TheCape]

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.

[Vega]

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.

Edit 4/16/19

final revision on source