Forums

X-Terminator is a rare device that is very similar to the Pro Action Replay. It sits between the system and the game cartridge and injects code to write to memory. Some information is here:

https://www.smspower.org/forums/18074-XTerminatorForGameGearGameGenieActionRepla...

This thread is about how it works, based only on the ROM dump.

It has an 8KB ROM at address $0000. It has 8KB RAM at address $2000. On the body of the device there is a two-position switch labelled "NORMAL" and "ACTION". When in the "normal" position, the device does nothing, passing all lines through to the cartridge. When in the "action" position, it injects code into the interrupt handler. It seems to do this by swapping between its ROM/RAM and the game cartridge, at least in the lower 16KB, every time address $0038 is read. It does not make use of the interrupt handler itself.

In its injected interrupt handler, it checks bit 0 read from address 7. If this is 0, it jumps to its own menu at address $0000. This seems to correspond to a "reset" button on the device, which I guess also triggers the interrupt handler injection.

If the reset button was not pressed, it proceeds to write data to six memory locations specified in device RAM. As these default to address $0000, there is no effect, but if a suitable cheat code is entered, it will write to RAM and have some effect.

It also runs its ROM from $0000 by default on boot, according to the manual. It does not enable interrupts, it just runs slowly enough to not need to wait for VBlanks to update the screen.

The device also has a function to search for cheat codes. This is the reason why it has 8KB of RAM - the majority is used to track memory values during a code search. It has similar search modes to the Pro Action Replay, handling things like BCD and off-by-one values as well as 16-bit counters and flags.

One notable difference from the PAR is that it will also detect and search for cheats in the on-cartridge RAM, but only the first 8KB of it. This may be needed for games using it as extra scratch memory, or for hacking save games.

Similar to the PAR, only having 8KB of RAM means it can only "search" a little less than 2KB of the potential memory locations at once - as it needs four bytes to track each location - which means the trickier cheat searches will take a few iterations as it needs to eliminate possibilities to free space to even start considering later locations. As it searches the save RAM first, it'll be especially slow to find codes on games with save RAM.

Also similar to the PAR, it has no way to run only in VBlank interrupts, so games using HBlank interrupts may show some slowdown or graphical glitches as the HBlank code is delayed.

Somewhat different to the PAR, it does not attempt to boot back to the BIOS (which may not even be present). As a result, it may be incompatible with some SMS games if using a Master Gear Converter or equivalent, or an Everdrive.

I'll publish my disassembly after the ROM is released...

X-Terminator 2.1-01.png (1.64 KB)

X-Terminator 2.1-02.png (1.81 KB)

X-Terminator 2.1-03.png (2.16 KB)

The “lives” cheat scanner takes the value you enter (in decimal) and looks for bytes that have values equal to it in BCD or hex, for a range of one either side. e.g. a value of 99 would be searched for as $98, $99, $9a, $63, $64, $65 hex. On subsequent interactions of the scan process it requires that the offset is the same as previous matches, e.g. an address matching for an equal value for 99 must then match an equal value for the next searched value.

As this is filtering by value, it is likely to cover the full range of RAM in the first iteration, making it the fastest way to find a cheat, if you know the value to search for (and the searched value is not a common value like 0 or 1).

The “timer” scanner works by searching for delta changes from some initial value. The user may only enter a number from -9 to +9. Values are searched for a delta change of that amount, but always using BCD maths. Searches are only at the byte level. As it needs to find delta changes, it needs to track values for all possible memory locations until they are discarded; this means it needs a few iterations to even look at the higher addresses.

As it’s only ever looking at single byte BCD values, it seems like it will only ever find values that you could have found quicker using the Lives method. I don’t think a game would store a number as BCD and not show you that decimal representation.

Energy Bar mode is a bit more tricky, and therefore also makes harder to discard possible values. You start by capturing some “100%” value, which cannot be exceeded. You then iterate by picking a value of “roughly 25%”, “roughly 50%”, “roughly 75%” or exactly 100% of this initial value. At each stage it will discard values that are unacceptably far from the value you picked. This means, for example, that a “roughly 25%” value is considered acceptable if it is less than 50% of the previously captured 100% value.

However, as again it can’t track all of the memory due to only having 2KB of device RAM, it has to try to capture more values as possibilities get excluded. Some of these may be captured in one of the non-100% iterations, meaning the corresponding 100% value is unknown. It therefore treats these with an even greater margin. For example, an address known to have a “roughly 75%” value is only trusted to have >50%, and thus can only be used to discard numbers at the 25% and 100% levels. This means it will take longer to discard possibilities.

Hi Bock,

thanks for the dump and thanks to Maxim to his disassembling work and research!
Following Maxim's research, I got it emulated to the point that codes can be entered and automatically get applied by the executed code on interrupt.
What's missing from the emulation is the functionality of the Reset button and the mode switch.
From the manual I understand, that the switch should be set to NORMAL mode and when the system powers on it should boot into the menu but from the dump it seems like the reset button was being pressed.
So the main questions that remain to me right now are, what effects do the reset button the two modes have and also if it makes a difference whether a cartridge is plugged into the device or not.
Could you please try dumping the ROM with different setups so we can check for their effects?

I think it should be:

- Always boots to the X-Terminator ROM
- Action -> switch between the X-Terminator ROM and cartridge when reading from $38
- Normal -> switch to cartridge ROM only when $38 is read
- Reset -> reset bit 0 of address 7 and switch to X-Terminator ROM when $38 is read (while held)

This matches the behaviour expected when using the device. It would also explain why holding Reset allows it to be dumped.

Alternatively you may find that in normal mode you can dump the first $38 bytes in one pass and the remaining part in the second pass.

On with the search algorithms. "Power" mode again searches for bytes, but this time the three possible states are equal, greater or less than some known starting value. At each iteration, values can be discarded if the known state is incompatible with the new state. For example, if the value stored is the "equal" value and the new state is "greater", then it can be discarded if the current value is not greater than the stored value. However, if the value stored is only known to be greater than what is wanted, it can't be discarded if the current value is also greater than what is wanted, because even if it is a different value, we can't know if that value is the target.

This is I think a failing of all these cheat devices: they don't have enough RAM to store state for all of RAM, so they have to try to capture additional state after earlier iterations have discarded possibilities and freed up RAM. However, this means the initial state of all RAM is unknowable; so either the algorithm has to try its best to capture the data in the non-initial state, and make use of it as best it can, or require the user to revisit the initial state to capture the right values for those new addresses. The former might get codes faster, but will sometimes produce you a code that sets the variable to the wrong state. The latter will take more iterations to reach the end of RAM but will at least find the right code.

Fitting the device with more RAM would allow it to simply take a copy of all RAM at the start and do comparisons later. To support the 16KB of RAM searched by the X-Terminator would require 16KB plus a little bit more, so I guess 32KB RAM would be needed; presumably that would have made it more expensive, but it would work much better.

"Status" mode searches for bytes whose bits all invert when something is in the "opposite" state. This will only really work for cases where the game uses a whole byte for a flag, and flips between $ff and $00. It can't find single-bit flags.

"Other possibility" mode is the last scanner mode. This searches for bytes that are either equal to the initial state, or different in any way at all. If bytes are captured in a "different" iteration then the "correct" value is again unknown, and they are less useful because you can't tell if a new value is indeed different to the initial state.

Overall, these search algorithms are reasonable for a lot of cases but will fail to find cheat codes in a lot of cases. There is no allowance for 16-bit or higher numbers. However, it's quite interesting to have had such devices and to have this relatively unknown one. Maybe it was more well-known in Japan while the PAR was well-known in Europe, and Game Genie in the US?

So this is how I emulate it:
When the X-Terminator ROM is active:
Address 7 returns the state of the reset button (active low) in the least significant bit. The remaining bits of the returned byte are 1.

Reads from all other addresses < $2000 read from the X-Terminator ROM.

Reads from addresses >= $2000 and < $4000 read from the X-Terminator RAM.

I'm passing all reads from addresses >= $4000 through to the cartridge. I'm not sure if all the reads should go through but at least reads from SRAM should go through because from what I understood the X-Terminator can also operate on SRAM.

Write to addresses >= $2000 and < $4000 write to X-Terminator RAM.

When the X-Terminator ROM is not active, all reads and writes are passed through to the cartridge.

The swapping logic is triggered by reads from address $38:
In normal mode there's only a swap to the cartridge as soon as $38 is read.
In action mode reads from address $38 swap between X-Terminator and cartridge.
While the Reset button is held, a read from address $38 also swaps to the X-Terminator.

The X-Terminator enables on-cartridge RAM and writes to address $8000 to detect if it is RAM (restoring the original value afterwards). It assumes save RAM is 8KB.

Author	Message
Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Reverse engineering X-Terminator cheat device for Game Gear Posted: Wed Nov 25, 2020 10:35 pm
	X-Terminator is a rare device that is very similar to the Pro Action Replay. It sits between the system and the game cartridge and injects code to write to memory. Some information is here: https://www.smspower.org/forums/18074-XTerminatorForGameGearGameGenieActionRepla... This thread is about how it works, based only on the ROM dump. It has an 8KB ROM at address $0000. It has 8KB RAM at address $2000. On the body of the device there is a two-position switch labelled "NORMAL" and "ACTION". When in the "normal" position, the device does nothing, passing all lines through to the cartridge. When in the "action" position, it injects code into the interrupt handler. It seems to do this by swapping between its ROM/RAM and the game cartridge, at least in the lower 16KB, every time address $0038 is read. It does not make use of the interrupt handler itself. In its injected interrupt handler, it checks bit 0 read from address 7. If this is 0, it jumps to its own menu at address $0000. This seems to correspond to a "reset" button on the device, which I guess also triggers the interrupt handler injection. If the reset button was not pressed, it proceeds to write data to six memory locations specified in device RAM. As these default to address $0000, there is no effect, but if a suitable cheat code is entered, it will write to RAM and have some effect. It also runs its ROM from $0000 by default on boot, according to the manual. It does not enable interrupts, it just runs slowly enough to not need to wait for VBlanks to update the screen. The device also has a function to search for cheat codes. This is the reason why it has 8KB of RAM - the majority is used to track memory values during a code search. It has similar search modes to the Pro Action Replay, handling things like BCD and off-by-one values as well as 16-bit counters and flags. One notable difference from the PAR is that it will also detect and search for cheats in the on-cartridge RAM, but only the first 8KB of it. This may be needed for games using it as extra scratch memory, or for hacking save games. Similar to the PAR, only having 8KB of RAM means it can only "search" a little less than 2KB of the potential memory locations at once - as it needs four bytes to track each location - which means the trickier cheat searches will take a few iterations as it needs to eliminate possibilities to free space to even start considering later locations. As it searches the save RAM first, it'll be especially slow to find codes on games with save RAM. Also similar to the PAR, it has no way to run only in VBlank interrupts, so games using HBlank interrupts may show some slowdown or graphical glitches as the HBlank code is delayed. Somewhat different to the PAR, it does not attempt to boot back to the BIOS (which may not even be present). As a result, it may be incompatible with some SMS games if using a Master Gear Converter or equivalent, or an Everdrive. I'll publish my disassembly after the ROM is released... X-Terminator 2.1-01.png (1.64 KB) X-Terminator 2.1-02.png (1.81 KB) X-Terminator 2.1-03.png (2.16 KB)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Thu Nov 26, 2020 7:16 pm
	The “lives” cheat scanner takes the value you enter (in decimal) and looks for bytes that have values equal to it in BCD or hex, for a range of one either side. e.g. a value of 99 would be searched for as $98, $99, $9a, $63, $64, $65 hex. On subsequent interactions of the scan process it requires that the offset is the same as previous matches, e.g. an address matching for an equal value for 99 must then match an equal value for the next searched value. As this is filtering by value, it is likely to cover the full range of RAM in the first iteration, making it the fastest way to find a cheat, if you know the value to search for (and the searched value is not a common value like 0 or 1).

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Thu Nov 26, 2020 7:34 pm
	The “timer” scanner works by searching for delta changes from some initial value. The user may only enter a number from -9 to +9. Values are searched for a delta change of that amount, but always using BCD maths. Searches are only at the byte level. As it needs to find delta changes, it needs to track values for all possible memory locations until they are discarded; this means it needs a few iterations to even look at the higher addresses. As it’s only ever looking at single byte BCD values, it seems like it will only ever find values that you could have found quicker using the Lives method. I don’t think a game would store a number as BCD and not show you that decimal representation.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Thu Nov 26, 2020 7:41 pm
	Energy Bar mode is a bit more tricky, and therefore also makes harder to discard possible values. You start by capturing some “100%” value, which cannot be exceeded. You then iterate by picking a value of “roughly 25%”, “roughly 50%”, “roughly 75%” or exactly 100% of this initial value. At each stage it will discard values that are unacceptably far from the value you picked. This means, for example, that a “roughly 25%” value is considered acceptable if it is less than 50% of the previously captured 100% value. However, as again it can’t track all of the memory due to only having 2KB of device RAM, it has to try to capture more values as possibilities get excluded. Some of these may be captured in one of the non-100% iterations, meaning the corresponding 100% value is unknown. It therefore treats these with an even greater margin. For example, an address known to have a “roughly 75%” value is only trusted to have >50%, and thus can only be used to discard numbers at the 25% and 100% levels. This means it will take longer to discard possibilities.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Sat Nov 28, 2020 11:33 am
Calindro Joined: 14 Apr 2013 Posts: 624	Hi Bock, thanks for the dump and thanks to Maxim to his disassembling work and research! Following Maxim's research, I got it emulated to the point that codes can be entered and automatically get applied by the executed code on interrupt. What's missing from the emulation is the functionality of the Reset button and the mode switch. From the manual I understand, that the switch should be set to NORMAL mode and when the system powers on it should boot into the menu but from the dump it seems like the reset button was being pressed. So the main questions that remain to me right now are, what effects do the reset button the two modes have and also if it makes a difference whether a cartridge is plugged into the device or not. Could you please try dumping the ROM with different setups so we can check for their effects?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Sat Nov 28, 2020 8:32 pm
	I think it should be: - Always boots to the X-Terminator ROM - Action -> switch between the X-Terminator ROM and cartridge when reading from $38 - Normal -> switch to cartridge ROM only when $38 is read - Reset -> reset bit 0 of address 7 and switch to X-Terminator ROM when $38 is read (while held) This matches the behaviour expected when using the device. It would also explain why holding Reset allows it to be dumped. Alternatively you may find that in normal mode you can dump the first $38 bytes in one pass and the remaining part in the second pass.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Sat Nov 28, 2020 10:30 pm
	On with the search algorithms. "Power" mode again searches for bytes, but this time the three possible states are equal, greater or less than some known starting value. At each iteration, values can be discarded if the known state is incompatible with the new state. For example, if the value stored is the "equal" value and the new state is "greater", then it can be discarded if the current value is not greater than the stored value. However, if the value stored is only known to be greater than what is wanted, it can't be discarded if the current value is also greater than what is wanted, because even if it is a different value, we can't know if that value is the target. This is I think a failing of all these cheat devices: they don't have enough RAM to store state for all of RAM, so they have to try to capture additional state after earlier iterations have discarded possibilities and freed up RAM. However, this means the initial state of all RAM is unknowable; so either the algorithm has to try its best to capture the data in the non-initial state, and make use of it as best it can, or require the user to revisit the initial state to capture the right values for those new addresses. The former might get codes faster, but will sometimes produce you a code that sets the variable to the wrong state. The latter will take more iterations to reach the end of RAM but will at least find the right code. Fitting the device with more RAM would allow it to simply take a copy of all RAM at the start and do comparisons later. To support the 16KB of RAM searched by the X-Terminator would require 16KB plus a little bit more, so I guess 32KB RAM would be needed; presumably that would have made it more expensive, but it would work much better.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Sat Nov 28, 2020 10:31 pm
	"Status" mode searches for bytes whose bits all invert when something is in the "opposite" state. This will only really work for cases where the game uses a whole byte for a flag, and flips between $ff and $00. It can't find single-bit flags.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Sat Nov 28, 2020 10:38 pm
	"Other possibility" mode is the last scanner mode. This searches for bytes that are either equal to the initial state, or different in any way at all. If bytes are captured in a "different" iteration then the "correct" value is again unknown, and they are less useful because you can't tell if a new value is indeed different to the initial state. Overall, these search algorithms are reasonable for a lot of cases but will fail to find cheat codes in a lot of cases. There is no allowance for 16-bit or higher numbers. However, it's quite interesting to have had such devices and to have this relatively unknown one. Maybe it was more well-known in Japan while the PAR was well-known in Europe, and Game Genie in the US?

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Mon Nov 30, 2020 7:17 pm
Calindro Joined: 14 Apr 2013 Posts: 624	So this is how I emulate it: When the X-Terminator ROM is active: Address 7 returns the state of the reset button (active low) in the least significant bit. The remaining bits of the returned byte are 1. Reads from all other addresses < $2000 read from the X-Terminator ROM. Reads from addresses >= $2000 and < $4000 read from the X-Terminator RAM. I'm passing all reads from addresses >= $4000 through to the cartridge. I'm not sure if all the reads should go through but at least reads from SRAM should go through because from what I understood the X-Terminator can also operate on SRAM. Write to addresses >= $2000 and < $4000 write to X-Terminator RAM. When the X-Terminator ROM is not active, all reads and writes are passed through to the cartridge. The swapping logic is triggered by reads from address $38: In normal mode there's only a swap to the cartridge as soon as $38 is read. In action mode reads from address $38 swap between X-Terminator and cartridge. While the Reset button is held, a read from address $38 also swaps to the X-Terminator.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Mon Nov 30, 2020 7:50 pm
	The X-Terminator enables on-cartridge RAM and writes to address $8000 to detect if it is RAM (restoring the original value afterwards). It assumes save RAM is 8KB.

Forums

View topic - Reverse engineering X-Terminator cheat device for Game Gear