Re-enacting TRON On The Apple IIgs

TRON is a science fiction classic, hitting cinemas in the midst of the burgeoning home computer era. It’s the film that created the famous light cycle, which spawned many video game recreations in the following years. Many years ago now, [Daniel] decided to flex his programming muscles by coding a version of the game for the Apple IIgs, with accidentally excellent results.

In the film, the characters find an escape from the light cycle game by forcing another player to crash into the walls of the play area. The resulting explosion left a hole, allowing the players to exit the light cycle game and explore the rest of the computer. Amusingly, due to a coding oversight, [Daniel] had created exactly this same flaw in his own code.

[Daniel]’s game differed from the original in that players were provided with missiles to destroy enemy trails. However, these missiles did not discriminate, and due to the simplicity of the code, were able to destroy the boundary on the play area. This was discovered when the computer player tried to escape an otherwise impossible situation. Upon blowing a hole in the arena wall, the computer player proceeded to drive off the screen – into invalid memory. This led to the computer crashing in short order, due to the unprotected memory space of the Apple II platform.

It’s a case of code imitating art – and completely by accident. The game managed to replicate the light cycle escape from the film entirely due to the unexpected behaviour of the simple missile code. [Daniel] steps through the code and how the bug happened, and covers the underlying principle behind the resulting crashes. It’s an entertaining tale of the risks of coding at low level; something we don’t always run into with today’s modern interpreted languages.

Thirsty for more tales of hacking the Apple II? How about going back in time to fix a 37 year old bug?

4 thoughts on “Re-enacting TRON On The Apple IIgs

  1. I did something similar in a text adventure game I wrote in college. In COBOL. By cheating I could go North etc when I wasn’t supposed to. I ended up wandering through bits of the source code. The COBOL was “compiled” to run on some sort of P-code system, my guess is that’s where the source code appeared from.

    The OS was System V Unix on a 68020-based mini (I think). Other than that, the source code was also in my home directory and might’ve been hanging round de-allocated RAM waiting to be wiped from when I compiled it, I suppose. I’d have to really dredge through the technical docs for a system I haven’t seen in 20-odd years to be certain. It had proper virtual memory though.

    After a bit of exploring code and variables, it’d crash soon enough. Really it was just reading stuff from arrays with an invalid index.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.