F2 Codetype

[Deathwolf]

CST1/2 : ASM Insert With 16-bit XOR Checksum

F2XXXXXX YYZZZZNN
ZZZZZZZZ ZZZZZZZZ
ZZZZZZZZ ZZZZZZZZ
ZZZZZZZZ 00000000
YY (signed) 16-bit values after (if positive) or before (if negative) [ba + XXXXXX] will be XOR'ed together and the result will be compared to ZZZZ. If equal, the code will be executed. The rest of the code functions the exact same way as the C2 code type (Insert ASM code in the game), with NN as the number of lines.


I've aboslutely no clue what it means. I read brkirchs tut about the F4 code type but that doesn't help at all D: What do I need to "XOR" the values?

An example would be really helpfull.

Thanks!

[goemon_guy]

I've never used it before, but how I interpret it, is like so:

e.g.
F20EC868 06906303
ZZZZZZZZ ZZZZZZZZ
ZZZZZZZZ ZZZZZZZZ
ZZZZZZZZ 00000000

The code will look 6 16-bit values after 800EC868.
The code will then compare the result at the new address that it found. (16-bits after 800EC868.)
In the example I came up with, I believe it would compare to 9063. If equal, the rest of the ASM would be executed.
(You know how a C2 code works.)

However, I could be wrong.

[Bully@Wiiplaza]

http://wiird.l0nk.org/forum/index.php/topic,8773.0.html

*cough* same topic, but nobody replied there.
I didn´t understand the XOR checksum part :-[
which values you pick etc.
Best would be a real example code with reference to a game.

[goemon_guy]

http://wiird.l0nk.org/forum/index.php/topic,8773.0.html

*cough* same topic, but nobody replied there.
I didn´t understand the XOR checksum part :-[
which values you pick etc.
Best would be a real example code with reference to a game.

I would have answered your topic, had I seen it! But I was away last week when it was posted, so...

Here's a code made by dcx2, for Tales of Symphonia

can learn S/T techs without forgetting opposites v1.1 [dcx2]
F322840C 90337B01
38600000 00000000
F322845C 70F70301
38600000 00000000

(I'll be looking at the bolded part.)

If what I explained was right, then it would look 0x90 16-bit values after 8022840C and compare it to 9033. (I believe that you'd pick the first 16-bit value of the ASM instruction you wish to replace.)

e.g.
stw r0,12(r3)  =  9003000C
9003 would be your "ZZZZ"

F2XXXXXX YY9003NN
ZZZZZZZZ ZZZZZZZZ
ZZZZZZZZ ZZZZZZZZ
ZZZZZZZZ 00000000

I'm not actually sure how to find the YY values, though now that I look at it... In the example I provided above, (dcx2's code) he used 0x90. I'm not sure where that came  from...

[Bully@Wiiplaza]

Thought the ZZZZ part was normal (C2) assembly?
His is pretty weird. :(

[spoiler]li r3,0
.word 0x00000000
psq_st f25,1116(r2),1,0
andi. r23,r7,769[/spoiler]

F3 obviously stays for mem81.

[Deathwolf]

Mhm okay but what's the difference between F6 and F4/F3/F2? Yup F6 is a search codetype but why would you use an F2 codetype which XORs the values? :confused: Or mabye "what's the special thing"?

BTW Thanks goemon_guy for your help  :)

[goemon_guy]

No problem, Deathwolf!

F2,F3 and F4 all check the ASM you are replacing before they do replace it. (Used for when the game swaps ASM in and out during gameplay.)
So you don't replace something you shouldn't.

It's kinda like putting a 20XXXXXX YYYYYYYY before an ASM code.

F6 is when the ASM changes places every so often during gameplay.


@Bully@Wiiplaza

li r3,0
.word 0x0000
psq_st f25,1116(r2),1,0
andi. r23,r7,769
li r3,0

^You got that by inserting the code into PyiiASMh, right?

You didn't notice that there are two ASM hooks in the code. (Or I failed to point it out myself... XD)

[spoiler]F322840C 90337B01
38600000 00000000
F322845C 70F70301
38600000 00000000

=

F322840C 90337B01
38600000 00000000

F322845C 70F70301
38600000 00000000[/spoiler]

[dcx2]

If what I explained was right, then it would look 0x90 16-bit values after 8022840C and compare it to 9033.

There are two things wrong with this.

1) YY is signed.  0x90 = 0b10010000 = -0x70
2) This is an XOR hash, so it is the "sum" of many different values.  Specifically all values between the hook (exclusive) and (hook+YY) (inclusive) will be XOR'ed together.  Meaning in this case there are 0x6F XOR computations using the consecutive 16-bit values from 8122839A to 8122840A

I wanted to XOR hash many values together, because the code overlay I was hooking appeared to be loaded in pieces, and was not always cleared from memory.

[goemon_guy]

1) YY is signed.  0x90 = 0b10010000 = -0x70

First off, *doh!*
I forgot to take that into account, then!

2) This is an XOR hash, so it is the "sum" of many different values.  Specifically all values between the hook (exclusive) and (hook+YY) (inclusive) will be XOR'ed together.  Meaning in this case there are 0x6F XOR computations using the consecutive 16-bit values from 8122839A to 8122840A

I wanted to XOR hash many values together, because the code overlay I was hooking appeared to be loaded in pieces, and was not always cleared from memory.

I think I was slightly confused on the topic of XOR before that, then.

Thanks for clearing that up!