The Debug Menu can take you to various viewers and editors for all the major
features of the game.
As it is in the ROM, none of the options in the debug menu work. The code to
drive the menu seems to be long-gone. My patch replaces the missing logic,
allowing the menu to take you to other options as expected. To do this, I had
to hunt down the code for all the options, which are scattered about the
ROM.
I have done my best to restore full functionality, but
there are two problems with my patch that you should be aware of:
The "Room of Legend" option does nothing. I looked high and low
for whatever this was supposed to connect to, without success. I
speculate that the name is an off-translation of "Hall of Fame".
Several of the options expect a Transfer Pak with an inserted Game
Boy Game Pak in Controller 1. If the expected Paks are not there, you
will be kicked back to the Debug Menu.
The Model Viewer is a full-fledged viewer of Pokemon models. It has a number
of features:
View the model of any Pokemon in the game, including the base 251, plus
all Unown forms, the Substitute doll, the egg, and an extra Pikachu model
(??)
View any animation of a model. There's separate tools to view poly animations
and texture animations (like blinking eyes).
See the memory required for loading any particular model+animation.
View the "Rare" (shiny) color of any Pokemon. Rare
colors are given as a hue/saturation/lightness offsets from regular colors.
Some Pokemon use different textures for their rare versions. (Trivia: the word
"shiny" does not appear in this game at all.)
View a model with silver or gold environment mapping.
View
Smeargle with differently-colored paint on its brush by changing the
"Sub-ID". Smeargle seems to be the only Pokemon that has this sort of
customization.
Set the hue range for a Pokemon. In Pokemon Stadium 2, a Pokemon with a
nickname will have a random hue offset applied to it from within the range
selected here. This is the reason that Pokemon of the same species will
sometimes appear different from each other in this game.
"Check Poke-Buffer", shown in the video above, will run through every
combination of model+animation to figure out the absolute maximum amount
of memory needed to load any one of them.
The Screen Viewer is used for showing the various pre-made screens used
throughout the game. Examples include the Stadium cup select screen and the
many information cards shown in the Classroom. Screens can be viewed in
low-rez and high-rez.
There are a few screens related to the Japan-only Mobile stadium that are
translated into English in the USA version of the game. I believe these are
totally unused.
Note that viewing some screens will freeze the game.
The POKéMON Editor lets you edit the Pokemon on the Game Boy Game Pak attached
to Controller 1. Among the editable fields are:
GBID: This is the ID number of this particular savegame. When a player
starts a new game in the Pokemon Game Boy games, they enter their name, and
the game generates a random ID in the range 0 - 65536. This combination of
name and ID is recorded into each Pokemon that is caught. This allows
the game to determine whether a particular Pokemon was originally caught by
the player, or traded from someone else.
POKE: This lets you change a Pokemon's species (i.e. Dex number). For
example, you can change a Pikachu into an Eeevee.
Item: The item held by a Pokemon. In particular, you can use this to
acquire the highly coveted item "GS Ball", which was only distributed briefly
in Japan.
Moves: Any move can be given to any Pokemon, regardless of whether that
Pokemon could legally learn the move. Illegal moves are indicated in red
text.
ID: This is the ID of the trainer who caught the pokemon.
Name: This is the Pokemon's nickname. If no nickname was given to the
Pokemon by the player, then this will contain
"Friend", which is the friendliness of a Pokemon
Level and all stats can be tweaked directly
"Random", which is a 16-bit value that contains a Pokemon's IVs I think?
There is a minor bug in this tool. A move will appear in red if the
Pokemon cannot normally know that move. However, it flags the Dizzy Punch on
my Elekid in red. However, Elekid CAN legitimately learn Dizzy Punch if it is
hatched from the Odd Egg.
I think this is supposed to be the Backup Editor. It lets you toggle all the
unlockables in the game, such as whether a certain cup has been beaten, or if
the GB emulator speed boosts were won.
The "Mobile Stadium Appears" toggle is
a left-over from the Japanese version of the game: in the Japanese version,
the Mobile Stadium option will unlock once a Pokemon Crystal cartridge is
inserted that has interacted with a GB Mobile Adapter. In the international
versions, there is no way to make the Mobile Stadium menu option appear, and
toggling this setting has no effect (although the setting is saved).
Pokemon icons are used as UI elements in many parts of Pokemon Stadium 2. This
fragment lets you modify them.
Icons are stored in the ROM in two ways: first, as a set of coordinates used
to position a Pokemon model inside a frame, and second, as a pre-rendered
image. This tool lets you both change the coordinates, and re-render the
images.
This is one of only two debug fragments that was not translated into English.
I have shown a screenshot of both the USA and Japanese versions for
comparison.
The AI Editor can tweak the many AI opponent profiles used in the game. For
example, a profile can be made to not exploit a Pokemon type advantage, or to
want to use items more often.
The GB SRAM Editor is a hex editor that operates on the SRAM of the Game Boy
game pak attached to Controller 1. It works just like any common hex editor,
with one difference: the text on the right side uses the peculiar character
set of the Game Boy Pokemon games, rather than ASCII.
This is similar to the 'PokeMon Editor' above, except that it lets you
change the Pokemon contained in registered sets that are stored on the
Pokemon Stadium 2 cartridge.
I'm not too sure about this one. It seems to create some sort of battle record
and save it to the GB game pak in Controller 1. In my testing, it only worked
if that game pak was Pokemon Crystal. More research is needed!
This tool lets you view any battle or trainer message in the game. It can also
cycle through all battle or trainer messages. Unknown what "checks" it
performs on the messages.
The Clock Editor lets you set the clock of the Pokemon Gold, Silver, or
Crystal game connected to Controller 1. These games have a real-time clock.
Normally, the clock can be set only once when the game is first started, and
never changed again, to prevent the player from time travelling. The Clock
Editor bypasses this limitation to let you directly set the clock.
The "Break the clock" option will set the clock state to something invalid.
If the Game Boy game is started while the clock is broken, it will detect this
case and allow the player to reset the clock.
The Item Editor is not a full-fledged editor. Instead, it fills the Color and
Metal Cases (item storage areas) with items.
Notes
Pokemon Stadium 2 is a 64 MB ROM image. As typical for N64 games, there's no
filesystem and no obvious structure on the inside. We know that the initial
program is going to start roughly at the beginning of the ROM, and be at most
one megabyte in size; any more than that, and an intermediate bootloader would
be necessary.
On bootup, the N64 will copy the first megabyte of ROM (after the header) into
RAM and execute it. So, we at least know where the entry point is. We'll have
to dig into it with IDA later. But first, let's look for any clues to the ROM
structure.
In a typical (sane) computer system, you'll have some sort of filesystem that
lets you find individual chunks of data. You might find a directory called
"graphics", and if you're not interested in graphical stuff, we can skip
looking through all the files in that directory. On N64 we're not so lucky:
most games have no filesystem (although there are a small number of
exceptions). Instead, during the build process of an N64 game, the raw address
of all assets in the game are available at link time. Game code always knows
where a needed asset is in ROM without looking up its location in a
filesystem.
We need to find structure. Let's get digging.
First attempt: binwalk
Binwalk is a great tool for looking at firmware images, but when it comes to
video games, it's basically useless. Let's try it anyway.
$ binwalk np3e0.z64
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
663884 0xA214C Gameboy ROM,,[SGB], [ROM+MBC1+RAM+BATT], ROM: 256Kbit
2906713 0x2C5A59 Certificate in DER format (x509 v3), header length: 4, sequence length: 19587
19554941 0x12A627D StuffIt Deluxe Segment (data): fgpD3#
22647968 0x15994A0 Gameboy ROM,, [ROM ONLY], ROM: 256Kbit
22648304 0x15995F0 Gameboy ROM,, [ROM ONLY], ROM: 256Kbit
22649118 0x159991E MySQL MISAM index file Version 7
22738337 0x15AF5A1 MySQL MISAM index file Version 11
22739735 0x15AFB17 MySQL MISAM index file Version 9
22742911 0x15B077F MySQL MISAM index file Version 7
26992350 0x19BDEDE Certificate in DER format (x509 v3), header length: 4, sequence length: 9968
30877890 0x1D728C2 TROC filesystem, 1398099785 file entries
31021156 0x1D95864 LANCOM OEM file
31315505 0x1DDD631 Neighborly text, "neighborhood.>Ha, ha... Here's #26!"
31340945 0x1DE3991 Neighborly text, "neighborhood.>Ha, ha... Here's #26!"
31503361 0x1E0B401 Neighborly text, "neighborhood.>Ha, ha... Here's #26!"
31528721 0x1E11711 Neighborly text, "neighborhood.>Ha, ha... Here's #26!"
37472899 0x23BCA83 MySQL MISAM compressed data file Version 3
37482738 0x23BF0F2 MySQL MISAM compressed data file Version 3
37483991 0x23BF5D7 MySQL MISAM compressed data file Version 3
37490213 0x23C0E25 MySQL MISAM compressed data file Version 3
37502327 0x23C3D77 MySQL MISAM compressed data file Version 3
37502508 0x23C3E2C MySQL MISAM index file Version 1
37597623 0x23DB1B7 MySQL MISAM compressed data file Version 3
38399368 0x249ED88 MySQL MISAM compressed data file Version 7
38483462 0x24B3606 MySQL MISAM index file Version 1
38658728 0x24DE2A8 Unix path: /01/CGB-BXTJ/exchange/index.txt
38737416 0x24F1608 MySQL MISAM index file Version 3
39120016 0x254EC90 MySQL ISAM index file Version 5
46057099 0x2BEC68B Unix path: /E/5/0o5/5/e/
47451318 0x2D40CB6 MySQL ISAM compressed data file Version 11
This is overall pretty hopeless. Let's go over the results:
Gameboy ROM: There's three of these listed. This is a
misdetection: PS2 contains three copies of the Gameboy-style Nintendo logo,
which is also required to be in every Gameboy ROM. A quick check with a hex
editor indicated that these are not Gameboy ROMs. They are definitely
Gameboy-related, though.
Neighborly text: Text spoken by some trainers. Interestingly,
they are all bunched up together. Checking in a hex editor, it looks like tons
of text (possibly all of it) is located around here.
Unix paths: The path
/01/CGB-BXTJ/exchange/index.txt
is certainly interesting! "CGB-BXTJ"
is probably a reference to the Japanese version of Pokemon Crystal, which has
a product code of BXTJ. Unfortunately, there's not much more to see around
here.
The rest: Obvious misdetected garbage.
Binwalk was a waste of time, as expected. Moving on...
Second attempt: strings
The 'strings' program will walk a file and find any printable strings over a
certain length. If we're lucky, we'll be able to find some landmarks in our
ROM. The full output of 'strings' is enormous, but I'll point out some useful
bits that I found.
We start off with the game name and product code, which are part of the ROM
header:
There's some text for displaying the contents of registers. This same text is
found in many of Nintendo's N64 games, and is typically used when the game
crashes:
A search through the strings output shows many more instances of "FRAGMENT":
$ strings -tx np3e0.z64 | grep FRAGMENT | head
a8a88 FRAGMENT
ad268 FRAGMENT
adca8 FRAGMENT
ae5e8 FRAGMENT
b4d98 FRAGMENT
b5da8 FRAGMENT
ba238 FRAGMENT
cc6b8 FRAGMENT
d0488 FRAGMENT
d4c38 FRAGMENT
[...]
In total, strings found 762 instances of "FRAGMENT" in the ROM.
Most of them are found at addresses that end with -8, such as the first match,
a8a88. Looks interesting! Let's take a closer look.
I came to the conclusion that these fragments are code modules. Each fragment
carries a main function and relocation information. Fragments are structured
like so:
struct fragment_s {
uint32_t ep1, ep2; // MIPS instructions to jump to the main function,// typically something like "j 0x8xx00020; nop"uint32_t magic1; // "FRAG"uint32_t magic2; // "MENT"uint32_t entrypoint; // typically 0x20uint32_t relocations_offset;
uint32_t size_in_rom;
uint32_t size_in_ram;
char data[];
};
Using the above struct, we can decode the fragment header:
The entrypoint in this example is 0x83500000. This address is
not used in the N64 memory map. It turns out that each fragment is pre-linked
to a bogus base address like this one. When a fragment is loaded, all address
references are change to point to its new location in RAM.
There's another interesting thing about this entrypoint. Each code fragment is
given a unique fragment number. This number is used to derive the base address.
The formula is:
