Coding Questions and other Quandaries

[Hackwiz]

I came up with a workable button activated code:

2873ef10 00000040 #Activator Press & hold L for JMA
c2179fa0 00000001 #Insert asm at 0x80179fa0
60840000 00000000 #ASM ori r4, r4, 0
e0000000 00000000 #halfway terminator
2873ef10 00000000 #Activator No buttons pressed for normal jump
c2179fa0 00000001 #Insert asm at 0x80179fa0
60840001 00000000 #ASM ori r4, r4, 1
e0000000 80008000 #Full terminator

The key to why its locking up is because the ori r4, r4, 1 operation
is also used 4 times during the attack routine (only once for the jump).

That's enough for 2night.

Peace.

With some more work, I would think a non-button activated code would be possible.

[Vega]

Nice work so far. When you are replacing a single instruction with a new single instruction, you don't need an Insert ASM (C2) Codetype. You can use a Word (32-bit) RAM Write (04 codetype) instead.

Code:

2873ef10 00000040
04179fa0 60840000
e0000000 00000000
2873ef10 00000000
04179fa0 60840001
e0000000 80008000

Also you can change the activator to allow pressing other buttons. A simple hex equation of FFFF - ZZZZ = YYYY (which is FFBF for your code)

2873ef10 ffbf0040

Btw equipping a button value of 0000 is not suppose to be done. If you want a hold-button-activator-only type of effect, place the RAM write that has the default instruction at top, then your activate-able code below like this...

Code:

04179fa0 60840001 #Default state of code being 'de-acivated'
2873ef10 ffbf0040 #16-bit If statement for button activator; allow other buttons being pressed
04179fa0 60840000 #Code, word RAM write
e0000000 80008000 #Final terminator

Also since you're only replacing a bit within the instruction, you could do a Byte RAM Write instead. Makes no real difference at the end of the day.

Code:

00179fa3 00000001 #Byte RAM Write, notice the address change of +3
2873ef10 ffbf0040
00179fa3 00000000 #Code on
e0000000 80008000

[Hackwiz]

The last time I was farting around with the jump code for this game was about a year and a half ago.
I was just learning how to make a working button activator code lol.
So, now that I understand it better, when you shared this way to do it:

04179fa0 60840001 #Default state of code being 'de-acivated'
2873ef10 ffbf0040 #16-bit If statement for button activator; allow other buttons being pressed
04179fa0 60840000 #Code, word RAM write
e0000000 80008000 #Final terminator

I'm thinking, why didn't I think of that?

My takeaway?

There's more than one way to accomplish a goal.

&

Don't miss the forest for the trees.

Thanks!!!!!!!!!!!

[Hackwiz]

The key may be in the CTR. Last night when I was doing bp's on the ori r4, r4, 0x1 instruction,
I noted that the address in the CTR during the one break that occurs during the jump sequence is consistent...at least for the first stage.
Although I didn't make note if the values are consistent in CTR during the 4 breaks during the attack routine, I did notice they are drastically different from the value held in CTR during jump routine.

Going to go into the second stage tonight and see if this value is the same.

Maybe a simple mfctr -> andi -> cmpwi -> branch instruction will do the trick.

[Hackwiz]

Although I can't remember the exact address held in CTR (I think I'm close though):

Try: (Assuming CTR is 8009DD54, adjust accordingly)

C2179FA0 00000005 #Insert asm at 0x80179FA0
7C0902A6 7000000F #ASM mfctr r0; andi. r0, r0, 0xf
2C000004 4082000C#ASM cmpwi r0, 0x4; bne- default_instruction
60840000 38000000 #ASM ori r4, r4, 0x0; li r0, 0x0 (r0 was loaded with 0x0 at 0x80179F8C)
60840001 38000000 #ASM default_instruction: ori r4, r4, 0x1; li r0, 0x0
60000000 00000000 #Question: what is the technical name for this? I know what it's for.
E0000000 80008000 #Full terminator

I can try this out on the first stage, and with any luck, the CTR will have the same address in other stages.

[Vega]

Code:

mfctr r0
andi. r0, r0, 0xF
cmpwi r0, 4
bne- default_instruction
ori r4, r4, 0x0000
default_instrction:
ori r4, r4, 0x0001

The branching is wrong on this. Regardless of which branch route is taken, bit 31 of r4 will always end up high. Label names by themselves aren't 'barriers' in your source.

I would write it like this~

Code:

ori r4, r4, 0x0001 #Default Instruction, bit 31 is set high
mfctr r0 #Grab address from CTR
andi. r0, r0, 0xF #Check last digit
cmpwi r0, 4 #Check last digit against value of 4
bne- end_code #If not equal, end code, we want bit 31 kept high
rlwinm r4, r4, 0, 0, 30 #Flip bit 31 low
end_code: #The end

You can end a source with a label name destination for a branch if required.

Regarding your question on '600000000 00000000'~

It's a nop then the null word for the Code Handler to know to put a branch forward instruction to jump back where you left off. Nops will be added to your source by the compiler for compiled code alignment whenever necessary.

[Hackwiz]

Ok, I see what I did wrong here (duh!):

mfctr r0
andi. r0, r0, 0xF
cmpwi r0, 4
bne- default_instruction
ori r4, r4, 0x0000
default_instrction:
ori r4, r4, 0x0001

And understand what you did here:

ori r4, r4, 0x0001 #Default Instruction, bit 31 is set high
mfctr r0 #Grab address from CTR
andi. r0, r0, 0xF #Check last digit
cmpwi r0, 4 #Check last digit against value of 4
bne- end_code #If not equal, end code, we want bit 31 kept high
rlwinm r4, r4, 0, 0, 30 #Flip bit 31 low
end_code: #The end



Thanks for your critiques. I'm learning a lot from it.

I was just asking about the "rlwinm" instruction, and here, is a great example of how to use it.

[Vega]

You're welcome

[Hackwiz]

I'm curious.

You didn't say anything about the " li r0, 0x0 (r0 was loaded with 0x0 at 0x80179F8C) " line in my code.

I did that because I'm going to be loading an address (CTR) into r0 and wanted to "clean up" after using the register.

[Vega]

Didn't see that, lol.

I'm guessing you are doing it for Register Safety?

If that's the case, replace any usage of r0 with r11 or 12. Therefore you wont need the 'li r0, 0'.