Idea: the Cheat State Machine

kelvSYC · Post by **kelvSYC** » Thu May 17, 2007 8:04 pm

I know I've pushed for this idea before, but I'll push it again, having thought it out more thoroughly:

We should have a state machine implementation for the cheat engine, so that we can do more complicated things (such as data being stored encrypted, relative addresses with multiple pointer dereferencing, and so on).

The cheat state machine consists of 32 32-bit registers, called R0 to R31. No special meaning to any register has been bestowed upon them. Cheats exist independently in the sense that one activation of a cheat will not affect the activation of another cheat (or the same cheat) at some later point.

Because of the potential of invalid instructions or computations (say, divide-by-zero, branch offset errors, any cheat that takes the machine to an invalid state must be switched off and hidden as a safety measure.

Currently, the cheat engine has four 32-bit data fields, which I will call T, V1, V2, and V3 (the type, address, data, and extend fields). The cheat state machine implementation will have five: T, OP, V1, V2, and V3.

The T field
T is the metadata on the cheat:

Code: Select all

-00----- -------- -------- -------x one-shot
-1------ -------- -------- -------- legacy mode
-01----- -------- -------- -------- comment 
x------- -------- -------- -------- do not display

The legacy mode bit, when set, treats OP, V1, V2, and V3 as the four data fields for the current cheat engine. "Do not display" hides the cheat from the user interface.

For selection, we have the following:

Code: Select all

-00----- -------- -------- -----00- no select (ie. instruction)
-00--000 -------- -------- -----01- number select
-00--000 -------- -------- -----10- BCD number select
-00--000 -------- -------- -----11- enum select

"No Select" means that it's just instructions.
"Number Select" will prompt the user to select a number, which will be stored in R1. Similarly, "BCD Number Select" will do the same, but in BCD. Here, OP will contain the minimum and V1 the maximum to select.
"Enum Select" will select a value from an enumerated type (more on this later), and populates R1-R4 based on their selection. OP determines which enum declaration to use.

Code: Select all

-00--000 -------- -------- -------- no link
-00--001 -------- -------- -------- link with previous
-00---10 -------- -------- -----00- pre-enable
-00--1-0 -------- -------- -----00- activation key

If any part of a linked cheat has "one-shot", the cheat is one-shot. Similarly, if any part of a linked cheat has "do not display", the cheat is a "do not display".

"Pre-enable" and "activation key" sets the namesake for the cheat immediately after, for which the next line must be "no link". This is purely an end-user convenience. Note that you can pre-enable with activation key, but you cannot use it with a select (largely because I haven't sorted out the details of the behaviour). OP will contain the key if an activation key is used.

Code: Select all

1001-00- -------- -------- -----00- enum declaration

For list cheats, you declare list values independently of the cheat (to promote reuse). To declare this, you use the "enum declaration". OP, V1, V2, and V3 determine the values that are placed into R1-R4 upon their selection, and the name determines the name of the list value (the comment is ignored, so it's a good place to mark what enum it actually is...). The enum index starts at zero, and every new enum delcaration with a "no link" starts a new enum type (ie. use 0x90000000 for a new enum, and 0x91000000 to use add to the current enum).

Note that enum declarations can only be linked to each other.

The OP field for instructions
An instruction is one with "no select". The OP field determines the instruction to execute.

Code: Select all

-------- -------- -------- xxxxxxxx V3 operand type
-------- -------- xxxxxxxx -------- V2 operand type
-------- xxxxxxxx -------- -------- V1 operand type
xxxxxxxx -------- -------- -------- instruction type

In a field operand type, we have the following:

Code: Select all

000xxxxx value at standard memory address
   xxxxx CPU index
001xxxxx value at memory region
   xxxxx region index
010xxxxx value at write handler mapped memory
   xxxxx CPU index
01100000 value at direct program space
110xxxxx value at register
   xxxxx register index
11100000 constant

the field is ignored if "value at register" is chosen.

For the instruction type, we have

Code: Select all

-00xxxxx load/store operations
   -x--- swapped
   --x-- 0 to load, 1 to store
   ---xx number of bytes
-01xxxxx arithmetic and bitwise operations
   x---- 0 for unsigned, 1 for signed
   -0000 add
   -0001 subtract
   -0010 multiply
   -0011 divide
   -10x- 0 for shift, 1 for rotate
   -10-x 0 for left, 1 for right
   -1100 bitwise and
   -1101 bitwise or
   -1110 bitwise not
   -1111 bitwise xor
-10xxxxx branching operations
   x---- 0 for unsigned, 1 for signed
   ----x branch on equal
   ---x- branch on greater
   --x-- branch on less

V3 is ignored in load/store operations.
"writing to constant" is not permitted, so V2 can't be set to "constant" in load/store, nor V3 in arithmetic/bitwise.

In branching instructions, V1 and V2 are the two data values to compare, and V3 is the number of instructions to skip (taken as a signed integer) if the comparison fails. To terminate a cheat on branch failure, use 0x00000000 (the rationale: if the comparison succeeds, no lines are skipped...). So this means "branch never" can be used as a terminate or unconditional jump. (V1 and V2 is ignored in a "branch never", while V3 is also ignored in "branch always").

Note that this is incomplete at the moment, and I'd love to hear any feedback (note that I'm still mostly on the design stage, so any real C implementation is still far off), especially on how to do watches, delays, and other such stuff that are missing and probably a good addition.