It's been an interesting last few months for Nintendo fans. We were handed a massive gigabyte of leaked material from deep within their headquarters that revealed things like the entire development process behind Yoshi's Island, as well as the evolution of Yoshi himself (who started out with the more accurate body shape of a dinosaur). We got to play the 1997 Japanese trade show demo of Pokemon Gold and see concept art for Pokemon that were changed or never even made it. We got to explore beta regions from Zelda 64 that were shown in early trailers but didn't appear in the final game. We found beta versions of every single Genesis Sonic game (okay, that's not Nintendo, but it counts in my book). We got our hands on the rumored XBox 360 conversion of Goldeneye 007. And just yesterday, I woke up, turned on my computer and there, standing before me, was DINOSAUR PLANET.

So much has come out that there have been revelations that were drowned out by the noise of the bigger revelations. One of the things the Gigaleak produced was the source code for The Legend of Zelda: Link's Awakening. I thought that was huge, but apparently everyone else thought other things were huger. The Yoshi's Island material was analyzed and dissected from every angle, but I've heard barely anything about Link's Awakening. And it's a shame, because I found some cool stuff by myself.

The folder with the Link's Awakening material originates from the time period when they were colorizing the game for the release of Game Boy Color in 1998. Both the original ASM (Assembly) scripts are there as well as the additional scripts written to add in the new material. There are also ROM files from various points in the conversion process, from the original black-and-white to the finalized DX retail ROM. For the first time ever, we have access to the in-between stages where all they did was add color to the existing tiles. These were the source of early screenshots in magazines:

The ROMS are also dated, revealing the initial color conversion took place through June and July of 1998. The new content and revamped tiles seem to have been added sometime in August.

Link's Awakening, like all other Nintendo games at that time, was written in Assembly. You might consider it a dead art but since the homebrew community has been growing, a new generation is ASMing up fresh games for retro machines. Since I had coincidentally been studying Assembly myself, I found I could not only look at the original code for one of my favorite games....I could UNDERSTAND it! That was awesome!

Now, if you have the time, I'll teach YOU how to understand it too. If some of you find this too confusing, you can skip down one-fourth of the page to the part where I start talking about something else. It's really to your loss though...there isn't much to Assembly and reading the code from your favorite game is a fascinating experience.

Assembly is one of the first programming languages ever devised and thus it is one of the most simple. It has only a handful of commands, each one being just three letters long. it doesn't take much time to go over ever single command in Assembly. The true challenge comes in making anything out of it.

Because it is so primitive, you're taking programming down to its core: maniuplating the very ones and zeroes themselves. A lot of Assembly is just simply moving numbers around...taking a number out of memory, adding or subtracting from it, and then storing it somewhere else. With a gazillion of these commands, you have a game. The hard part comes in writing the gazillion commands.

The first thing you need to learn is that you have three places in which to manipulate data:

A

X

and Y

A is what the program mainly uses. And a typical routine starts with loading a piece of data into A.

LDA $4404

"Load A" is the command you'll see the most. It's followed by a registry number -- the exact location of the bit of data the program needs at that point in time. LDA says, "Take the number stored at the location we mentioned and load it into A, so we can do something with it."

The programmer doesn't actually see "$4404." They see a variable or a nickname given to that address. When source code is compiled (when it's crunched by the computer into a game ROM), it becomes raw data and all the names are lost. This is why it's so hard to make sense of a video game's coding without the source code.

Another thing you'll never see without source code are the notes programmers make along the way to help them make sense of what they're writing. The compiler will ignore anything with a semicolon after it, so programmers write notes and guides into the code by preceding it with semicolons:

The second thing you need to learn is how to recognize an IF-THEN-ELSE command. These are the building blocks of all programs in all languages.
IF something happens, THEN do a thing, ELSE do something different.
IF the D-pad is pushed left, THEN make the player's character move left, ELSE don't make it move at all.

You can't do anything without IF-THEN-ELSE, and it works differently in assembly than in most other languages. It's time to learn the next few commands: CMP (compare), BEQ (branch if equal) and BNE (branch if not equal).

LDA dataName
CMP differentData
BEQ newLocation

We've loaded a bit of data into A that we call dataName. Next we're COMPARING it to the data that's stored somewhere else. If the two numbers are the same, the program will BRANCH to a different place in the code (like, say, the part that tells the player character to move left). The BNE command does basically the same thing, only when the numbers are different instead of equal.

That takes care of our IF-THEN. But what about our ELSE?

Well, if dataName and differentData are two different numbers, then the code simply won't branch. So below it, we can write what the program should do when the player isn't being moved.
If we program the D-pad to register a specific number when pressed, and we make dataName equal to that number, the code will execute. Otherwise it'll do something different.

Here's the problem with branching though -- you're only allowed to leap so far. Due to limitations in assembly memory, the program will refuse to work if the distance between BEQ and the location we named "newLocation" is too great.
Fortunately, we have a command with infinite range for those situations. It's JMP (jump). If you're familiat with 80s BASIC, this works the same way as GOTO.

You can JMP anywhere as long as the place you're JMPing to is loaded in the memory bank. So why bother with BRANCHing at all? Why not just use JMP all the time?
Because JMP is not a command that works with comparing numbers, BEQ and BNE are.

So to work around this, a typical IF-THEN-ELSE is a combination of BEQ, BNE and JMP. Like this:

LDA dataName
CMP differentData
BNE skipThis
JMP newLocation
skipThis:

This modified IF-THEN-ELSE has unlimited range. iIf dataName and differentData aren't equal, the program heads to the line we've labeled "skipThis" -- skipping the line with the JMP command. If the numbers are equal, then it reads the JMP and obeys, skipping the rest of what we wrote.

When we're done with whatever we need to do to a specific number, we can store it back where we got it by using Store (STA).

STA #$4404
Or as the programmer sees it,
STA leftNumber

And there are more commands than this, but that's enough to read assembly source code somewhat.

Everything I've just described is 6502 Assembly code, which most 8-bit machines (like the NES) used. The Game Boy, however, had a Z80 processing chip, not a 6502, which means the language is a bit different. Here, the instructions are even harder to understand because most of them take up two letters instead of three. But now that you're acquainted with Assembly commands, it doesn't take long to figure out that LD is a shorter LDA, JP means Jump, etc.

So let's take another look at that mess posted earlier. This is from ZEN.DMG, which appears to be the script that controls Link's interactions with monsters. It makes a bit more sense now.

The notes also help, but some are in Japanese. Good thing we live in the age of Google Translate. The question and answer part says, "Tanuki?" and then "Yes!" below it. The line by the INC says, "Transform into a father!" We're looking at the ASM script for the scene in Mysterious Forest where the raccoon turns back into Tarin.

The first line says, "CP PAPA0." The note by it declares, "TANUKI TARIN!" The game is comparing whatever number is in A right now to the number registered to mean Tarin as a raccoon. The next command is "JR," which is kind of a cross between JMP and BEQ...it takes you to a directed place, but it can only travel a limited distance. EECRE0 is the name of the next part of this script (see the bottom). And NZ is checking PAPA0 to see if it equals zero (meaning nothing is meant to happen). If PAPA0 is zero, the program will jump all the way down to EECREO...if not it will stay here.

And if it stays here it will load a flag, do some math to it, then make the same comparison again. If the answer is No it will skip down to EECRE0, if it's yes, it will add some more things to whatever is stored in variable HL, then start the transformation sequence. Observe at the bottom that the sound is cleared (the music stops) and two sounds are loaded instead, which is exactly what happens when Tarin starts bouncing around.