(Artemis) Code Types

[Skiller]

This is long. Everything is basically an "if". If you could see an actual use for it, use it, they are just a mixed jumble of ideas.

A master type D or E that would activate every other activate code only if whatever is happening is happening would be a little helpful. I'm thinking of Shadow Of The Colossus. It would save lines for that game, because all of the codes are only active if one certain line is active, or else the game freezes. There's no reason to activate any codes any other time either, so it could just as well be an extra line in the enable code as a separate code type. A "master joker" or whatever you would call it. A supplement to the enable code.
I still remember it slightly, something like E00?E264 013d8190 or something, it was needed for every code.

Your are talking about the C Code type for this that will only activate all codes in list after the Activator has been set to =. this codetype is usefull for games with Multi Games like sega Gen collection

[misfire]

Thanks for your feedback.

With the 4 code type, I'd also prefer using @n to indicate other options. The low/high RAM stuff is way too complicated. Also, the current version doesn't support "negative" address steps.

I will extend the 6 type if need be - that is, if a game requires it.

Actually, you can combine two D codes to do 32-bit tests.

All code types implemented so far are 100% compatible with CodeBreaker V7+.

[Pyriel]

Code type "B" on every device is virtually useless. Yes, bung, it's a timer delay, similar to a "C" type code. Nothing below it will execute until the countdown reaches 0. I suspect the intent is that you can use it to delay code execution until some unknown state changes. For instance, if codes are active during the loading screen the game crashes, so you set a value that delays execution for a minute of wall-clock time. In practical use, it's generally easy to replace with a "C" type, and the "C" code makes a much more reliable on/off switch.

The other purpose it appears to serve is to reset various hook-insertion values. I suppose this theoretically could be used to reset values for games with loaders, but I don't think it will actually function as intended. Besides that, they've never used it for that purpose.

Actually, I've never seen the "B" code type used, officially or unofficially. It can safely be replaced with something more practical, like say a byte-array write that could be used for string values or things of that nature.

Yeah, you can pretty easily simulate 32-bit compares with nested 16-bit compares. Well, equality and inequality type tests can be done easily. If you ever need a greater or less than comparison with any real precision, it can get a little tricky. I haven't see those used very often, except when the guys at Datel were fascinated with their new code types, and starting churning out codes like "Always Have Less Than $250,000".

What led to the decision to emulate the CodeBreaker cheat engine? I can guess, but it seems to me that wedging Artemis into that mold will constrain it quite a bit. There are quite a few useful things you could do if you aren't limited to the 4-bit command model. Granted, you could escape from it with odd control schemes, like making B a super-type with other bits actually indicating the operation to be carried out, but that could quickly get cheesy and confusing.

[Gtlcpimp]

I'm not sure if this would help you out any on determining your code types, however these are what I am putting into the next revision of my personal / public cheat device I have designed...

0 - 8 Bit Constant Write
1 - 16 Bit Constant Write
2 - 32 Bit Constant Write
3 - 8 / 16 / 32 Bit Increment / Decrement
4 - 32-bit Multiple Address Write
5 - 8 / 16 / 32 Bit Copy Bytes
6 - Line specific Pointer Write
7 - 8 / 16 / 32 Bit Boolean
8 - 8 / 16 / 32 Bit Replace Bytes
9 - Execute specified data
A - DNAS Patch Configuration
B - Delayed write (x cycles before each write)
C - 32 Bit Compare and Kill
D - Boolean: Half (Aka: Joker)
E - Line specific Boolean: Half (Aka: Joker)
F - Extend Command Structure

F: 0 - 8 Bit IOP Constant Write
F: 1 - 16 Bit IOP Constant Write
F: 2 - 32 Bit IOP Constant Write
F: 3 -
F: 4 -
F: 5 -
F: 6 -
F: 7 -
F: 8 -
F: 9 - Delayed execute specified data
F: A -
F: B -
F: C -
F: D - Chunk Boolean: Half
F: E - Line specific chunk Boolean: Half
F: F -

(As my mind wanders the list actually grows, at the current moment those are what is guaranteed to go into the next revision)

[misfire]

@Pyriel:

I mainly chose CodeBreaker because a) it has a powerful cheat engine and b) it's the system with the largest user/code base. And that's why I care about compatibility. (For "historical reasons", the Xploder supports almost the same code types - another pro.)

IMHO, the 4-bit command model is sufficient. Think of it, are there really so many code types that you are missing?

We should not start implementing dozens of different code types each doing one special thing, but rather think about missing fundamental types that can be combined to do more powerful things.

[Pyriel]

Compatibility is fairly obvious. The question is more, "what's the target audience?", I guess. Personally, I'd prefer to see something powerful and extensible versus something that can use all my old codes with no transformation. Maybe that's just me. If I want to use unmodified CodeBreaker codes, I can use my CodeBreaker. However, if you're aiming this at a user-base that consists of anyone who can follow the instructions to boot it with an exploit, then compatibility with no extra steps becomes more important. Or if the goal is to provide a cheat engine simply as a convenience for testing codes prior to publishing them for commercial devices, then adding types is just needless.

Off the top of my head, I'm missing 8- and 16-bit multiple address writes and the "string" write I mentioned before. I can think of other things that would be handy, but I wouldn't deem any of them necessary. The point is simply that if something useful comes up later, you either have to ignore it, or wedge it in as an extension in a manner similar to what Gtlcpimp posted above.

[Lazy Bastard]

The intention is to completely replace commercial cheat systems. To that end, Artemis will launch from memory card via FMCB without need for another exploit, nor a modchip.

[Viper187]

Does PS2 use TLB mapping? Most of my MIPS experience came from N64, and that mapping shit was always a nightmare. Set a breakpoint and turn up a crazy virtual address instead of the real one, and the real one moves around. Anyway, the thing the N64 shark always needed was a TLB write code type to write ram hacks using those virtual addresses. Thought I'd mention it, in case it's relevant for PS2. I don't know how many people have actually gotten to set a breakpoint/watchpoint on PS2, but hopefully we'll be changing that in the near future. heheh

[kh2k4]

It'd make sense there's specific tlb builds for pcsx2 after all. I seem to remember the difference being virtual memory pagefile.sys vs actual ram, It was a speed thing I think ie: the actual ram being quicker than read / writing to a temporary file on the hdd but at the cost of less ram to play with if you only have a small amount to start with say 512-1GB any pc with 2GB+ I don't think it has any real benefit.
The pcsx2t tlb build uses the actual ram same as the EE on a real PS2? whereas pcsx2 doesn't and uses the pagefile instead.
The I/O P is essentially a ps1 used for emulation that's disabled as soon as your in PS2 mode?

[Parasyte]

I'm also of the crowd that believes modernization and extensibility are superior goals than backward compatibility. I used to have a mantra, "If you live in the past, you have no future." I think it's quite suiting in terms of technology, as well. For one example, just look at the archaic Intel 8080. That's all your super duper 3GHz Intel Core7 quad-core CPU is... A 40-year-old architecture with a couple tack-on improvements and better lithography.

Back on topic a bit more, I've always imagined that the old address/value format is becoming dated. It's a nightmare that the format has to be bit-mangled to squeeze meaningful operations into the address field. But it is even worse that in some cases, the address field is shifted over into what is commonly the value field, because a single 32-bit number cannot contain enough information to do everything that is requested.

Maybe code types, as we currently know them, need to be reinvented. 32-bits is not scalable. At all. Just look at the "Y2K38 Problem" ... We face similar problems, and the workarounds so far have been less than comforting.

One idea I've been toying with for a while is extending the "code type" to its own unique field. It could be just an 8-bit number stuck in front of the address, for example:

00-00000000 00000000

There, now you have 256 usable code types. Maybe that's not enough?

But there's also another problem. And this is going to be a bit counter-intuitive, I know, but bear with me. Code engines have progressed from extremely primitive poke-only dumb loops to something resembling a programming language in its own right. You can perform condition checks, loops, variable reads and writes... May as well just make it a bloody virtual machine with the "codes" being little more than byte codes for a VM interpreter. Or if you want to get real fancy, you could even give those byte codes some mnemonics; make it a proper machine language.

This will all make the parser more complex, and the creation of new codes more difficult to grasp. But we should face the facts that while we do not have infinite resources, we do have to make sacrifices on both terms; size vs. speed, quality vs. quantity, ease of use vs. raw power...

Forgive me for saying this, misfire, but supporting the Codebreaker format is effectively locking yourself to it. It seems like you would rather be free of such a proprietary mess.

[Lazy Bastard]

One idea I've been toying with for a while is extending the "code type" to its own unique field. It could be just an 8-bit number stuck in front of the address, for example:

00-00000000 00000000

I had considered the same...

[Gtlcpimp]

To hell with 256 commands, make each "1 line code" consume 12 bytes. That way you can have the first 4 bytes contain the command, shit you'd have 4294967296 commands that way >:]

In all honesty I say stick with a 4 bit command, and leave one of the command open for an extended structure. So instead of limiting yourself to 16 commands, you can extend out to as many as you need while maintaining compatibility with already made codes such as the ones with Code Breaker. You keep that compatibility, while building your own command structures as you go allowing the cheat engine to perform any task your heart desires. Maybe one day if one of us get bored enough we just might come up with a full C interpreter that lets you type up C coding and run that as codes off the device... Hell how about a Java virtual machine!

[misfire]

Forgive me for saying this, misfire, but supporting the Codebreaker format is effectively locking yourself to it. It seems like you would rather be free of such a proprietary mess.

From a technical point of view, you are right.

I just wanted to have a quick and simple solution allowing us to use available codes on the one hand and add (a few) new code types on the other. I would be more than happy to see if anybody puts more energy into this and comes up with a better system.

[Viper187]

What about doing both? The suggested extra byte(s) at the start of a code could still allow the basic (or all) CB types to function as type 00, so you'd have your new types or the option of entering the CB types prefixed with 0s. Hell, you could even do 00 for CB raw and 01 for AR raw if you wanted, assuming there's much difference in raw code types.

[Parasyte]

The truth is, there are a lot of options available. The sky is the limit, as they say. But I don't believe that; the limits are the same as human ingenuity.