43 with 36 posters participating, including story author
In my years writing about games for Ars, I’ve covered my fair share of surprising glitches, long-secret codes, arbitrary code execution tricks, and deeply hidden content buried within some classic games and hardware. But none of that prepared me for the above Twitch video clip I saw this morning, showing a fleet of flying Arwings from Star Fox 64 invading the world of Ocarina of Time to attack Link.
It’s the kind of scene you’d expect to see only in a fan-made animation or in a ROM hack of the type Nintendo is so fond of taking down from the Internet. But what made this clip truly impressive was the fact that it was apparently running on an unmodified version of the original Japanese Ocarina of Time ROM, using standard N64 hardware and control accessories.
I spent all morning tracking down how such a thing was even possible. Explaining it involves a deep dive into the nature of Nintendo 64 machine language instructions, Ocarina of Time memory management, and the mid-’90s development of the game itself. If you’re as curious about all this as I was, come and take a journey with me.
Stale references and fresh code
The key glitch to this amazing run dates back to last October, when a runner named Glitches0and0stuff used emulators and careful examination of Nintendo 64 memory locations to discover a method for stale-reference manipulation in Ocarina of Time.
Basically, the glitch involves picking up an item and then tricking the game into unloading it right from Link’s hands when he crosses a loading threshold (say, for a new room). At this point, the game frees up the memory location for that held object so it can be used by other in-game objects as they’re loaded. But the game also still thinks Link is holding something in his hands, so it continues to update that “stale reference” pointer in the newly freed memory with data representing the nonexistent object’s position and angle. With some careful manipulation, this pointer can now be used to “corrupt” the data for a newly loaded object with arbitrary values.

  • Space fighters are no match for Link.
  • The Star Fox 64 Arwings can take damage and fire on Link as if they were always in the game.
  • Z-targeting makes it easy to aim a boomerang at an Arwing’s underside.
  • A shot of Link holding an “empty” object as part of the arbitrary code execution glitch setup.
  • Freezing the camera in this glitched position is a key part of the method.
  • To warp directly to the credits, some extreme measures are necessary to hold the correct buttons/analog positions on Controller 3.
  • After over ten minutes of file name entry, the Arwing code payload is ready to be loaded.

Initial implementations of this trick focused on simple “corruption,” like loading new items into treasure chests or changing the positions of other in-room items (as explained in detail here). After a while, though, players discovered you could also use the same basic method to alter some specific assembly language “jump” codes, which tell the game where to look for its next instruction when certain in-game events are triggered.
By inserting a specific code in this way, the game can first jump to the memory location that holds the last known X and Y rotation values for the in-game slingshot. If those values are set precisely, they’ll be interpreted as another jump code that goes to the area of memory where the current file name is stored. That file name will then be interpreted as basic N64 machine code, which can of course be set by the user ahead of time to do whatever they want (assuming they’ve translated the binary file name characters into the appropriate opcodes correctly, of course).
An explanation of the stale-reference glitch, initially used to replace items in in-game chests.
The first major use of this jump code manipulation was to load the game’s credits cut scene and thus set a new “Any%” speedrun world record for the game. Doing that quickly, in the game’s opening area, requires the use of some other glitches, including a “walking while talking” camera glitch that gets in-game rocks to load and unload at the perfect times and locations. It also involves holding down specific buttons and analog stick positions on the controllers in the first and third ports on the Nintendo 64, so those signals can get interpreted as the correct cut scene location code for the credits.
Unlocking the Arwing
The above method is fine if all you want to do is jump to a cut scene. But it had a major limitation: the Ocarina of Time file name system is limited to eight characters, which translates to just a couple of in-game machine code instructions. Luckily, those two instruction slots can also be used to basically eliminate that character limit.
The method for doing this is extremely intricate and is explained in detail in this Pastebin and this video. Suffice to say that it involves executing the general method above three times to remove a few key checks for the filename position pointer, then setting that pointer to a negative position value.
An in-depth explanation of arbitrary code execution in Ocarina of Time, as it was understood in November 2019.
The result lets players enter a file name that’s hundreds of characters long, allowing the player to pre-load much more complex sequences of machine instructions for the code-jumping method above. But that’s still not enough to code the graphics, animation, and gameplay logic required for our in-game Arwing attack. Luckily, Nintendo already did a lot of the work for us here, helpfully including all that Arwing code deep inside every Ocarina of Time cartridge.
Why? Character and Graphic Designer Satoru Takizawa explained in a 2011 Iwata Asks interview that it was a simple case of code reuse for some specific Zelda enemy movement:
Volvagia is a dragon, so it wriggles and undulates. I only gave [Boss Enemy Programmer Kazuaki Morita] the dragon model parts, but he set it in motion immediately. It was mysterious how he could do that… I couldn’t help but ask how he did it. He said it was the same as the programming for Star Fox 64. There’s this scene when another fighter aircraft is tailing Arwing, and… [the way the fighter moves as it flies and Volvagia’s movements are exactly the same]… I was like “Whoa!” and “I see!” and had a great time every day marveling over it all.
A circa 2007 video showing an Arwing flying over Kokiri Forest (making use of GameShark codes and an emulator).
After copying the necessary animations to Volvagia, Morita apparently left the entire Arwing code block in the game’s garbage data, as data miners discovered many years ago. And players have known for well over a decade how to access those buried code bits with cheat devices like the GameShark, editing memory values to replace specific enemies with Arwings.
But with the memory manipulating tricks discussed above, an external cheating device is no longer necessary. Runner ZFG1 proved this once and for all last night, loading the Arwings using an unedited Zelda ROM and standard Nintendo 64 hardware live on Twitch. The result is a version of the game where all the doors have been replaced with Arwings, which can swarm around Link from the air, attack him with damaging blaster fire, and even crash to the ground in flames when attacked.
The full setup for this particular clip ended up taking well over an hour, including three arbitrary-code execution loops and over 10 minutes of meticulous file-name entry for the final Arwing payload. But the clip is also the culmination of months and years of work by a community utterly obsessed with achieving full understanding and mastery of a classic game and its glitches.
Besides being a joy to marvel at, the “Arwings in Zelda” clip is a testament to that communityand to the ability for a group of computer experts to do amazing things with classic gaming hardware and software, given enough time and focus.
Listing image by Twitch / ZFG1