Idea: "Register Machine" to increase Cheat Engine

[kelvSYC]

Just a thought on how to use the remaining undesignated space in the 32-bit cheat specification (that would be the A0000000-E0000000 area, I think).

It came across as I was looking for Game Boy Advance cheats. Right now, no GBA emulator that I know of has a powerful enough cheat engine to do relative addressing (GSA and CBA do only a zero-offset RA, which isn't really useful). As an example, the 3G Pok?mon games extensively use RA to store crucial game data (to deter aspiring Gamesharkers), so much that there are a LOT of kludges in terms of GSA and CBA codes to rig the random number generator or otherwise work around the RA mechanism (and for the most part, they unnecessarily corrupt data and requires very specific working conditions).

One thing in the 3G Pok?mon games is that the item pocket is a series of RA cheats (for example, in Emerald the item pocket starts at [03005D90] + 150C), in which the item is a straightforward RA and the quantity is xor-encrypted, with the encryption key stored in another RA (I'm not sure if it's [03005D90] + AC or [[03005D90] + AC]).

Obviously, this kind of thing is simply too much for the GBA emulator's cheat engine (or for GSA and CBA). It's even too much for the MAME cheat engine if a MAME game had some data stored in this manner.

My idea is admittedly taken from CheatScript, but in a much more simpler way. For those of you who don't know, CheatScript is an idea to bring a VM for complex cheats, including UI details and stuff. From that I borrow the idea of having 32 32-bit registers, and using cheat types themselves as operators on those registers (the fact that a cheat has three data fields also proves convienient...).

As we know, a multipart cheat executes its parts in the order the parts are listed. If we add cheat types for the register operations, we effectively create a simple register machine. With a register machine, we could make very complex nonbranching cheats in this manner (branching is considerably more difficult, and perhaps is why we might still need CheatScript, or at least have the ability to activate a cheat from another cheat). Cheats requiring double-indirection, or indirect offsets and indirect base addresses (both of which have been found in MAME games but were unable to implement elegantly, IIRC) would become very trivial with proper usage of load and store instructions. We can easily deal with encrypted values, and perhaps with a little bit of greasemonkeying around, we can finally build enumerations (in the sense that selecting a value from an enumeration will automatically write values into some registers) so that we can finally get multipart list cheats (a good way to shrink the appearance of the ddsom cheat list in the UI...).

This might seem overly ambitious (and/or even redundant), but what do you think of this idea?

[Pugsy]

I don't really understand what you mean (sounds far too complicated), XOR value of one RA location linked to a RA address of another cheat sounds like a nightmare to find - you'd have to go through the code to find it and in which case it would probably be a lot easier just to create a ROM cheat for it instead. If I'm reading this wrong (which I probably am) could you give me a worked example of a theoretical cheat?

And the ddsom cheats have been downsized for the next cheat file, though obviously the multi-part cheats can't be converted into list cheats easily (though in that instant one part of the cheat is identical for all the items so we could therotically have a single non-linked cheat that the user would have to activate in addition to the select cheat.)

[kelvSYC]

The problem with a ROM cheat is that
1. you have to know something about the CPU architecture of the emulated machine (ie. processor assembly language)
2. you are effectively diverting CPU resources away from the game, which might throw the game out of sync if timing is important

The knowledgeable does not have to concern themselves with the first, and the excellently designed ROM cheat takes care of the second. For the rest of us, it might be better if we sacrifice a bit of emulation speed for that desired cheat behavior.

Actually, after looking it up again, I was mistaken a lot - the code for the above example in Pok?mon Emerald is that the type of the first item is at [03005D90] + 130C, and the quantity for the first item is stored at [03005D90] + 150E, but it is XOR-encrypted. To correctly store the value, you'd have to take the desired value and XOR it with the key, which is (a two-byte value) at [03005D90 + AC].

One could perhaps envision holding [03005D90 + AC] at zero and then writing clear into [03005D90] + 150E, but currently no GBA emulator cheat engine can do such a thing (the GBA community would rather have a cheat that disables the RA mechanism altogether, and build off of that). We could do this with the MAME cheat engine, but then it would not be elegant (any cheat that depends on another cheat being on isn't too elegant in my book).

Regardless, the point is that the register machine can make the cheat engine even more powerful by introducing some form of semipersistent (really, cheat-by-cheat and invocation-by-invocation) state. It can also get us into more semantic-oriented cheat finding and cheat writing (prefills are redundant with a register machine, for example).

[ianpatt]

Sorry for the delay on these posts, couldn't get to anything hosted at ZTNet over the weekend.

It's an interesting idea, but not really that much less code than the original implementation. I'd much rather just set up something with conditional branching than do a partial implementation or something.

Could work as a way to store the data, though, if everyone's OK with not being able to combine them with select cheats.

BTW, I've started to convert the MAME menus over to the new system. Not sure how long this is going to take, but once that's done I'll re-evaluate all the requested new features for the cheat engine. Not sure if this'll become viable at that point or not, but it'll be at least more realistic than it is now.

[kelvSYC]

My line of thinking was something that could kill two birds with one stone - allow more complicated cheats while working around multipart list cheats. Consider this:

Code: Select all

:game:F0000000:00000001:00000001:00000000:Enum 1, Choice 1:The address field is an ID for the enum while the two others are what is initially written to r0 and r1 upon activation by any cheat using this enum - we could use relative positioning or embed the ID into the type, allowing us three register writes per enum...
:game:F0010000:00000001:00000002:00000000:Enum 2, Choice 2
:game:F0000000:00000002:00000001:00000000:Enum 2, Choice 1

Then you could have something like this:

Code: Select all

:game:F1000000:00000001:00000000:00000000:Use Enum 1 in list:You could even extend 62000000 and say that 0 in the address bit means "don't use enums"
:game:E0010000:00000001:00000000:00001000:Write a 4-byte value from r0 to address 00001000:Right now, it's instruction-op1-op2 format, but we could embed the instruction into the type field and then we can have three operands
:game:E0010000:00000001:00000000:00002000:Same as above, but to 00002000 instead

Different cheats could use the same set of registers - they exist as a sort of scratch space that we can use without altering the actual game's memory. (At the beginning of the cheat's execution there is no guarantee of the existing values in the registers)

Again, the major weakness is branching, unless you are thinking of, say, "jump over the next three lines of this cheat if A < 0" that kind of thing.

[ianpatt]

Hmm. I was actually thinking about making each cheat in a linked cheat an instruction in the program; it'd be by far easiest that way as most of the code for that exists already. Will think of some alternative.

Again, the major weakness is branching, unless you are thinking of, say, "jump over the next three lines of this cheat if A < 0" that kind of thing.

That's basically what I was thinking. It'd be very easy to implement with the way linked cheats are already set up.

[kelvSYC]

I like the instruction idea, and I think it was the original intent of CheatScript.

The main purpose of this idea is mainly to allow for more complex cheating constructs, as well as dispensing with ROM hacks that disable some kind of storage mechanic (say, checksumming for valid data) which may also cause side effects, by effectively duplicating the mechanic in the cheat.

An example of an application:

Let's go back to GBA Pok?mon as an example. A Pok?mon's OTID is used as one of the two XOR encryption values (I forget the other), and the sum of all of the unencrypted values is the checksum (if that doesn't match up, we have a Bad Egg). Also, the Pok?mon's nature will determine how a 48-byte block in the data (which contains, say, the Pok?mon's move data, current HP, IVs, and so on) is arranged - if you change the nature you will also (most likey) change how the 48 bytes are arranged, thus requiring a copy operation. Thus, a simple change in a Pok?mon's attributes would require a massive (cheat-wise) computation (that may even be significant enough to disturb the emulation), requiring mass changes to be made to the memory (so the cheat would only be guaranteed to work if the emulation is paused, for instance).

We may also be able to extend this concept to watchpoints that have to go through all that just to get a simple value (although at this time it looks like that part might even need a complete rewrite to make it work). Another potential application is to, given an enum and a watchpoint, get the enum string corresponding to the value being watched.