Before we continue, it might be a
good idea to give you guys a crash course in how the GameShark and
emulators work. This is a question that gets asked a lot, and
understanding some of the more basic concepts will allow you to
understand how some of the things discussed later on actually do what
they do. It also explains why some things can be done with the
GameShark, and why some things don't work so well with emulators.
Note: we are not endorsing usage of emulators on commercial ROMs here! This is meant for your education only.
For starters, we'll explain a concept called
memory.
Memory is pretty much the same as what our brains and nerve cells have:
it stores information for later retrieval. Our brains use memory
to learn, adapt, develop, and grow. With computers, memory is
usually used for keeping track of numbers and knowing what to do
next. Computer memory comes in two flavors, both of which are
similar to our own brains: short-term and long-term.
The N64 does not use long-term memory (nor do most consoles; long-term
memory is usually a hard drive or flash card). For short-term
memory, it uses something called RAM (short for
Random
Access
Memory).
You've probably heard of RAM before, since every computer uses it, but
you might not understand how it works. It's not very difficult to
learn, thankfully.
Pretend that you have a hundred pieces of paper, each of them
numbered. You can write a number between 0 and 255 on these
pieces of paper, but you're using trick ink, so you have to rewrite
those numbers all the time in order for you to see them. That's
pretty much how RAM works. Every piece of paper starts with 0,
and the processor (think of it as the boss) can tell it to change those
numbers to whatever it wants. So, for example, the processor
wants page 26 to have the number 3 on it. You get page 26 and
start writing the number 3 on it, but the ink starts to disappear, so
you have to keep writing it. The processor then does some other
things, and eventually asks what you've got on page 26. You go to
the page, see the 3, and send the number to the processor.
That's precisely how RAM works. The reason the ink disappears, by
the way, is because its cheaper than getting ink that doesn't disappear
(trust me, that's really how the RAM in the N64 works). It also
tends to be slower since it has to do a lot of writing, so things like
graphics cards use "static RAM", which has much better ink. The
N64 has some of this RAM too, but it's only a small amount, so it
doesn't get used much.
Now let's translate our pages to GameShark/computer lingo. The
pages we were using are actually called "bytes", and just like the
pages we had before, every byte can hold a number between 0 and
255. No more, no less. The page numbers we had are called
"addresses", and these addresses are used to quickly jump from one byte
to the next. We won't get into complicated stuff here (like how
these numbers turn into programs or how we make negative numbers), but
there is one teensy complicated thing you need to understand before the
GameShark makes any sense.
Computers use binary numbers; in other words, they only understand the
digits 0 and 1. For the number 2, computers use 10. 3 is
11, 4 is 100, 5 is 101, and so on. This gets old really fast for
us, so instead we use hexadecimal numbers. This means we can use
all of the digits we're familiar with, but we've also got A, B, C, D,
E, and F. So the number 10 becomes A, 11 becomes B, 12 becomes C,
and 16 becomes 10. With addresses, you don't really have to worry
about converting decimal to hexadecimal, since they're just pointing us
to the numbers we want to look at (page numbers point at the page we
want to look at-- get it?). When you're dealing with the values,
though, I suggest you use your computer's calculator program to convert
from hexadecimal (usually abbreviated as Hex) to decimal (Dec) and back.
Now lets look at an example. Here's a sample GameShark code:
8011B9E3 0020
The first section (8011B9E3) is the address, and the second section
(0020) is the value we want to store there. Now, unfortunately,
we just lied. Because of how the GameShark works, the first
section isn't actually the real address. The last six numbers are
the address (11B9E3) and the first two make an instruction code
specific to the GameShark. In decimal, that means we want to
change the 1,161,669th byte in the N64's RAM to the number 32.
Here's a list of all the different instruction codes we can use, along with a detailed explanation for each one:
50 - Serial code changer
This is a special instruction code. Starting at the address in the next code,
x number of addresses will have their values set to the value given in the next code.
x is usually a number between 1 and 63 (decimal) and is followed by 01.
Example:
50000201 0000
8011B9E3 0001
Is the same as writing:
8011B9E3 0001
8011B9E4 0001
80 - Single-byte force value
This changes the byte stored at the given address to the value you
provide. It is virtually impossible for a game to prevent a
GameShark from doing this, though it can
detect it.
Example:
8011B9E3 00FF
81 - Double-byte force value
This changes two bytes, starting with the one at the address you give
(which should be divisible by 2). Since it changes two bytes, you
can use any number between 0 and 65,535, but be warned that the game
might only look at one of these bytes, leading to unexpected
results. You might also encounter negative numbers with this, in
which case you can use any number up to 32,767.
Example:
811DAA90 40CB
88 - Triggered single-byte force value
This acts the exact same way as 80 except for one thing: it only works
when you press the button on the GameShark or Action Replay. This
is useful if the game uses all of the buttons on the controller and you
don't want the code to be active all the time. Most emulators
will map the button to a function key.
Example:
88025633 0000
89 - Triggered double-byte force value
Same as 88, but changes two bytes instead of one. Again, the same rules apply here as they did with 81.
Example:
8911B99C 01F4
D0 - Code activator when == to single-byte value
This code will trigger whatever code is below it when the value stored at the address after D0 equals the value provided.
Example:
D01C84B4 0008
8111B9E4 0F0F
When the value at address 1C84B4 equals 8, then the GameShark will set 11B9E4 to F0F.
D1 - Code activator when == to double-byte value
Same as D0, but it looks at two bytes instead of just one. As always, the rules for 81 also apply here.
Example:
D111A600 0140
8011A603 0060
When the value at 11A600 equals 140, the GameShark will set 11A603 to 60.
D2 - Code activator when != to single-byte value
This code will trigger whatever code is below it when the value stored at the address after D0
doesn't equal the value provided.
Example:
D211B92F 0000
811C6F64 0101
When the value at 11B92F doesn't equal 0, the GameShark will set 1C6F64 to 101.
D3 - Code activator when != to double-byte value
Same as D2, but it looks at two bytes instead of just one. Yet again, rules for 81 also apply here.
Example:
D311B998 FFFF
8111A600 0000
When the value at 11B998 doesn't equal FFFF, the GameShark will set 11A600 to 0.
For those who are curious, here's what all of the example codes do:
50000201 0000
8011B9E3 0001
Will send you to the "Beta Quest", type 1.
8011B9E3 00FF
Will crash your game as it tries to load "Beta Quest" type 15.
811DAA90 40CB
Will send Link up into the sky forever and ever (moonjump).
88025633 0000
Will set off Luke88's code when you press the GS or AR button, which
makes the game do bizarre things and will undoubtedly crash your game.
8911B99C 01F4
Will give you 500 rupees when you press the GS or AR button (the game
will change it back to 99 or 200 if you don't have the Giant's Wallet).
D01C84B4 0008
8111B9E4 0F0F
Will set off cutscenes in the Beta Quest when you press D-Up.
It'll usually crash the game if you're in normal mode (outside the Beta
Quest).
D111A600 0140
8011A603 0060
Will give you full magic when you have 20 hearts and are at full health.
D211B92F 0000
811C6F64 0101
Will activate the RSP debugging bars whenever the A, B, and C buttons disappear (i.e., during a cutscene).
D311B998 FFFF
8111A600 0000
Will kill Link if you don't have Nayru's Love active.
There are some additional instruction codes we can use with the
GameShark, but they are used for either disabling the Expansion Pak or
making the GameShark work better with games, so we won't be covering
them here. If you're curious, you can check them out at
Kai666.
Emulators are very complex and are far beyond the scope of this site,
but we can explain why some things are different in an emulator
compared to the N64. As it turns out, there's many different
things that cause these little odditites.
Link has a white tunic and the graphics look funny - Most old graphics cards and drivers suffered from this issue.
Ocarina of Time
uses blending techniques and multi-texturing features that older cards
couldn't support, and at the time few emulators could simulate these
features. Nowadays, these features are considered obsolete but
are found in every modern graphics card for compatibility (and because
some of the advanced functions use these methods in order to work).
The game doesn't crash in the Beta Quest when it tries to say Link's name
- With versions 1.0 and 1.1 in the United States, the game would
usually freeze if it tried to display Link's name. This was
because the default name was リンク (Link in Japanese), which used
characters that weren't loaded into memory. As it tried to
display this junk, the N64 would detect a special error that happens in
the Translation Look-aside Buffer (you don't need to know what this
means, ever). Most emulators do not emulate the Translation
Look-aside Buffer, so they didn't suffer from this problem and would
continue working. If you enabled the TLB in a more powerful
emulator (such as Project64 or 1964), the game would crash.
The VGX Debug Menu trick doesn't work with emulators - When a game crashes, it can use a special program called a
stack dump
to show a bunch of information about what the game was doing when it
crashed. This information can then be used by the developers to
reproduce the crash and then fix the problem. This requires that
the stack dump has access to some special stuff that games normally
don't ask for. The N64 is fully capable of doing this, of course,
but emulators usually don't support stack tracing since the games they
run don't normally crash (and, more often than not, the emulator takes
care of the crash anyway). It is theoretically possible to make
the stack dump work on an emulator, but without a good incentive,
emulator programmers don't usually bother putting it in.
The flat textures code doesn't work on the emulator - We don't
really know for certain why this is, but it's possible that the effect
of the code isn't being emulated by the graphics plugin. It's
possible that the code is actually messing up the texture calls, which
on the N64 would hypothetically prevent them from appearing, whereas
the plugin would just ignore it. It's also possible that it's
making a call to the graphics processor that emulators don't normally
encounter, and thus don't emulate. Whatever the reason is, there
is no known workaround for it.
The game is really slow - Emulating a console is not easy.
In fact, the older the console is, the harder it is to emulate
it. This means that it takes a lot of processor (CPU) power to
make the game run at a decent speed. A 1GHz processor is usually
fast enough to get 60FPS (
Frames
Per
Second), and
anything faster can even turbo through the game (though some games,
such as Super Mario 64, have built-in limiters that keep it at a steady
60FPS). If you have a lot of intensive programs running or a slow
processor, you might get only 40FPS. Most emulators will by
default use the fastest settings possible to run the game, so there's
not much you can do about it except upgrade. Keep in mind,
though, that there are ways to make the game run slow without it being
your processor's fault, so if you're playing around with codes, then it
might be the code's fault.
The Equipment subscreen and/or background of the Start Menu looks really weird -
Ocarina of Time
uses a technique called "self-rendered textures" to create the picture
of Link with his equipment or the background behind the Start
Menu. Early emulators and most of the simpler graphics plugins
don't support this technique and instead display some gibberish or all
black. Using a more advanced plugin (we recommend Rice and Jabo)
will make things look normal. If you do see Link or the
background and it looks kinda blotchy, it's because the N64's
resolution is 320x240, so the textures it makes are low in
quality. Since emulators can use higher resolutions, the rest of
the game can look really sharp but the self-rendered textures end up
looking grainy. There's no real way to fix this without changing
the way the plugins work.
