F6 exposed >.>

[Stuff]

I think it's time I put F6 to use, but before my wii explodes, I want to make sure I got this right. Here's a nice explanation from Deathwolf:

F600000Z XXXXYYYY
--------- ----------
D2/140000XX      TTTTTTTT
E0000000 80008000

Z = how many lines you need to find the hook address
XXXX =  example, search bwtween 8000
YYYY = and 817F
D2/14 = D2 for ASM and 14 for RAM writes.
TTTTTTTT = your new value

example:

F6000001 8000817F <-- 1 = search line, 8000817F = search between 8000 and 817F
7C018DC3 38B01305 <--- your search line (values)
14000030 60000000 <-- if values found, add 30 bytes to get to your hook address and write 60000000
E0000000 80008000

But be careful, the search lines (values) should be only once in the RAM.

So from this, I think F6 searches between 80000000 and 817F0000(using this example). Or does it search between ba+8000 and ba+817F? It has to be the first one.  So then it searches for exactly 7C018DC3 38B01305. Not some variation of that like 38B01305 7C018DC3. So then once it finds it, it sets the po to the address it found it in. The value in the first 8 bits would be 7C. But just the pointer. I can safely assume base address is still 80000000 if I haven't used a 42 code yet. And then the following code lines use the offsets I want to use like normal.

Hoping all that is correct, When searching can it find something like this:

........ ........ ........ 7C018DC3
38B01305....

And then how would I go about executing the F6 again? I could probably do 32000000 7C018DC3 in case it moved and follow that with some 04 or something. But I wouldn't know where the F6 is for me to 04 it cuz you can't assume it's gonna be in the same spot in the code space. Or maybe there's some simple solution for re executing F6. Expose F6 for me. >.<


Edit:
I found this http://wiird.l0nk.org/forum/index.php/topic,5135.0.html and created a F6in monster. The code itself, I can't really share, but I'll fill the values with some good ol XXs and YYs

F6000001 XXXXYYYY <-f6 stuff
ZZZZZZZZ WWWWWWWW <-more f6 stuff
3800001D 00000002 <-if something 1D from the hook
2A6593DC DDFF2200 <-then if not pressing R and L
14000365 40C00000 <-write something 365 from the hook
E0000000 00000000 <-just end all ifs
32000000 ZZZZZZZZ <-if the hook ever changes
4E00FFC0 00000000 <-load next code's address -20 into po
16000002 00000006 <-6 byte write overwriting 0031/0011 XXXXYYYY
00019XXXX YYYY0000 <-with 0001 XXXXYYYY (I assume F600 would never change)
E0000000 80008000 <-terminator

This F6in monster seems to re execute the F6 even if F6 returns false which is very nice since it'll be searching the range for the moving address until it finds it.

I guess I found the answer to my questions. Except, I still want to know if it can find
........ ........ ........ XXXXXXXX
YYYYYYYY....

[Bully@Wiiplaza]

F6000001 8000817F -> Search through mem 8000000 till 817F0000
7C018DC3 38B01305 -> check for those 2 followed values
14000030 60000000 -> if found, go 30 bytes forward and write value 60000000 to it (if you´d like to include a C2, replace 14 with D2)
E0000000 80008000 -> end of F6 code (terminator)

How it looks like, when you had written the same as C2 code (which is pointless in this case):

F6000001 8000817F -> Search through mem 8000000 till 817F0000
7C018DC3 38B01305 -> check for those 2 followed values
D2000030 00000001 -> if found, go 30 bytes forward and write C2 code
60000000 00000000 -> instructions
E0000000 80008000 -> end of F6 code (terminator)

[Deathwolf]

Correct me if I'm wrong but 8000 does not mean 80000000.

[Bully@Wiiplaza]

Correct me if I'm wrong but 8000 does not mean 80000000.

you´re right.
It actually means: 8000XXXX
I´m not sure about the XXXX value, but it´s AFTER the part where codes are stored in memory.
Otherwise the F6 code would always find itself and hook there -> fail

[Stuff]

hmm...but is this only for 8000? If not, we need to find out what XXXX is >.<.

[biolizard89]

hmm...but is this only for 8000? If not, we need to find out what XXXX is >.<.

It searches the whole range except for the 0x8000 range, which starts after the code handler.

[dcx2]

Actually, if you specify 8000 for XXXX, it will start at address 80003000


[spoiler]    xoris r24,r23,0x8000
    cmpwi r24,0
    bne- _notincodehandler
    ori r23,r23,0x3000
    _notincodehandler:
[/spoiler]

[biolizard89]

Actually, if you specify 8000 for XXXX, it will start at address 80003000


[spoiler]    xoris r24,r23,0x8000
    cmpwi r24,0
    bne- _notincodehandler
    ori r23,r23,0x3000
    _notincodehandler:
[/spoiler]

Yeah, I think that's what I said ("after the code handler")... although looking back at my post I see that I phrased it poorly.  Thanks for clarifying.

[dcx2]

Yeah, 80003000 is the end of the code handler, but I figured I could answer to Stuff's question on what precisely is the lower bound when 8000 = XXXX.

Also, you can safely use 8180 for YYYY.  It will search all the way up to the very last word possible, but no more.  So if your NN = 1, then it will search up to 817FFFF8.  If NN = 2, 817FFFF0.

EDIT:

[spoiler=Stuff said...]F6000001 XXXXYYYY <-f6 stuff
ZZZZZZZZ WWWWWWWW <-more f6 stuff
3800001D 00000002 <-if something 1D from the hook
2A6593DC DDFF2200 <-then if not pressing R and L
14000365 40C00000 <-write something 365 from the hook
E0000000 00000000 <-just end all ifs
32000000 ZZZZZZZZ <-if the hook ever changes
4E00FFC0 00000000 <-load next code's address -20 into po
16000002 00000006 <-6 byte write overwriting 0031/0011 XXXXYYYY
00019XXXX YYYY0000 <-with 0001 XXXXYYYY (I assume F600 would never change)
E0000000 80008000 <-terminator

This F6in monster seems to re execute the F6 even if F6 returns false which is very nice since it'll be searching the range for the moving address until it finds it.

I guess I found the answer to my questions. Except, I still want to know if it can find
........ ........ ........ XXXXXXXX
YYYYYYYY....[/spoiler]

I bolded a digit that you shouldn't have in there.  But yes, you seem to understand what's going to happen.

Also, F6 codes are if codes themselves.  When you used the terminator (without resetting po; smart!), you actually ended the F6's "if-ness" while preserving the PO that it found.  You could use the end-if code with V=2 to end just the 38 and 2A if's.

One thing you might not be expecting is that when the F6 fails, the po will be 80000000.  So your 38 if will actually be saying "[80000000] = ZZZZZZZZ?"  That's why it will keep searching when the F6 fails.

Instead of an "unaligned" 16 code, you should really consider just writing the whole line.  It doesn't take up extra code handler space and it's easier on the eyes.  See the modified code, below

This is actually a pretty awesome idea - not only will it search for something, but when it moves, it will *keep* searching for it until it finds it.  If it's not there when the game first starts, it will keep looking until it appears.  The only issue I might see is that if it disappears for long periods of time, then the constantly executing an F6 code could slow the Wii to a crawl.  So...use an if counter!

A8000000 FFC00001 # this is true once every 64 frames, or about 1 second @ 60 FPS

You can tune the 0xFFC0 value to various powers of 2 (FF80 = 128 frames, FF00 = 256 frames, FFE0 = 32 frames, etc) and control how often the F6 will "retry" to search.

Finally, I would move the 38 code up ahead of the F6 code.  The reason is that on the frame where the hook has changed from ZZZZZZZZ, your F6 code will still execute, potentially 14'ing something important.  However, moving the 38 code means that we might try to use XXXXYYYY as a pointer.  While 80008180 is actually a valid address, various values of XXXX could cause crashing.  That said, moving it forward is...non-trivial and might require using some new code types.


F6000001 XXXXYYYY <-f6 stuff
ZZZZZZZZ WWWWWWWW <-more f6 stuff
3800001D 00000002 <-if something 1D from the hook
2A6593DC DDFF2200 <-then if not pressing R and L
14000365 40C00000 <-write something 365 from the hook
E0000000 00000000 <-just end all ifs
32000000 ZZZZZZZZ <-if the hook ever changes
4E00FFC0 00000000 <-load next code's address -20 into po
A8000000 FFC00001 # this is true once every 64 frames, or about 1 second @ 60 FPS
16000000 00000008 <-8 byte write overwriting F6 line
F6000001 XXXXYYYY <- rewrite whole line
E0000000 80008000 <-terminator

Also, at the very end of your post, you have a question about XXXXXXXX and YYYYYYYY.  Are you asking if we can specify 32-bit starting and ending points, instead of just the upper 16 bits?

[Stuff]

oh that was a mistake. The actual code did work, but that 9 wasn't there. idk how that got there XD.

Well the code was meant to end the F6. It's not needed once it returns an answer unless it didn't hook to anything. The Z is unique in memory, afaik, for the code I was making. A few similar ones though. And the Z check needed to be independent from F6. I used E2 before trying to make a case switch, but then I learned about add 1 to the offset. I do 'E0-no reset' when it's time to end all ifs. But about E2, what happens when you make it end 0 ifs?

I do agree on that easier on the eyes thing. I just figured a lesser write would be better. But it does get awkward. I look at it like "wth was this?....oh it's the that thing."

Now your introducing A8. I tried using if counters before, but they didn't work like I thought they would. So a few new questions pop up.

A80ZZZZT MMMMXXXX. I expected this to run the code once at X as it counts I guess up to M and then count up from 0 again and run the code once more at X. Now, I wanted to do this to delay a 04 before because it would come in handy at some point. I didn't think about making Z=1, but the description says it resets to 0 when execution status is false. That kind of makes Z pointless since it would be false until the condition is met. Wasn't really much of a question.

So the counter goes up once per frame?(incoming "duh")

A8000000 FFC00001 # this is true once every 64 frames, or about 1 second @ 60 FPS

wut? It would count up to 3F(63 >.>) or something? I don't think I get what not(MMMM) means. Also wouldn't that be true immediately?

The counter if is a great addition to this F6in monster. I was thinking about what would happen if F6 can't find a hook.

Finally, I would move the 38 code up ahead of the F6 code.

You mean like:
38------ 00000002
F6000001 XXXXYYYY?

The address I'm if'ing has an offset of 1D from where ever Z is. It kind of needed to be after F6. I think this would be a quick fix to the last frame problem:

F6000001 XXXXYYYY <-f6 stuff
ZZZZZZZZ WWWWWWWW <-more f6 stuff
3800001D 00000002 <-if something 1D from the hook
30000000 ZZZZZZZZ<-then if the hook is still correct.
2A6593DC DDFF2200 <-then if not pressing R and L
14000365 40C00000 <-write something 365 from the hook
E0000000 00000000 <-just end all ifs
32000000 ZZZZZZZZ <-if the hook ever changes
4E00FFC0 00000000 <-load next code's address -20 into po
A8000000 FFC00001 # this is true once every 64 frames, or about 1 second @ 60 FPS
16000000 00000008 <-8 byte write overwriting F6 line
F6000001 XXXXYYYY <- rewrite whole line
E0000000 80008000

This would first check if hook+1D = 0002. In case for whatever reason the address moved and hook+1D just happens to have 0002 there, it'll check to make sure the address hasn't moved by reverifying the hook. I could probably put that check after the button activators instead. Probably unnecessary, but since 30 would be true as long as it's there, that line would usually execute the next line. Just a "improve performance" thing, since we were talking about F6 searching too much. So in that frame, if 30 isn't true, I'm hoping this will stop the next 14 from happening. I'm trying to keep the lines to a minimum as well.

Also, at the very end of your post, you have a question about XXXXXXXX and YYYYYYYY.  Are you asking if we can specify 32-bit starting and ending points, instead of just the upper 16 bits?

No, but that is interesting. Answer that too. >.<
My bad. That was a bad illustration. I meant for it to look like a 'copy all cells'.

             00010203 04050607 08090A0B 0C0D0E0F
8xxxxx10 00000000 00000000 00000000 XXXXXXXX
8xxxxx20 YYYYYYYY 00000000 00000000 00000000

Still not a 'copy all cells', but it looks better with that top row. Not sure when this would ever happen. Every time I checked, my Z was at 10-17. But yeah. Can it find XXXXXXXX at 0C and YYYYYYYY at 00 in the next row?

[dcx2]

The counter goes up once per execution of the code handler.  Typically, the code handler runs once per frame.  Sometimes different hooks might run the code handler more than once per frame.

Yes, A8000000 FFC00001 will run once immediately (X = 1).  This is desired, because as soon as you e.g. press a button you want something to happen.  Or as soon as the hook moves, you want to immediately re-search.  You don't want to wait e.g. 64 frames before activating.

M is used to mask off bits the interesting bits.  Bit masking is sortof common thing in programming, using the boolean operators & and | and ^.  In this case, it's saying "ignore the bits that are set".  When I say "bits that are set", I mean that you should see 0xFFC0 = 0b1111 1111 1100 0000.  All the bits where there are a 1 will be ignored, all the bits with a 0 will be compared.  So this will do a "6-bit" compare.  "sliding" the division between 1s and 0s will tune the repeat rate as a power of 2 frames per second.

If you're familiar with the remainder operator %, then you can sortof think of it as X % 64 = 1.  So, it would be true for 1, 65, 129, 193, 257, etc.  In other words, every 64 frames.  "every n frames" must be a power of 2, because of the way binary works.

The "periodic execution" where it runs once occasionally is a great way to minimize the cost of an F6.  You can also try to restrict the area of memory it searches to help it run faster.

Uh oh.  I just realized the extended code list and F6 codes won't get along very well.  lol

re: copy all cells, I see what you're asking.  In technical terms, you want to know if the F6 Z value must be double-word aligned (i.e. 8 bytes).  The answer is no, Z values may be word-aligned (i.e. 4 bytes) because F6 codes search in increments of words

It looks like you got the F6 code all figured out.  That is quite the fine code right there.

[Stuff]

The % explanation made much more sense than the "ignore bits" one. Many thanks. That is so awesome. Now I can mask everything XD.
I am gonna have to shrink the range for the F6. It found an undesirable position >.>. Still the same effect, but wasn't expecting it to work during a quest.

Uh oh.  I just realized the extended code list and F6 codes won't get along very well.  lol

lol yeah. F6 would find itself in the new code space. >.<

[fusionraptor]

[spoiler]

F6000001 XXXXYYYY <-f6 stuff
ZZZZZZZZ WWWWWWWW <-more f6 stuff
3800001D 00000002 <-if something 1D from the hook
2A6593DC DDFF2200 <-then if not pressing R and L
14000365 40C00000 <-write something 365 from the hook
E0000000 00000000 <-just end all ifs
32000000 ZZZZZZZZ <-if the hook ever changes
4E00FFC0 00000000 <-load next code's address -20 into po
A8000000 FFC00001 # this is true once every 64 frames, or about 1 second @ 60 FPS
16000000 00000008 <-8 byte write overwriting F6 line
F6000001 XXXXYYYY <- rewrite whole line
E0000000 80008000 <-terminator

[/spoiler]

I'm wondering if someone can help me with an F6 code that I am trying to get to reset itself when the hook changes, like the code above does. I think the only part of the code above that I do not understand is the 4E00FFC0 00000000 line. Where did the -20 come from? Is that the part that tells where to rewrite the F6 line? The code that I put together after reading this thread, I think, didn't reset it's F6 line when the hook changed. It just kept rewriting to the original hook every time the A8 line became true.. So I'm hoping someone can help me fix it.  :)

Here is my code:

Code Select Expand

F6000002 XXXXYYYY
ZZZZZZZZ WWWWWWWW
WWWWWWWW WWWWWWWW
16000010 00000020
VVVVVVVV VVVVVVVV
VVVVVVVV VVVVVVVV
VVVVVVVV VVVVVVVV
VVVVVVVV VVVVVVVV
E0000000 00000000
32000000 ZZZZZZZZ
4E00FFC0 00000000
A8000000 FFC00001
16000000 00000008
F6000002 XXXXYYYY
E0000000 80008000

[dcx2]

The comment about -20 into the po is wrong.  It's actually -0x40.

The 4E code type puts the address of a code into the po.  We use that to write to the F6 line so that it can be "reset".  A 4E code with no offset will put the address of the first word of the next code line into the po.  A 4E with -8 offset will put the address of the 4E itself into the po (since each code is 8 bytes).  -0x10 (-16 decimal) would put the address of the code line before the 4E, etc.

For your code, since the F6 is eleven lines back, you would want to subtract 0x58 (88 decimal).  So you would want FFA8 instead of FFC0

4E00FFA8 00000000

Also, your initial F6 code is wrong.  Why are you using F6000002?  It should be F6000001.  It's not a typo because you put 2 in both places.

[fusionraptor]

Ah, that makes perfect sense to me now. Thanks, dcx2! My code works perfect now as well, so thanks for that too. :)

It's F6000002 because there are 2 lines of values to search. I would've put all 4 of the words as ZZZZZZZZ, but the original poster used WWWWWWWW after the first word, so I thought I should as well.  ???

Thanks again for your response, dcx2.