(Artemis) Code Types

[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.

[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.

[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!

[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.