Self-modifying codes with CT2-CST7 0x4E code type

[dcx2]

I would like to share with you a code which modifies itself.  I will be using the 0x4E code type.  It is mis-labeled in the code-types document as doing something with grN, but the text itself is correct.  This code type puts the address of the next code into the po.  After that, we can use a code to modify our codes while the game is running.

My example will be a Tales of Symphonia code that allows you to spellbind monsters.  You only get to spellbind one monster per fight, though, and if you spellbind more than one, the actual monster will be one of them at random.  So an "always spellbind" code would backfire by making it harder to bind the monster you actually want.  What we really want is a way to turn spellbind on and off.

We could use a switch code.  I have posted previously about using a switch to make a code toggle-able.  The problem with making spellbind into a toggle code is that there is no way to know what state the switch is in, so you have to remember what state it was in all the time or you could mess it up.  What we need is one button combination to turn it on and one combination to turn it off.  In my case, I'm going to use + and up to turn it on, + and down to turn it off.  I chose + because that brings up the menu so that game play stops, while up and down correspond nicely with on and off.

How do we do this?  The pattern goes like this.  First, write the "anticode" (or original instruction).  Then, we get the address of the code part we want to change.  Next, if the first button activator, patch with the code.  Else if the second button activator, patch the anti-code.  Finally, end if.  When neither button activator is true, the first line will depend on the last successful button activator.

040B1000 38600000   # writes anti-code; li r3,0 (return false; never spellbind) to 0x800B1000
4E00FFF4 00000000   # load address of second 32-bits (3860000x) into po (0xFFF4 = -12 back from the start of next code)
284D755A 00000018   # if + and up are pressed (0x18)
14000000 38600001   # over-write second 32-bits of first line; li r3,1 (return true; always spellbind)
284D755B 00000014   # else if + and down (0x14)
14000000 38600000   # over-write second 32-bits of first line; li r3,0 (return false; never spellbind)
E0000000 80008000   # end if, and fix po

[Panda On Smack]

Thanks for explaining various methods and how to do certain things, I enjoy your posts

[dcx2]

I was considering this last night, and this code could be simpler.  It's still a nice demonstration for a self-modifying code, but this is a simpler version.

284D755A 00000018   # if + and up are pressed (0x18)
040B1000 38600001   # li r3,1 (return true; always spellbind)
284D755B 00000014   # else if + and down (0x14)
040B1000 38600000   # li r3,0 (return false; never spellbind)
E0000000 80008000   # end if

If no buttons are being pressed, no changes would be made to 0x800B1000.  If the right activators are pressed it will change the instruction.

I'm sure someone will find a use for self-modifying code sooner or later...

[dcx2]

nono, the last wasn't self-modifying; it doesn't over-write the code itself in memory.  The first code was self-modifying.  That is, there was exactly one line of code that did the patching - the first line.

040B1000 38600000   # The *only* code that writes to the game's memory  <-------------
                                                                                                                          |
The rest of the code  |  is just belly-rubbing and head-patting that's needed to modify that | line of code.
                             v
4E00FFF4 00000000   # Get address of "The *only* code"
284D755A 00000018   # if
14000000 38600001   # Modify "The *only* code" to li r3,1
284D755B 00000014   # else if
14000000 38600000   # Modify "The *only* code" to li r3,0
E0000000 80008000   # end if, and fix po

The code handler reads the codes from memory and executes them.  A self-modifying code writes to the code handler's memory, so that it does something different the next time that code is executed.  This is in contrast to the code itself, which is writing to the game's memory using ba + 0xb10000.  The address of the code in the code handler is then copied into the po by the 0x4E code, and finally the code modifiers can over-write the code with po + 0x000000.

We must use the ba and po in this way.  If we put the address of the code in the ba instead, the important address bits would get masked when we try to write with 0x40 0x04 0x14-code-type to the code handler's memory.

----

In contrast, this code is NOT self-modifying.  It has two separate lines that write to the game's memory and zero lines that write to the code handler's memory.

284D755A 00000018   # if
040B1000 38600001   # write li r3,1 to game's memory
284D755B 00000014   # else if
040B1000 38600000   # write li r3,0 to game's memory
E0000000 80008000   # end if

The two codes I posted behave identically.  They're like a light switch - press it up to turn it on and down to turn it off.  If it's up and you turn it up again, it doesn't turn off, so it's an unambiguous way to set the state.  Up is always on.  If the power goes out, and you flip the switch several times, you will still know for sure whether it will be on or off when the power comes back.

A switch code with 0xCC code type will be like a lamp with a cord that you pull.  Pull the cord once and it turns on, pull again and it turns off.  The behavior is ambiguous - it depends on what it was before.  If the power goes out and I pull it a few times, you might not know whether it will be on or off when the power comes back.

The power going out in my analogy means that you don't have an indicator on the screen as to the state of the code.  There's no blinking or color changing or anything, unless you write another code that does that too.  So the power is perpetually out, but the lights still work.