About the Game Engine

A superb game, one of Nintendo's very first 3D games for their Nintendo 64 console, was apparently created at the same time as The Legend of Zelda: Ocarina of Time, which supposedly runs on a (heavily) modified Super Mario 64 game engine (as did later N64 games by Nintendo). This game showed that Mario worked well in 3D and did away with a lot of the linear limitations of most other games at the time.

In any level (Bob-omb Battlefield, Wet dry world, outside or inside the castle, etc) the game can handle a maximum of 240 objects. An object can be visible such as Mario or a box, or it may lack graphics and be used 'behind the scenes' such as an activator object (as to activate a 1-up when you climb a tree, for example).

Whenever you enter a level there will be a minimum number of objects set up including, of course, Mario. These objects will occupy a number of the available 240 'slots' leaving many more slots for objects that are added on the fly as the game is played. For example, if you stomp a Goomba or break open certain boxes coins will be added; they will use some of the previously unused slots. The game will crash if all the slots are used up, but normally that isn't a problem, but by using various codes that increase how many objects are spawned the game can slow down or even crash.

Every object uses 608 bytes for its 'object structure' but this does not include additional memory that the object may need, such as graphics data. These 240 object structures are doubly linked lists; each structure points to both the next and previous slot (the game was most likely programmed in either C or C++).

An object structure is fundamental for an object's existence in the game world, it contains data that determines how the object looks, how it behaves and also remembers what it's currently doing (example, an object's world position variable stores its position in 3D space). By modifying the object structures it's possible to force objects to behave how they wouldn't normally, within limits. Leaving a level and re-entering it, however, will reset your changes unless you have codes set up (as opposed to just using a memory editor such as the Equalizer cartridge provides).

Animation

For the time, the animation featured in Super Mario 64 wasn't half bad, but have you ever wondered how the objects are brought to life? Examples of objects that are animated in this game are Mario, Goombas, Bowser and even the flags on top of the castle. If the object is animated, in its object structure, it will have a pointer to its animation data. This data for one thing, determines how many frames are in the animation and if the animation is played once or repeated. For example, the castle flags are continually animated as they seemingly blow in the wind.

In the animated object's structure is a frame counter which starts at zero for the first frame and then stops at one less than the total number of frames. If the animation is set to repeat it will start at zero again and count up.

For every frame an object can perform one or more transformations, such as translation or rotation. The object as a whole could be affected or individual parts such as arms or legs; it is generally easier to rotate limbs than to translate them. Each value uses two bytes and is an integer, this means that less precise control over the characters that would be possible with floating-point data, yet f/p values would take up more bytes.

Using Peach's animation as an example, she can be moved and rotated, and her dress (the skirt part), her hair, her arms and her earrings can be rotated to pose her. Peach has no legs, just like Zelda in Ocarina of Time, since her dress covers where her legs would be and her dress isn't flexible enough to expose them even if she had any legs.

Beta

Beta Animations

Probably the most famous beta graphic in this game that was never removed was the Blarrg and I was fortunate enough to find it in Lethal Lava Land, Wing Mario over the Rainbow and Bowser in the Fire sea. There are very few animations in the lava filled level and I knew where the two bully animations were; the Blarrg's animation of him jumping up and opening his mouth was after the bully animations.

Now I knew the values used for Blarrg's animation it wasn't too difficult to find that same animation in Bowser in the Fire sea and Wing Mario over the Rainbow, by searching for the values that belong to the animation data.

Behaviours

Although a few variables in an object structure determine how an object behaves (e.g., if it can be climbed like a tree) it is the behaviour scripts that really make an object come to life. The behaviour scripts are a list of instructions that place certain values in the object's variables and also calls functions that do a lot of the hard work.

These behaviour scripts, along with the graphic ID (with the exception of some behaviours that do not require a graphic ID) are used to create an object. They are also the values to be used with my spawn code. These values remain the same between the different versions of the game since they are used to calculate the actual addresses of the data needed for spawning objects.

Behind the Scenes

Colours

Colourful Text

The colourful text such as the number or lives remaining or 'PAUSE' that is displayed when you...um...pause the game uses a simple approach to handling the individual characters of a string, which has advantages over ASCII, namely that 0-9 and A-F are in ascending order which is handy for when outputting numbers.

First, here are the values you'll need (in hex) to create your own colourful strings when the ASCII standard isn't used. Take note that some characters are missing for some strange reason (surely not much space was saved by leaving them out):

Here are some addresses of more English strings (foreign strings follow the English ones):

        0x802FDA10 COURSE
        0X802FDA28 MY SCORE
        0X802FDAE0 CONTINUE

To find other strings, take two adjacent characters on even boundaries (the first two characters are ideal, like 'PA' for PAUSE), convert to the hex values (0x19 and 0x0A for 'PA') and convert to decimal to use in the 16-bit search (if need be). Once you've found a possible address you'll know if it's the string by looking at the values that follow and by modifying them.

The level select uses the colourful text even though there's the problem of the few missing letters coupled with the strange names makes reading them difficult. It's weird since the level select names are actually stored in the RAM in ASCII so why not display them correctly by using the normal text?

0x2A cross (used for lives for example)
0x2B coin symbol
0x2C Mario head symbol
0x2D star symbol
0x2F Ü (no Ü in NTSC game. Key symbol for Japanese versions.)
0x30 0
0x31 1
0x32 2
0x33 3
0x34 4
0x35 5
0x36 6
0x37 7
0x38 8
0x39 9
0x41 A
0x42 B
0x43 C
0x44 D
0x45 E
0x46 F
0x47 G
0x48 H
0x49 I
0x4A (should be J but glitched up)
0x4B K
0x4C L
0x4D M
0x4E N
0x4F O
0x50 P
0x51 (should be Q but glitched up)
0x52 R
0x53 S
0x54 T
0x55 U
0x56 V (no V in NTSC game)
0x57 W
0x58 (should be X but glitched up)
0x59 Y
0x5A Z (no Z in NTSC game)
0x61 to 0x7A are A-Z (would be a-z in normal ASCII)

Other values will result in blank or glitched up characters. It can be seen that the PAL game has more colourful characters than the NTSC game as the PAL version supports English, French and German languages. Starting at address 0x80305C98 in the RAM for the PAL game are the strings TIME, TEMPS and ZEIT which is Time in English (d'oh!), French and German.

Create your own codes

Debug

 

Debug Display 2 (added: 5/9/8)

 

I've found a second debug dislay that is much better than the first; since finding it in the PAL version I have also activated it in the USA NTSC game and both Japanese versions. Like with the other debug display it is enabled by setting a flag (PAL 8030AE93 NTSC 8033D263). But, there is also another variable used (PAL 802FD054 NTSC 80330E94) to select 1 of 6 different debug displays on the left of the screen (using values 0 to 5), with the object number (don't forget the J colourful character is missing in non-Japanese versions) displayed most of the time.

 

 

What's so interesting about this second debug display is not only does it serve as a better form of debug, unlike the first debug display it is only shown when Mario is updated as it is actually part of the Mario behaviour and that is how I found it. You can have this debug display on at the same time as the first one (see Debug Display 1), although in some levels more information is shown at the right of the screen for this second debug so that would get in the way of the first debug display.

 

 

Please note that some of the values are in decimal, others are in hex. We need to work out what a lot of the debug data means, the most obvious of which is the OBJ value, most likely reffering to the object that is currently being updated, and is usually the Mario object.

 

In the NTSC and Japanese versions there is extra information shown when the MAPINFO data is being displayed. Since the Japanese SM64 has all the colourful characters the debug display appears as was intended but for all other versions, especially the NTSC game, the debug is harder to read.

 

 

A couple of NTSC screens of the debug display can be seen above, this is what is shown:

MAPINFO
AREA
WX
WY
WZ
BGY
ANGY
BGCODE
BGSTATUS
BGAREA
DPRINT OVER

The second debug display is shown below, from the original Japanese version, and appears the same as it does in the Japanese Shindou edition.

 

The DPRINT is possibly the debug function used to display the colourful text on the screen and is a typical C language function.

 

MD, SP and FG appear in some levels, the MD could be mode and relates to what a Chuk-ya is doing and SP is its speed. FG doesn't seem to change, is different in each regional version, and is such a large value that it doesn't all fit on the screen (the numbers overlap at the right of the screen). SInce MD, SP and FG all appear together when in a course that has a Chuk-ya and they vanish when you defeat the Chuk-ya, the three values must all be to do with the Chuk-ya.

If you spawn a Chuk-ya (for example, using my spawn code), the MD, SP and FG appear for each Chuk-ya, although there is room on screen only for a few lots of these values. MD, SP and FG will also show up if you spawn a Chuk-ya in levels that don't normally have them, so it must be part of the Chuk-ya behaviour to display those debug values.

 

I have investigated the FG value; first I moved the Chuk-ya related values to the left (which can ony be done by altering the coding) so that the full FG value can be seen. It's a huge value and is in decimal since the M appears at the beginning of the value (i.e. minus) and in memory the FG string is fg %d, the d means decimal.

 

The FG value, when converted to hex is 64-bit and the bottom 32-bits looks like a pointer. By tracing through the game's coding I found that FG is a return address, in other words, is where the game continues when it has finished executing a certain function. So, the FG value may have been used so they know where in memory a part of the program that was causing problems in stored and this value will always stay constant while playing the game (although it will be different for each version of SM64).

 

There does remain a couple of unanswered questions, starting with why 64-bits is needed when 32-bit is the right amount for a pointer address. I do know that there is a bug in the display function that if a hex value is too long (32-bit or more) it will crash the game (a problem I was able to work around with my memory editor code) so they had to show the value in decimal form. Lastly, FG may possible stand for something like Function Goto, but I could be wrong.

 

It seems very likely that ANGY is Mario's Y angle, that is, his Y rotation so you'll see the value change as Mario turns around. WX, WY, and WZ must be Mario's world position.

 

When in the castle, Big Boo's Haunt, or Hazy Maze Cave and the second debug display is usually showing only the object number, AREAINFO appears, the value of which changes as you open a door and go to different rooms.

 

ACTION and MODE show up when you are in Tall, tall mountain and are to do with what the monkey is doing. If you select the Mystery of the monkey cage star, ACTION and MODE appears two times, the two values for both monkeys.

 

Strangely, when you fight King Bob-omb when the second debug display is active, a zero appears at the right of the screen when he picks up and throws Mario, similar to what a Chuk-ya does.

 

Both EFFECTINFO and ENEMYINFO values don't seem to change, but by altering the variables they display it can be worked out what they are used for. From tests, the B0 of ENEMYINFO is possibly the height of the star from the object that creates it (such as King Bob-omb) yet it is normally zero. Since the value is used by more than one object, it may have been used only for testing and that explains why it is now not used.

When you are in Lethal lava land, and second debug display is usually just showing the object number, NUMBER will also appear, two times at the left of the screen and is to do with the metal cage-like platforms that help you across the lava. This NUMBER value is from offset 0xF8 from the start of the object; so it's likely to do with what the object is currently doing. In theory the function that displays the debug NUMBER could be applied to any object.

WALL is another; like NUMBER, the function that displays the WALL value could be used with any behaviour, however, the game continually stores zero to the WALL variable as to disable it. WALL could possibly be to do with wall collision but as it seems the code no longer exists to update the WALL value, we may never know for sure exactly what it was used for.

There is even more debug text that is in the USA and Japanese versions but not in the PAL SM64. They are BOUND, TOUCH, TAKEOFF, DIVE, S WATER, U WATER, B WATER, SKY and OUT SCOPE. There is a variable when written to will display combinations of the these debug strings along with the value so they may have been used to report what Mario was doing yet the coding to update the variable seems to no longer exist.

NULLBG and a value show up when certain objects are spawned, such as fire, the value seems to be how many of the objects were created in a certain amount of time. BG could possible stand for Behaviour/Graphic and the NULL may be reference to objects that when spawned do not require a graphic ID value (i.e. it is zero), or behaviours that spawn multiple objects with their own, different, behaviour and graphic ID values.

 

Spawn debug mode

 

(Added: 2/10/8)

 

Here's irony for you; I was working on a better version of my spawn code and I needed a way to disable the Mario behaviour so that I could use more buttons on the controller. I checked the Mario behaviour script which has three function calls that are always executed, the first of which helps out with the second debug display and the second updates Mario. When I removed the third function call to see what affect it would have on the game it did nothing which was the case for the second debug display.

 

Looking through the code for the third function call I noticed that it checked the type of (second) debug display and if another flag was set. I satisfied both conditions but nothing happened until I looked at more of the coding-it checked the D-pad. To my surprise and delight pressing D-pad right spawned a normal Koopa shell, D-pad left a bouncing box and D-pad down a Koopa shell you can pick up but only works if you spawn it in the water. D-pad up isn't used and interestingly the spawned objects appear in front of Mario, something that would help me with my own spawn code.

 

So, Nintendo had used a very limited spawn debug mode which not only reveals more of what they used to test SM64 but could also help out with making codes. If you have the second debug display on and the type of display is number 3 (as partly needed to enable the spawn mode) whenever you spawn an item using the D-pad NULLBG appears.

 

Expansion pack memory

(Added: 30/9/8)

 

Although SM64 does not use the 4MB expansion pack it is possible to make use of it which would allow for adding new behaviours, bigger worlds, more objects and other improvments. But due to the way the memory is split into segments loading and using data in the expansion pack memory can be tricky.

 

A simple way to make use of the expansion pack memory is to use Gameshark codes to place values in the extra memory and then patch the game's coding to use the data that has been put into the expansion pack memory. If you're using a real N64 and cheat device like a Gameshark then you will need to find an area of the expansion pack that is not use by the cheat cartridge.

 

I will now explain how I added a new behaviour to the game by making use of the expansion pack memory. The values are for the PAL game but the details can be applied to other versions.

 

If you look at the segment table in the RAM you will notice that a couple of the segment addresses are usually zero, one of which is the address of segment 0x0B. The first thing to do is change the segment 0x0B address to the start of the expansion pack memory:

 

803096F4 00000000 -> 00400000

 

Remember that the 8 at the start of an address is missing in the segment start address table but is added by the game when a segment/offset value is converted to an actual address.

 

Next we put a simple behaviour script at the start of the expansion pack memory:

 

80400000 08000000
80400004 0C000000
80400008 80400100
8040000C 09000000

 

This behaviour script just calls a function at address 0x80400100, which is also put into the expansion pack memory:

 

80400100 lui a0, 0x8031
80400104 lb a1, 0x94DD(a0)      Get the number of lives Mario has
80400108 addiu a1,a1,0x0001    Increase lives
8040010C sb a1, 0x94DD(a0)     Update lives
80400110 lui a0,0x8033

80400114 lw a0, 0xED90(a0)      Get pointer to object
80400118 sh r0, 0x0074(a0)       Remove object
8040011C jr ra

 

The above function increases Mario's lives by one.

 

Lastly, change the preset behaviour of the signposts to use the new behaviour script that's in the expansion pack, which is now segment 0x0B:

 

802FDE38 130032E0 -> 0B000000

 

Now, every time you go into a level that has signposts Mario's lives will increase by how many signposts there are. Note that the signposts won't be visible since even if the new behaviour didn't remove them there is no initilization that the signposts would normally use.

 

All objects in all levels

 

(Added: 5/10/8)

 

A big limitation with SM64 is that only common graphics can be used in all levels including Mario, coins and stars. By making use of the expansion pack it would be possible to have objects such as Peach and Yoshi in all levels. I have done a test using Nemu and a save state which now contains Peach and other objects that can be used in every course.

 

 

Using Nemu I set up breakpoints (so that the game stopped at certain times) during the loading of the castle graphics and then changed various values so that the whole of segment 5 was loaded into the expansion pack memory. Segment 5 contains amongst other things, Peach's graphics and animation but not the graphic structure so I had to then get the game to load that also into the expansion pack.

 

The problem is that for the graphics to be used that's in the expansion pack the start address of segment 5 has to be changed otherwise it would try to use the data that's only loaded in the castle grounds. This means having to change the sement 5 start address whenever you enter or exit a course.

 

FAQ

(Updated: 4/11/8)

 

Note: this FAQ should be helpful for other games as well, not just SM64.

 

Q. What exactly do codes do?

A. The most common type of codes simply place a certain value in the memory (RAM) where the game stores variables such as lives, health, etc. For example, you loose a life so the game subtracts one from Mario's lives and then stores the result in memory. But a code can then puts back a different value so that Mario always has a fixed number of lives.

 

Q. What is the difference between Action Replay and Gameshark codes?

A. They both use the same type of codes as does xplorer64 and Equalizer (which is based on the Action replay). I often use the term Gameshark when talking about codes since Gameshark seems to be the most recognised cheat device.

 

Q. Can a code harm my game?

A. No, the worse a code can do is wipe a save file and that's quite unlikely. The only definite way to damage a game cartridge is to remove or put the cartridge into the N64 while the power is on (which is why I advise against so-called cartridge tilting).

 

Q. Will a code from one region or version work on another?

A. Not normally, just as a code for a game won't do the same thing on another game. As well as the regional differences, often there are different versions for the same region (such as Mario Kart 64 and The legend of Zelda: Ocarina of time).

 

Q. Can a code be converted for use on another region or version?

A. Often yes, by adding or subtracting the difference between the address part of the code (the left hand side). However, for some codes this will not work so you'll need to use a different approach such as using a memory editor.

 

Q. Cam you make a code to do xxxxxx?

A. Although what you can do with a code is quite limited I never say never; codes I've said I would not be able to do, later I have been able to do as I learn more about how the game works.

 

Q. Is Luigi in SM64?

A. Luigi is NOT in SM64 for the N64 but we can get close through modifications.

 

Q. What beta items/objects are unused but are still in SM64?

A. They are the Yoshi egg, Boo key, key display (only the Japanese versions have the key character), the Blarrg baddy and, the level select and debug although not actually beta.

 

Q. What is an emulator?

A. An emulator attempts to behave like the original game system and usually runs on a computer, and can offer extra features such as for creating codes without the need for a cheat cartridge. Examples of N64 emulators are Nemu64 and Project64 but there are many more.

 

Because an emulator may not exactly display a game as it would on the real game system, certain cheats may behave differently on the emulator than on the original hardware. Advantages of emulators are that the quality can actually be better than the original system that's being emulated and you can easily take screenshots.

 

Q. What is a ROM?

A. When we are talking about an emulator, a ROM is the copy of the game cartridge, CD, DVD, etc as a software file, to be loaded by an emulator. The general rule is they you are only allowed to download a ROM if you own the original game on cartidge or CD, etc.

 

ROM is short for Read Only Memory and is any type of memory that cannot be changed after it is created (so game ROMs that are software files aren't really ROMs).

 

Q. I've just entered a long code, why doesn't it work?
A. Some cheat cartridges and emulators don't like long codes, so if you've checked that you entered every digit of the code correctly, try splitting the code in half and turning on both halves as if they were a single code.

 

Q. Does a code have to be entered exactly?
A. Yes, although if you do make a mistake when typing a code, by chance you may discover another cheat.

 

Q. When I use certain code combinations, nothing happens or not as expected. Why?
A. Some codes can conflict with each other and having too many codes on at the same time can cause problems or even crash the game. Try turning on less codes or different combinations. A few of my codes won't work if used together since they use the same memory.

 

Q. I've activated a code but it does nothing, what am I doing wrong?
A. If you've checked that you entered the code correctly it may be that it uses an activator. This requires you to press a certain button or combination of buttons to trigger the cheat.

 

Q. Why do some codes say that they must be activated before the title screen appears?
A. This is usually only necessary with emulators, which cache (backup) the game's coding that the cheat modifies. If the emulator caches the game's coding before the cheat has altered it the emulator will use the unmodified coding and so the cheat will have no affect. I have found with SM64 that any codes that alter the game's coding should be turned on as soon as possible, at the latest at the file select screen.

 

Functions

(Added: 17/10/8)

 

Please go to SM64 Exposed ASM Functions.

Graphics

(Update: 27/9/8)

The objects in Super Mario 64 can look very simple such as the trees and the coins, or they can have a complicated 3D apperance such as Mario. Nintendo used numerous tricks to make sure that the game ran smoothly; many of the objects are 2D like the trees, coins, 1-up mushrooms and so on but always face the camera to appear more 3D (known as billboarding). The coins do not actually rotate but appear to by cycling through several pre-rendered frames (textures) of the coin at different angles.

The Mario graphic is without doubt the most complicated, although Bowser is not far away. Of course normally only one object has the Mario graphic (two when mirror Mario is visible), but if too many objects were to use the Mario graphic the game would crash.

What has always puzzled me although nothing major is why the programmers went to the trouble of having coins and other objects with and without shadows. Did Nintendo really go to so much trouble to not have shadows except where absolutely necessary such as for objects that move (an e.g. is that the only boxes to have shadows are those that jump and can move). Fortunately having a graphic without a shadow is simply a matter of bypassing the shadow value in the graphic structure.

The graphic structure is what I call the values that describe what an object looks like including such information as its starting size (a single value for X, Y and Z; the size modifiers in any object that uses a graphic can then adjust the graphic's size even more and in each of the three directions). Also, the graphic structures have details about the type of shadow (if any) and how the (if any) sub parts of the graphic are positioned accordingly like the head, torso, legs, arms, and so on.

Although nothing new where 3D graphics are concerned, you may be surprised that the graphic structures can contain pointers to functions to use that typically would adjust a graphic in some way. For example, part of the coin behaviour updates a variable in the coin object to remember what coin animation frame (texture) to use. The function call in the coin graphic structure then copies the coin object frame variable to the coin graphic structure as a temporary variable (a pointer to each object that use the graphic is also copied to the graphic structure).

Something I've wanted to do for ages but I didn't know if it was possible is to use scenery graphics for objects like Mario, coins, doors, etc. As can be seen when using my Attack of the big Goomba castles I changed the signposts to look like the castle and surrounding area and then used the (big) Goomba behaviour.

For most of the levels the scenery graphics are actually objects but with other courses including inside and outside the castle, and Bob-omb battlefield the scenery is nothing to do with the objects (i.e., it cannot move or be sized like the objects). Since the graphic structures used by the objects contain segment/offset values for what graphics to use, these values can be changed to use scenery graphics (but remember that the scenery graphics will only be loaded for the one level).

Changing the signposts to look like the castle worked well since the signposts are made up of two parts; the post and the actual sign. So I swapped the sign part with the castle graphics and the post part with the grass and hills area. The signposts still use the signpost graphic structure but that has been modified to use different graphics for the post and sign parts.

The levels are made up of several layers, for example, outside the castle the castle is one layer, the surrounding area is another. Then there are the fences, tree shadows, castle windows and castle door way as more layers-and let's not forget the castle tower but that is an object.

Most likely the reason for splitting up the level scenery graphics is so it's more manageable and let's not forget the objects also are made up of many parts like the signposts. But for some objects such as Mario who is animated he has to be made up of lots of parts (Head, torso, legs, and so on) so they can be moved independently of each other.

Graphics Pointer Values

Please go to SM64 Exposed Graphic Values. 

How many stars?

Super Mario 64 reinvented the Mario universe and introduced the concept of earning stars to progress in the game. But just how many stars had Nintendo originally intend for the player to collect? The DS remake features a lot more stars, though some were dropped from the N64 version.

65535 stars?

Address 803094DA in the PAL version stores the current amount of stars obtained. What's strange is that this value is unsigned, 16-bit, meaning a maximum star total of 65535. This is an unrealistic amount, however, though 16-bits would be needed for stars above 255, which is much more likely. This cannot be used as hard evidence, because the programmers might just of got lazy and forgot to make the variable 8-bit (i.e. 0 to 255).

No more than 99 stars?

This is probably overlooked by most people but even though you can obtain more than 99 stars, the display misses out the 'x' after the star symbol and before the amount, instead of shifting the star total right one space to avoid overwritting the 'x'.

Further proof: the amount of stars stored in RAM is then converted to text form for the colourful text, which is the number of digits followed by the codes for the numbers (see above). For the PAL game, If the star total has 1 or 2 digits it's stored at address 0x8005C185 but for 3-5 digits the text is at address 0x8005C141. Did Nintendo suddenly realise that they could do 100 or more stars and had to use 2 addresses?

How my codes work

For this hack I created a new behaviour which allows you to move an object using the D-pad and is quite simple, however, it requires many codes. A problem I did encounter was how to force the game to execute my code that would work both on a real N64 and an emulator. The solution was to change the function call address in the tree behaviour script to my program and this can be done with other objects.

Have a look at the PAL coding I created for the remote control:

3C098033 LUI T1,0X8033
8D29ED90 LW T1,0X8032ED90 Get pointer to object
C52000A0 LWC1 F0,0X00A0(T1) Get object X position
C52600A4 LWC1 F6,0X00A4(T1) Get object Y position
C52400A8 LWC1 F4,0X00A8(T1) Get object Z position
3C084200 LUI TO,0X4200  How fast to move object
44881000 MTC1 T0,F2
3C0A8031 LUI T2,0X8031
814A9260 LB T2 0X80309260 Get 1P D-pad state
24080001 LI T0,0X00000001
1148000D BEQ T2,T0,DPAD_RIGHT
24080002 LI TO,0X00000002
1148000A BEQ T2,T0,DPAD_LEFT
24080008 LI T0,0X00000008
1148000C BEQ T2,T0,DPAD_UP
24080004 LI T0,0X00000004
1148000B BEQ T2,T0,DPAD_DOWN
24080006 LI T0,0X00000006
1148000C BEQ T2,TO,DPAD_LEFT-DOWN
24080009 LI TO,0X00000009
1148000B BEQ T2,T0,DPAD_RIGHT-UP
00000000 NOP
03E00008 JR RA
46001087 NEG.S F2,F2 DPAD_LEFT
46020000 ADD.S F0,F0,F2 DPAD_RIGHT
E52000A0 SWC1 F0,0X00A0(T1) Update object X position
03E00008 JR RA
46001087 NEG.S F2,F2 DPAD_UP
46022100 ADD.S F4,F4,F2 DPAD_DOWN
E52400A8 SWC1 F4,0X00A8(T1) Update object Z position
03E00008 JR RA
46001087 NEG.S F2,F2 DPAD_LEFT-DOWN
46023180 ADD.S F6,F6,F2 DPAD_RIGHT-UP
E52600A4 SWC1 F6,0X00A4(T1) Update object Y position
03E00008 JR RA

Put simply, the behaviour checks the D-pad and then updates the object's position if a direction button was pressed. I also sneakily only used add instructions but negated (made negative) the value to add when needing to subtract.

Sparkling and invincible Mario (update: 16/6/8)

I had a request so that Mario always sparkles and had tried to trigger such an effect but at the time I could not do such a thing. But now I have been swapping Mario's first 0x0C behaviour call in his behaviour script with other objects' behaviour calls I found that the Koopa shell behaviour call causes Mario to constantly sparkle since the game is none the wiser. Unfortunately this is just a side effect since using the Koopa shell behaviour call for Mario does not do anything else, so no walking on water for example.

As nice as it was to see Mario looking more super than usual I thought about adding to the code, such as to make him invincible. After studing the neon code that makes Mario flicker I realised that it was actually a timer used by the game after Mario is hit by a bad guy during which time he can not be hurt by enemies.

Let's look at, for the PAL game, how the code updates the invincible flag (assuming that Mario is currently flickering) depending on the timer and then I'll show you how I patched it to make sure that no baddies can do him damage.

First the game gets the value of the flicker timer:
8024A314 lh v0, 0x0026(a0)    'v0=(80309456)

Next the code updates the register t8 depending on if the flicker value is less than zero or not:
8024A318 sltu t8, r0, v0    't8=1

The contents of register t8 is transferred to register v0:
8024A31C or v0, t8, r0    'v0=t8=1

And to finish off the invincible flag is written to with the value of register v0:
8024A320 sh v0, 0x9532(at)    '(80309530)=1

Basically, the above coding sets the invincible flag if the flicker timer value is higher than zero or clears it if it's zero. You might think that I could have just used a code to force the invincible flag to always be set (equal one) but that is not possible due to the game's coding constantly changing it. The solution was to change the sltu instruction so that the result is always one:

8024A318 slti t8, r0, 0x0001

Anyone still awake at this point may realize that the just mentioned alternation seems pointless since we know that zero will always be less than one but that's exactly as was needed to force the invincible flag to always be set.

How Bullet Bill works (update: 3/06/08)

Most Mario fans will recall many Bullet Bills fired at Mario from many directions but in Super Mario 64 there is only one Bullet Bill blaster near where the tower is located in Whomp's fortress. I assumed that the blaster spawned a Bullet Bill whenever Mario neared it but I couldn't find the code that did such a thing. Have a look at this screen capture:

(pic to be added)

Item box

Memory Map

Multiplayer

Nintendo's Tricks

Nintendo made sure to save as much memory as possible and keep the game running smoothly by using polygons only were necessary. Examples are the fact that Peach has no legs (her dress hides that area) and the pendulum in the clock in the castle has no back to it since you never normally see that side.

As well as that, any hidden polygons of non transparent objects like Mario, are removed. This can be shown by removing polygons of an object facing the camera and you will see right through the object; you won't see the back polygons.

 

The Rooms of Darkness

Nintendo used many tricks to lower the amount of memory and CPU time that Super Mario 64 needed to work, one of which can be seen in the castle. Any room you're not in is put into darkness by the game (think of it as something switching out the lights when Mario leaves a room) though you can't normally see that happening. This is done because anything black doesn't need to be drawn, thus lowering the number of polygons that need to be rendered. This was actually a common trick used in 3D games, hence why so many video games were set in buildings.

One way to see the rooms put into darkness is to turn off a door's graphics or just move it out of the way (it's fun walking through a door that doesn't lead to anywhere). The 'lights' will still be activated as you approach a room but before then you will see a room of darkness.

The above picture shows the door that leads into the mirror room is missing, or appears to be, by turning off its graphics. This shows that the room has been put in darkness so it doesn't need to be drawn, it's not enough just to hide it with the door, since sprite and scenery graphics are handled differently.

There's something strange about Lakitu's cloud, for one thing it's a separate object to the actual cameraman. The white object against the black is Lakitu's cloud (which is still animated) yet Lakitu himself doesn't appear until the 'lights' are turned on.

Normal Text

Note: Arrow Up, Down, Left and Right are the actual graphical symboles used to represent the N64 controller's camera buttons. The A, B, C, Z and R refer to the controller's buttons and are bigger than the normal letters.

Save Files

Screen Special effects

(Added: 19/11/8)

Moving and sizing the screen

In the ending cut-scene there is a border at the top and bottom of the screen and in the end credits the screen appears to move and change size. There is a special function that allows the screen to be moved and its sized to be changed, although it doesn't actually affect the screen, more of a window on the world. So, if you were to make the screen smaller, or move it, you would see less of the game world.

The function uses several input values, one of which appears to be a pointer to where certain screen values are stored to set its size, position and other attributes. Note that the function must be called every frame otherwise the screen will return to its normal size.

When the screen is in the window mode, the area of the screen that is not showing the game world, that is the border, can be any colour you want. In the end movie and credits it is black, most likely to hide the fact that the text characters are on a black background that would show up if the border colour was not black. That and the tradition of having black borders in movie sequences.

The function that allows you to set the screen attributes requires that you specify the colour of the unused area of the screen when using window mode, as RGB. The red and green colour amount are placed into two seprate registers but the blue colour amount strangely has to be put on the stack before calling the function, although that may be due to how Nintendo's compiler converted from C to machine code. The colour values are then combined by the function and stored to memory.

There is an extra value to be passed to the function, one with a bit of mystery about it. In the NTSC game the value is stored to memory but in the PAL version it is never used by the function suggesting that it is an unused feature. Also, elsehwere in the game's code this unknown feature is disabled by writing zero to it, however, if the code is patched you can write to the variable without the game changing it. But, placing any value other than zero there seriously messes up the screen display, either showing darkness or zoming in greatly on the game world is a strange way.

Below is a screenshot of a code of mine that makes uses of the window mode, and also changes how red the border is depending on how much health Mario has (i.e. bright red for full health down to dark red for no health). This picture is from the PAL game running on Project64, but it works on a real N64 as well.

Unfortunately, the NTSC game has a black border at the top and bottom of the screen that's fixed and unaffected by the window mode.

Secrets of the Camera

Sound and music

Size modifiers

The coding

The Level Select

What did Nintendo forget to take out of SM64 but is actually a good thing-the level select and it's even in the PAL version. It can be activated using a code; pressing start at the title screen you can choose what level you want to go to including the ending. As for the enemy levels you can't select what star you want to do (though that isn't usually a problem), and if you exit a course you return to the level select at the title screen.

 

 

Above you can see on the left the PAL level select which has the missing colourful % character which is in the Japanese game as seen on the right. Note that the level select has the title of just 'SUPER MARIO' maybe as it was programmed early on and the final name was not decided then.

The analogue stick doesn't work with the level select, instead use the D-PAD:

D-Pad Up: select previous level.

D-Pad Down: select next level.

D-Pad Left: Select the level 10 levels before current one.

D-Pad Right: Select the level 10 levels after current one.

Stranely, some of the names are difficult to relate to the actual levels, others fairly obvious such as 'kuppa1' for the first Bowser fight (i.e. Koopa 1 since King Koopa is what Bowser is known as in Japan). There are a few glitched up letters due to some of the colourful characters not existing which also doesn't help in selecting the right level (but all the colourful characters are in the Japanese version). The blank names were perhaps where more levels were to be added; if selected you are returned to the title screen.

The MIPS Processor

The Mystery of The Mirror Room

Nowadays, realistic reflections are nothing to get excited about but in the 'olden days' reflections were created by using actual 3D space. That is, beyond the mirror in Super Mario 64 in the castle is valid 3D space that you can explore. The N64 is actually capable of reflections mapped onto the surface of a polygon but there are several reasons why Nintendo used a simpler way of creating the reflections:

1. It was easier at the time, especially as SM64 was an early N64 game.
2. Some things (such as paintings) musn't be reflected, so a surface reflection wouldn't work because it would (presumably) reflect everything.
3. Because Nintendo originally planned for Mario to go into the mirror world, if the DS remake is anything to go by (where you get a star).

Nevertheless, there is a certain strangness about the mirror world. To get past the mirror, you can move a door between the mirror or just alter Mario's position using a code. As can be seen in the picture below, the real Mario is on the right in the 'mirror' world where Lakitu appears as just a cloud.

 

                                 

 

There is very little collision (most likely because Mirror Mario who's now on the other side would just copy the real Mario) and you can return to the real world simply by walking through the mirror. Also, you can't get to the reflected door (if moved up it functions as a door that you just walk through), you can go through some of the walls, and in the mirror Lakitu appears only as a cloud, probably because there is only one Lakitu ever seen.

Other information is that the mirror's only shiny on the real side and there is a black area beyond one of the mirror walls that could possibly have been used for the DS version star room.

Interesting, any change in Mario's graphics are mirrored perfectly which suggests to me that another playable character was likely for the original Super Mario 64, as in the DS version adds three playable characters. You can make Mario look like a door and his mirrored version will copy, and even the cap powers are 'reflected', again this can be seen in the DS version with Luigi or using a code in the N64 version.

The mystery of the Ü-solved!

Mystey solved on 11/9/8-read on to learn more about this beta display.

 

When I first started to try out SM64 codes some while ago there was this 'cheat' that made the Ü character appear at the right of the screen. It was only for the PAL game, the code is 803094DC 000x where x can range from 1 to 6. You may notice that the variable is right next to the Mario's lives variable so it was easy to convert to NTSC: 8033B21C 000x. As you will see in the following screenshots with the PAL version on the left, since there is no colourful Ü in the NTSC game (shown on the right) glitched up characters appear instead.

 

What this means is that the Ü character isn't significant, there was likely to be a different character or symbol to be used instead; the fact that the variable and the associated code is in the NTSC game as well as the PAL game means it's an unused feature. So, there were plans to display up to 6 of the same symbols at the right of the screen but likely Nintendo realized that they got in the way too much.

So I worked out the code for the Japanese versions which, as can be seen below, reveal that it was to show how many keys you had collected, most likely the small key in Big Boo's Haunt. (As with the other versions of SM64 the display works for all levels.) The key colourful character is only in the Japanese versions, for the USA game it was removed and for the PAL version it was swapped with the Ü (although usually only used for normal text).

 

The beta picture of the Boo key is in Big Boo which is a little odd since the key display can show more than one key and yet there is only one Big Boo. As to give an idea of how the key display would work I created a code that modifies the coin behaviour and swaps the blue coins for the Boo key so that for each key you collect the key display updates:

 

 

You may notice that the key doesn't quite fit in the Boo when small, which supports the belief of only getting the key from Big Boo.

The Textures

The objects in detail

The Opening Movie

Unused and Beta Graphics

Stored in the RAM there is always a list of pointers to the graphics structures for each object. This is so the game knows where the graphics are stored especially as some of the common graphics move about in memory from level to level. A few of these pointers are actually invalid (the game doesn't update the pointers for certain graphics) for some courses but as for the rest, the game alters the values to reflect the new position of the graphics from level to level, with the exception of the common graphics which always live at the same place in memory.

Let me make this clear by dividing the graphics into three types:

(1) The very common graphic objects such as the coins, stars and Mario are in all or most levels and live at the same place in memory, not far from the start of the RAM.

(2) The not so common graphic items are Goombas, bat, Bob-ombs and so on and are loaded into memory at a different position depending on the level. A lot of these objects are actually unused in some levels including the cannon and common baddies.

(3) Lastly is the more uncommon graphics that move about in memory from course to course and include beta and unsed objects such as Blarrg and (except in Hazy Maze Cave) the sea creature (Dorrie).

By checking each graphic pointer value you'll find some very familiar objects and some that weren't used in a particular level but there may have been plans to use them. And as for the common graphics, you can easily swap them so you could have a butterfly that looks like a star, for example, and the change will remain for all the levels that have those graphics.

Now I will tell you about the unused and beta graphics in each level, please be aware that if the graphics are available then so are the associated animations.

In Wet-dry world some of the unused graphics are Bullet Bill, a Yoshi egg and the owl. Also, there's a Thwomp, a small Cheep-cheep and the spike bomb we know from the Bowser fights (the spike bomb was to be used in at least one of the water levels as a mine but was removed as an actual object).

(pics to be added)

Now onto The Princess' secret slide where we find Lakitu the cameraman, Boo, and MIPS the rabbit (a bit dangerous to try and catch it in this level). Most strange is the wing cap switch; could the secret slide have been the original home for the cap button? Note, like a lot of objects in SM64, the main part of the switch and its bottom are separate graphic objects. A few other graphics are flyguy and very interesting, Toad.

(pics to be added)

Now for a strange graphic in the Tower Wing cap course: a solid red box. Not very interesting but maybe that's how the unactivated wing cap boxes would have looked like before Nintendo decided on the version we are more familiar with, either that or it is missing some textures perhaps.

(pics to be added)

Does this ring any bells-Bullet Bill, a Yoshi egg and owl-but in Tick Tock clock.

(pics to be added)

The Cheep-cheep fish graphic is in Jolly Roger Bay, the spike bomb and the green spider pond skater, probably as they belong to the water set of graphics.

(pics to be added)

And surprise, surprise the spike bomb is also available in Dire, Dire Docks, as well as the green spider and Chuk-ya.

(pics to be added)

The piranha plant and Whomp graphics are both loaded into memory when in Bob-omb Battlefield, possible they were to be used in that level or it may just be due to the course being similiar to Whomp's fortress.

(pics to be added)

In Cool, cool mountain I found the graphics of a small and large blue ice bully; you may remember the big ice bully from Snowman's land. What's strange is that there are two separate graphics when they could have just resized one of them. The only other find worthy of mention is the handbag baddy that can be found in Snowman's land but its graphics can also be used in Cool, cool mountain.

(pics to be added)

Who's the creature you'd least expect to see in Hazy Maze cave...the monkey! And another baddy from Tall, tall mountain whose graphic can be used in Hazy maze cave is that cloud with a face.

(pics to be added)

We know that a Blarrg creature was to be in Lethal Lava land and its gaphics have not been removed in the released game, he is joined by the sea creature (Dorrie) we know from Hazy Maze cave.

(pics to be added)

This was a shock to find-the Blarrg graphic-in the Wing Mario over the Rainbow level along with the cavern beast (Dorrie). There's a lava theme here as there is also the graphic of the bat (can be seen in Hazy maze cave but also available in Lethal lava land), and a small and big lava bully.

(pics to be added)

Onto The Secret Aquarium course there are water creatures and other objects used in the bigger water levels, such as the manta ray, eel and shark graphic. Two more unused graphcs in The Secret Aquarium are the Cheep-cheep and spike bomb.

(pics to be added)

Where else could there possibly be unused lava themed creatures-Bowser in the Fire sea! There is the Blarrg, big lava bully, bat and the Dorrie sea creature.

(pics to be added)

There is much mystery about Big Boo's haunt and these three items are no exceptions, they are a key quite different to the Bowser key, the sea creature (Dorrie) and the cage that is the same as the one you use to get to the ghost level. It seems that the key you would get from a Boo judging by a beta picture, possibly the key was to be used to get to the second floor of the ghost house.

(pics to be added)

There are several unused graphics in the Rainbow ride course which are Wiggler (who is split up into two parts) and the large Cheep-cheep like fish. Both of these objects we know from Tiny-huge Island so maybe Wiggler was to be found in Rainbow ride originally. But even Nintendo wouldn't have had that huge fish swimming about in the air so Rainbow ride or whatever it started out as could have had water in it.

(pics to be added)

In Tiny-huge island there are two unused graphics which are Chain-chomp and Whomp. Think about it, the Tiny-huge island course has the same music as Bob-omb Battlefield and similiar enemies.

(pics to be added)

The only unsed graphic in Snowman's land that's worth talking about is a small ice bully.

(pics to be added)

Here's two very eye opening graphics in Whomp's fortress, and they are the Yoshi egg and a wind-up baddy that we know from Tick tock clock. What is the connection between Wet-dry World, Tick tock clock and Whomp's fortress that all have the Yoshi egg?

Considering Whomp's fortress uses the Bob-omb battlefield music it may not be so much of a surprise to find graphics from that course which are Chain-chomp, and koopa with and without his shell. The wooden post is not so interesting but the Koopa flag is: was there to be a race to where you find King Whomp similiar to King Bob-omb in Bob-omb battlefield?

(pics to be added)

In Vanish Cap Under the Moat you can use some of the graphics from outside the castle: the pipe and green tree.The other graphics, such as Peach and the castle tower, crash the game if used despite their structures appearing valid (there must be other data missing). This may not be significant but it suggests that this course may have been quite different.

(pics to be added)

Now onto the courtyard with the Boos there are many unused graphics that crash the game if you try to use them and most curious is a white square that brought the game to a halt within seconds so I took the screenshot as quickly as I could. Along with the strange graphic is Toad who wouldn't look out of place except for those Boos in the way so perhaps that's why there are just signposts instead.

Considering that the cage is an unused graphic in Big Boo's haunt I should have expected to find some of Big Boo's haunt graphics unused in the courtyard. There is the small key, chair, piano and book baddies and the ordinary book.

(pics to be added)

In the Cavern of the Metal Cap where you activate the metal cap boxes, the unused graphics are those available in Hazy Maze Cave so they probably weren't intended to be used. But they can be used if you wanted to and a couple of them are the bat and the spider.

(pics to be added)

Water

Something that features in many of the courses is water and Wet-dry World is known for its adjustable water level. Here I show you what happens when you mess with the water by removing it and as for Wet-dry world, it's possble to flood it to a super level!

The position of the water switches in Wet-dry world do not affect how high or low the water level changes but there is a varible in the RAM that does set the water level. For the PAL game this variable is located at address 0x8032EDBA and for NTSC 0x8036118A. This variable has the value of 0x0400 when you enter the course (assuming a normal jump into the painting), 0x0028 for the lowest water level and 0x0A00 for the highest water level.

All content of this and related pages is copyright (c) James S. 2007-2009