(12-22-2021, 01:36 PM)Hackwiz Wrote: Does that mean I'm SOL in shortening the amount of writes with pin configurations that do not have the same written value?
Unfortunately, yes.
Also, you further explanation on adding 0x1000 makes perfect sense now.
Regarding the button-frame-too-quick issue. You can utilize ASM to incorporate 'button statuses'. You would need a spot to keep these statuses safe at.
So in your C2 ASM code, the source could be something like this...
Code:
#Get some registers, backup LR
mflr r12
stwu sp, -0x0050 (sp)
stmw r14, 0x8 (sp)
#Get button(s) pressed, check against desired activator
lhz r0, 0(r5) #Default Instruction
andi. r14, r0, 0xXXXX #Your desired button(s), need r0 intact so place result in r14
lis r14, 0x8000 #Before taking the branch, set r14 to its new value, upper 16 bits of EVA
bne- button_has_been_pressed
#Nothing Pressed, Reset Button Status
li r15, 0
stb r15, 0x3FF (r14)
b the_end
#Button Pressed, Adjust Button Status
#0 = Not Pressed
#1 = Pressed
button_has_been_pressed:
lbz r15, 0x3FF (r14)
cmpwi r15, 1
beq- the_end
li r15, 1
stb r15, 0x3FF (r14)
#Update Pin Config tracker
lbz r15, 0x03FE (r14)
addi r15, r15, 1
#Check if it exceeded max config allowed (only 3 configs allowed in this source currently - 0, 1, and 2)
cmplwi r15, 3 #Check if we went beyond 2
blt+ store_tracker
li r15, 0 #Reset tracker byte
store_tracker:
stb r15, 0x03FE (r14)The source keeps track of a button status at EVA 0x3FF (unused byte spot in Memory called the EVA btw) and a Pin Config Tracker (which pin config to use?) as a byte at EVA 0x3FE. That way if you hold the button activator after pressing it, it will NOT auto increment the Pin Config Tracker byte number. You will notice there's no landing spot for "the_end", that's because we still have more source left. Here's the rest of the source (rough draft), btw this is ALL hooked in that address you found (0x8001D30C) as a C2.
Code:
bl pin_config_table
#Config 1
.byte 00
.byte 00
.byte 00
.byte 00
.byte 00
.byte 00
.byte 01
.byte 00
.byte 00
.byte 01
#Config 2
.byte 01
.byte 00
.byte 01
.byte 00
.byte 01
.byte 00
.byte 01
.byte 00
.byte 01
.byte 00
#Config 3
.byte 01
.byte 01
.byte 01
.byte 01
.byte 01
.byte 01
.byte 01
.byte 01
.byte 01
.byte 01
.align 2 #Align the block of data
pin_config_table:
mflr r16
#Load Pin Config Tracker byte
lbz r17, 0x3FE (r14)
#Multiple Pin config by 0xA (10)
#0 x A = 0
#1 x A = A (10) #First button press uses this button config because of earlier "addi r15, r15, 1"
#2 x A = 14 (20)
#etc etc
mulli r17, r17, 0xA
#Use it as a indexed offset to load correct pin config from pin config table
#But first set the initial loop store address (0x81269C35 minus 0x57C = 0x812696B9)
#Each pin config byte address is equally separated by 0x57C
lis r18, 0x8126
ori r18, r18, 0x96B9
#Set first load address
add r16, r16, r17 #Points to correct pin config based on the index number recently calculated
subi r16, r16, 1
#Set loop amount (10 for 10 pins); we do not know about CTR safety on this hook so don't risk it
li r20, 10
#Update the pin config!
pin_write_loop:
lbzu r19, 0x1 (r16)
stbu r19, 0x57C (r18)
subic. r20, r20, 1
bne+ pin_write_loop
#The End
the_end:
#Pop stack, Recover LR
lmw r14, 0x8 (sp)
addi sp, sp, 0x0050
mtlr r12I'll try to explain the rest of the source. Basically we create a pin config lookup table. Atm, only 3 configs are setup (why the first source did a check against the value of 3 being reached on the pin config tracker byte).
The tracker byte is loaded and basically adjusted so it will point to the correct pin config on our lookup table. I noticed that each pin that you modify in mem81 has every addressed equally separated by 0x57C. That means we can easily make a loop for this.
A loop is made to transfer the pin config bytes from the lookup table to all the mem81 byte addresses. Finally I added the spot for the "the_end", the place for the CPU to go if the button activator was not 'just-pressed'. And had to add some instructions at the very end to pop the frame and recover the LR.
The way that source is setup atm, the first config that will be used will be config 2 in the lookup table.
I basically threw the kitchen sink at you on this one tbh
. There are slightly better ways to improve this source. Such as...- Not using a lookup table within the ASM code itself. Write it all out via 06 and 08 Gecko writes to yet another unused spot in the EVA
- Don't use any stack shit, look around the code instruction's address for more free registers instead
Here's the code compiled with some fill-in values
Code:
C201D30C 00000017
7D8802A6 9421FFB0
BDC10008 A0050000
700EXXXX 3DC08000 #XXXX = button acitvator, fyi it's left unfilled in the source I provided, fill it before compiling
40820010 39E00000
99EE03FF 48000084
89EE03FF 2C0F0001
41820078 39E00001
99EE03FF 89EE03FE
39EF0001 280F000Z #Z = pin configs; the source I provided would compile this as 3
41A00008 39E00000
99EE03FE 48000025
00000000 00000100 #All the pin stuff, to add more pin configs to the table, you must add them in the [u]source[/u], then recompile; keep the ".align 2" at the bottom
00010100 01000100
01000100 01010101
01010101 01010000
7E0802A6 8A2E03FE
1E31000A 3E408126
625296B9 7E108A14
3A10FFFF 3A80000A
8E700001 9E72057C
3694FFFF 4082FFF4
B9C10008 38210050
7D8803A6 00000000No idea if this will even work, probably not lol. I would step by step this before even running with it in the emulation 'normally'. I'm sure I messed up somewhere.
Some links that will explain all the elements of the source:
EVA: https://mariokartwii.com/showthread.php?tid=1106
Push/Pop Stack Method: https://mariokartwii.com/showthread.php?tid=873
Loops: https://mariokartwii.com/showthread.php?tid=975
"BL Trick" & Pseudo-Ops: https://mariokartwii.com/showthread.php?tid=977