The Game Genie was branded as a 'game enhancer'
to skirt around copyright laws. It was seated between the console and the
cartridge to intercept signals to read from the game's ROM. This lets the player essentially rewrite a
handful of bytes in the game's code, allowing for simple cheats and modifications. The Game Genie line of products did not produce
derivative works from the game being played--it only acted as a middle man between the processor
and the ROM data. When the processor needs to read or execute
from ROM, the value stored on the game's cartridge at the specified location is copied to an
internal register. The Game Genie monitors every read from ROM,
and hijacks the signal if any of the applied Game Genie codes correspond to that memory
location. Each code can monitor a single location and
substitute in a single value in place of the intended value from ROM. This technique was very limited however, since
only 3-5 codes could be inputed at once, so only a handful of bytes could be changed at
a time. A problem with this method arises when dealing
with systems that use ROM bank switching. In order to have more ROM than allocated by
the system, smaller banks of ROM can be swapped in and out of the memory map. This means that some memory address might
not always correspond to the same ROM value, since the bank currently occupying that space
in memory could be different. In the Game Genie's case, this would result
in any value that happens to sit in that memory location to be replaced, instead of just the
one intended ROM value. To try to mitigate this problem, a comparison
value could also be packed into the code. This would be compared to the game's ROM value--if
they matched, the Game Genie would hijack the value. If not, the original ROM value was allowed
through. Again, this didn't solve the issue entirely,
but it helped cut down on unintended replacement. There is no way that the Game Genie could
tell exactly which ROM banks are currently mapped to memory, so this was the best it
could do. In general, a Game Genie code is made up of
letters and numbers, and encodes a ROM memory address, a value to substitute in, and an
optional conditional operand. It is questionable as to why this information
was encoded into a different string of characters instead of just keeping them in a raw format. In some cases, the encoding made the code
shorter, easier to remember, or provided a simple integrity check. It is also possible they were encoded to seem
more 'magical;' that is, changing a single character by one could result in a completely
different code. Game Genies were released for the Nintendo
Entertainment System in 1990, and then for the Nintendo Game Boy, Sega Game Gear, Super
Nintendo, and the Sega Genesis/Mega Drive in 1992. They all work very similarly, but each has
their own quirks due to the differences in the consoles they were made for. Let's start with the NES version. Codes can be six or eight characters long. Eight-letter long codes have a conditional
check while the six-letter variant do not. The first step to decoding the string is to
substitute each letter for the 4 bits that it stands for. For example, T stands for 0110, O stands for
1001 and so on. This transforms the codes into strings of
24 or 32 bits, which is 3 or 4 bytes. You'll notice this happens to be the exact
amount of information we need to fill in the address, value, and condition. However, it would be too easy to read off
the bits one-by-one in order; the bits need to be shuffled around to decode the information
correctly. In the NES's case, the bits are grouped in
sets of one and three like so, and the raw code can be identified. An interesting fact about the NES Game Genie
is that the codes actually come in pairs. The NES's cartridge ROM is mapped to only
the upper 32kB of memory space, so the first bit of the address is always guarenteed to
be 1. For this reason, the third character in the
code actually has two options: one where the first bit is 0 and one where it is one. Here you can see that the code TOPLINES will
produce the same effect as the code TOOLINES. This whole process can also be done in reverse
when you want to create a Game Genie code from a known ROM patch. For example, in Super Mario Bros., the number
of lives the player starts with is located at ROM address $906A.
Let's set this value to $08 so we start with 9 lives instead of 3. Super Mario Bros. doesn't use any bank switching
so a conditional check is unecessary, but we could set it to $02 and would work just
fine. Re-encoding the string gives us AATOZE. Maybe to make the code easier to pronounce
and remember, it could be changed to PATOZE, which would change the number of lives to
10. The Nintendo Game Boy and Sega Game Gear Game
Genies work almost identically since the ROM mapping is almost the same for the two consoles. In this case, the characters to choose from
are 0-9 and A-F. They don't need to be remapped like the NES. Both systems use bank switching, so a conditional
check can be added by appending 3 characters to the end of a 6-letter code. Here is the how the address, value, and conditional
information is decoded from the string of bits. As you can see, it's a little more complicated. The address and value parts are pretty straightforward. The only quirk is that the highest 4 bits
of the address are flipped. However, when a conditional check is added,
things get pretty interesting. The eighth character in the code is determined
directly by the seventh character--the first bit must be flipped and the other three must
match, or the code is determined to be invalid. This sort of acts like an itegrity check to
make sure you typed the code in correctly, but it really only checks the seventh character
for whatever reason. Then the conditional is determined by shuffling
and flipping various bits from the seventh and ninth characters. There is a something else to keep in mind
with these codes, and that is the consoles' ROM memory mapping. The Game Boy maps ROM from $0000 to $7FFF,
so the sixth character is limited to the characters 8, 9, and A-F. Similarly, the Game Gear maps ROM from $0000
to $BFFF, so the sixth character cannot be a 0, 1, 2, or 3. Otherwise the code will be determined to be
invalid. The SNES Game Genie has the simplest conversion
out of all of them. The code characters range from 0-9 and A-F,
but don't be fooled. There is a different mapping from these characters
to binary that isn't just a base conversion. Since most games didn't have a ROM bank switching
feature, the conditional check was not even implemented on this system. Here is how the bits are encoded to form the
Game Genie code; some of them are split into pairs. The address covers an entire 24-bit range,
but the codes must refer to ROM locations, which are different depending on which memory
mapping the game uses. And finally is the Genesis/Mega Drive Game
Genie. It is very similar to the Super Ninendo Game
Genie, with eight-character codes and no necessary conditional check. The one major difference is that there are
twice as many characters to choose from: almost the entire alphabet is available. Each character now represents five bits instead
of four. This allows for the substituted value to be
16 bits instead of only eight. The reason for this change is that the Genesis's
processor, the Motorola 68000, uses a 'reduced instruction set computing' archetecture. All the instructions are at least 16 bits
in size, so in general the smallest meaningful unit to modify is 16 bits wide. In contrast, all the other consoles mentioned
in this video use a 'complex instruction set computing' archetecture. That is, the instruction and its operands
occupy separate bytes, so you can get away with only modifying one 8-bit byte at a time,
like in the Mario example. The last thing to mention is that the Genesis's
ROM is mapped from $000000 to $3FFFFF. This limits the fourth character to be A,
B, C, D, T, V, W, and X; otherwise, the code would not point to ROM and would be considered
invalid. The Game Genie could only substitute bytes
from ROM with custom values. Other 'game enhancers' such as the Game Shark
and Action Replay could constantly write values to RAM, or even only apply a code when a certain
event is triggered. But those devices will have to be discussed
in another video. Thank you for watching.
