The Wiki http://www.computerarcheology.com/wiki/wiki
I am changing the format of this site away from TRAC. Until everything is moved over, visit the original wiki at the link above.
This web site is about digging up old, forgotten computer systems and cracking open the code that ran on them. Think of each program as a different "dig site". I am a nerdy Indiana Jones. My goal is to find the original programmer's spirit, ideas, and ingenuity in the code -- the programmer's "flavor". There are code gems and wise idea-nuggets in these programs buried in the ancient (decades past) ROMs of old. My goal is to dust them off and put them on display for all to share.
Welcome to the museum!
If you would like to contribute your own disassemblies to this site then press "Contact" above drop me an email. If you would like me to add a link here to your own site then send me the information.
The contributors to this site:
If you like Computer Archeology you must visit Don Hodges amazing site
. He has a series of digs into Pac Man, Ms Pac Man, Dig Dug, Donkey Kong, and Defender to name a few. Visit his Archive
for most of the series.
Vecoven Frederic has disassembled the Galaga sound processor. See his awesome work here: Vecoven Frederic - Galaga Sound
. Hopefully he will tackle the entire code base!
Dr. Stefan Holtgen in Berlin is working on a project investigating the nexus of hardware and programming languages of the early micro computer era. Check out his blog at Dr. Stefan Holtgen
. Google-translate does a great job if you don't read German.
Use the "Site" tab on the navigation tree to the left to go straight to a particular page.
One Quarter at a Time
There is a famous bug in the arcade game Galaga. Shoot everything in the game except the lower left bee. Then dodge it for fifteen minutes. Eventually it will stop firing, and none of the bees will fire at you again for the rest of the game. Let me lead you into the tomb of Z80 opcodes and show you the mistake in Galaga
Space Invaders was one of (if not the) first arcade games. The 8080 code is littered with "questionable code design". There is a hidden message Easter egg in the code, and I found a subtle bug. Check it out here in SpaceInvaders
Many early video games used vector-graphics. The display hardware reads a long list of lines from memory and then drives the electron gun from point to point. The technology is all but lost today. Check out the line-list programming in Asteroids
and in Omega Race
Harry Hurst has dug into the multi-bank ROMs of Defender
. Have a look at his ongoing work.
Sounds of the 80s
Remember the songs in Frogger? There is actually a snippet of hidden music buried until now. See and hear it here in Frogger
I grew up with the AY38910 sound chip. I still have a couple dozen of them! They were used in several arcade games, and it is fun to see how different sound boards scheduled long-running effects over multiple channel resources. Check out the sound-board disassemblies of Moon Patrol
and Time Pilot
The running base line in Moon Patrol is a nugget in itself. You can see the beginnings of Domain Specific Languages in these boards that define their own sound-script languages.
Adventures in Text
The TRS-80 Color Computer hosted a series of text adventure games from Robert Arnstein. Follow the fascinating evolution of his adventure engine from Pyramid
to Raaka Tu
Spectral Associates produced a complex text adventure game with real-time features in Madness and the Minotaur
. It is possible to win the game, but it is extremely difficult without knowing the secrets. They are all described here.
TV Console Systems
If you were a child in the 70s chances are you had an Atari2600. The hardware seems designed with the included game Combat
in mind. But game developers squeezed out ingenious games using the simple hardware objects. In Missile Command
the player-duplication feature creates the parallel falling missiles.
The 2600 was limited to a direct access of 4K bytes in the cartridge. Many games included several banks of ROM that were swapped in and out through cartridge circuitry. See bank switching in action in Asteroids
cartridge is a complete chess playing program for the Atari2600 with multiple difficulty levels. The entire game fits in a 4K cartridge and uses only the system's 128 bytes of memory.
The Legend of Zelda
for the NES started a long series of wonderful Zelda games spanning all the different Nintendo game systems.
Patrik, add whatever you want to the description here.
Computer viruses are an intriguing part of our computer culture. Let me take you into the assembly workings of two famous but defunct viruses. First I'll show you the Morris Worm
VAX assembly snippet written into a buffer overrun to forge a root shell. Then we'll look at the PC Stoned
boot sector infector. As tiny and efficient as it is, there is always room for improvement. Let me show you!
Patrik Sevallius is tackling Rainbow Islands
. He is especially focused on the Rob Northen copylock
Some Assembly Required
You can learn the rules of chess in an afternoon. Becoming GOOD at chess could take a lifetime. Programming is similar: the instructions the computer can execute are simple and few. But learning to combine the instructions into a sequence that does something -- something creative an engaging -- is more of an art than a science. It takes learning and practice and discipline. It takes talent.
Maybe Legos are a better metaphor. There are relatively few TYPES of pieces you have to work with. You have the 4x4 and the 4x8 and the 1x8 and so on. Some very creative people have written out sequenced instructions (a program) for combining pieces to make castles and starships and a replica of the Death Star. You (the computer) can easily follow the simple instructions and snap the pieces together to build these marvels. But designing the thing and writing the instructions to implement it? Well that takes a Master Builder who works with Legos on a higher plane.
After decades of evolution computers still only understand the myopic language of opcodes. Their moment-by-moment life is simple: read a value from memory, subtract five from it, store it back to memory, and jump to another part of the program if the new value is zero. They see only the current instruction. They have no internal inspiration of "Ah ha! I see what this code is doing!"
The programmer, on the other hand, starts at a higher level. He thinks about "alien ships" and "scrolling screens" and "collision detection". Where the computer sees "read location 100" the programmer sees "get the coordinates of QBert".
The programmer stitches sequences of instructions together to form routines that perform tasks like "draw a line from (a,b) to (c,d)". Then these routines are building blocks used to build more complicated building blocks like "draw a rectangle". These are combined to make more powerful blocks. Eventually the building blocks are all combined to form a working program. And other programs can reuse the crafted building blocks.
Humans think in labels and symbols. But the computer instructions use only numbers and addresses. The assembler is a tool that translates the programmer's label-filled instructions into the same instructions with numbers the computer can use.
The label "DrawLine" becomes "address $1577". And the label "QBertObjectStructure" becomes "address $8000". The labels and precious comments and drawings all get lost in the assembly process. All that remains is a list of very, very crude instructions that the computer follows one by one.
If the computer can read the instructions, then you can too! A "disassembler" reads a binary program image and produces human readable mnemonics for each instruction.
It isn't always easy to tell what is data and what is code. Tables and data objects are often scattered between routines in the code. The disassembler will generate "???" for invalid opcodes -- markers for data sections.
Separating the code from the data is just the beginning. What does the code do? What is the data? How is RAM being used? This is where the archeologist studies the code and ponders and begins to write comments on how the system works. He begins to assign labels to code and data. He begins to decipher what the data structures are.
There is no science to this part of the disassembly. This is where your own experience, insight, luck, and long staring result in that "ah ha!" moment of understanding.
There are lots of tools support the archeology efforts. They are all in the computerarcheology repository on github
The Raw Content
includes the markup files for discussion and code. If you want the clean disassembly file for a particular dig site, then look here.
The web pages on this site are built from markup files. The Web Site Builder
process the Raw Content into HTML deployed to this web site.
These are my Assemblers, Disassemblers, Cleaners, etc
used to dig into the code. There are several site-specific tools here as well.