« Intro to GWT article in October 2008 Better Software Magazine | Main | Test-First GWT article in November 2008 Better Software Magazine »

October 05, 2008


Feed You can follow this conversation by subscribing to the comment feed for this post.


I'm wondering if Some of the crashes were from the AI getting stuck somewhere in a RAM alley and blowing away some vital code in a memory address. They might have still had a missile or two after escaping from the game . . .


One of the funniest things on South Park was how they used the MCP from Tron as Moses.

I also wrote a Tron light cycle game, but mine was on the Commodore 64... I had way more colors to chose from (at the same time)


could this glitch work with a Macintosh IIsi. I know the video shared the main system memory but I don't know the permissions it gives applications.

Perri Nelson

That takes me back a ways. Thanks for the story!

Steve Clay

You could've certainly "watched" the AI driver by listing the memory addresses visited on the screen or providing a copy of the bike's movements on screen (use mod arithmetic to bound the copy to the visible screen), etc.


Do you have the code lying around? It would be a lot of fun to run it in
emulation. Also, as PockyBum suggests, it would be fun to make a hack
so that when a player, human or AI, blasts through a border, the
framebuffer "tracks" them (see below).

Getting a bit more technical, it should only produce really surprising
results when the player goes through the top or bottom of the field, as
I imagine video RAM was successive scanlines concatenated together, so
going off the edge, say, on the right-hand side on line y would simply
wrap the player around to the left-hand side of the field on line y+1.
If the Apple was anything like the Atari, you could actually POKE to
shift the start of video RAM (change the mapping for the display in
memory-mapped RAM), and "follow" the player in his path of destruction,
above or below the playing field, by tracking his Y position and
adjusting the start of the framebuffer accordingly. (I believe games
like Goldrunner and Goldrunner II used a similar trick to provide
extremely fast scrolling over a playing field, sort of a smooth
page-flipping, but I could be talking out my arse)

Abeer V. Dey

Ah it's so awesome to hear such funny and amazing tales from the world of programming. And if one lives through them, they are every bit as memorable for one's whole life like the other great moments they have had.


shaun the pixel check program uses assembler code so it is likely the missiles run the same way and I'm sure they run open loop; it's just not that easy.

I love just thinking about how this would fail. AI blows hole in wall and runs out instantly its path finding reads the addresses accessible to it. this causes memory mapped IO to go crazy because not only is it reading the cell in front of it but likely 2 cells in front of that as well as the sides. then you have the path its leaving behind it, a constant stream of ones which a running program may interpret as an on state or part of a larger system causing more programs to go haywire. it would be like John Conway's Game of Life; programs madly expanding then fading out causing more reactions all the while. You have created the mother of all memory leaks.


I'm surprised nobody mentioned the pushwall bug from Rise Of The Triad yet. "I'm FREEE!!"


That's funny.. though instead of imagining what the AI players are doing, you could 'peek' at what it is they're looking at and draw that on a 'reserved' part of the screen.. like a top-down-radar view of each player that's offscreen. I'd love to see a video of that.


I love it! Even now i can see one of your bots firing missiles at key system data! Eat that kernel bit!

Terrence Davis

The LoseThos operating system, http://www.losethos.com , is a modern 64-bit PC operating system without protected memory, for just such purposes. It's for having fun programming and screwing around is fun and educational. It's 64-bit and supports multicores and is simple.


posts like this make me wish i could program


I wrote a Star Trek game back in Ye Daye on the TRS-80 and - due to a not dissimilar bug - accidentally fired a phaser shot straight down out of video RAM and into my source code. If you reacted before it got too much further and crashed, you could could LIST the source and see the phaser shot character recurring every 64 bytes down in the lines of BASIC. XD


Heh, nice article, reminds me of good old times :)

Prince of Persia for the PC had a similar 'bug', in some places you could fall through the wall to the sides. You'd end up in a weird, random place and basically fall forever until you crashed against a randomly laid trap, piece of wall or floor.

But the idea of an AI player crawling around memory is even more intruiging. In contrast to the player, they would probably survive there.


I bet the most spectacular crashes happened when the bot fired a missile at what it thought was an obstacle.


We played the hell out of this game, when we were kids. And when wee saw the Tron movie (with a bit of a delay), we tought that it was inspired by the game.
It's nice to see it again, thanks for making it, thanks for posting!


Please put the source for this game on github! :)

Daniel Wellman

@Bryan - I wish I had an image of my IIgs hard drive to do that!

Roger Wagner

I loved Tron and very much loved the Apple IIGS. It actually took 6 years for the Mac (black & white in 1984) to catch up to the color Apple IIGS, and that "catch up" didn't include a MIDI synthesizer. :)

Daniel Wellman

@Roger Wagner - Thank you for visiting and commenting! Reading "Apple IIGS Assembly Language for Beginners" helped me learn to write in assembly language - which helped me write this program! Thank you for writing it and all your contributions to the Apple II line!

The comments to this entry are closed.