Cheat Device architecture

[EmOneGarand]

Hey, was wondering if anybody here has any knowledge on or anywhere I might find how a cheat device such as Game Genie or Action Replay (Cartridge based) work? I can't find schematics or basic info on how the hardware works (besides software). Thanks.

Edited September 17, 2006 by EmOneGarand

[EmOneGarand]

Perhaps I should be more specific... I'm looking for how I can build an cheat device for a system it hasn't been done for before (at least commercially to my knowledge) What I want to know is how the electronics inside such a device would be laid out especially input and output. Schematics of a SNES Gamegenie or a N64 Gameshark would help some if anybody knows where I can find any.

[Bruce Tomlin]

The general idea is that you have something that goes between the cartridge and console, which checks for a few specific addresses, then replaces the data with the hack if the address matches. Basically you have a CAM (content-addressable memory) that holds the cartridge addresses, plus another matching memory with the replacement data.

 

If it was done with an FPGA, you would probably have a bunch of N-bit registers for the address, which would be compared for equality using a bunch of XOR terms fed into a big AND term for each "line" of code that you want to support. Then you would have a menu program which knows how to 1) load the codes into the CAM, 2) disable access to the CAM (to avoid accidental access in the game itself), and 3) switch over to the cartridge ROM.

 

With more advanced CPUs such as the ARM in the GBA/DS, it might be possible to write a fully software version by using the MMU to remap the ROM to a changed RAM page. There are also issues that may make things more complicated, such as I think the N64 uses compression in the cartridge, decompressing code and data into RAM as needed.

 

CD/DVD-based code systems would work by intercepting the disc read routines and changing specific sectors after they are read.

[EmOneGarand]

The general idea is that you have something that goes between the cartridge and console, which checks for a few specific addresses, then replaces the data with the hack if the address matches. Basically you have a CAM (content-addressable memory) that holds the cartridge addresses, plus another matching memory with the replacement data.

 

If it was done with an FPGA, you would probably have a bunch of N-bit registers for the address, which would be compared for equality using a bunch of XOR terms fed into a big AND term for each "line" of code that you want to support. Then you would have a menu program which knows how to 1) load the codes into the CAM, 2) disable access to the CAM (to avoid accidental access in the game itself), and 3) switch over to the cartridge ROM.

 

With more advanced CPUs such as the ARM in the GBA/DS, it might be possible to write a fully software version by using the MMU to remap the ROM to a changed RAM page. There are also issues that may make things more complicated, such as I think the N64 uses compression in the cartridge, decompressing code and data into RAM as needed.

 

CD/DVD-based code systems would work by intercepting the disc read routines and changing specific sectors after they are read.

That helps alot thanks, do you think it'd be difficult to create a device like this for the Atari Jaguar?

[djmips]

Although intercepting the DVD disk read routines would be a great solution that is probably used, an alternative that I have seen (on the PS1 GameShark for instance) is to intercept at a higher level, like at the load executable level and patch RAM after the entire executable is loaded in memory.

 

Note, that the patching notation is usually given as address:byte and this is scrambled to give the actual code itself (to protect from competitors I imagine). However most of the older patching systems have been reverse engineered and you can find how to generate codes by searching online.