Donkey Kong and Me

MBCook sends us to the blog of one Landon Dyer, who posted an entry the other day entitled Donkey Kong and Me. It describes how he was offered at job at Atari after writing a Centipede clone and ended up programming Donkey Kong for the Atari 800. It's full of detail that will be fascinating to anyone who ever programmed assembly language that had to fit into 16K, as well as portents of what was to come at Atari. "My first officemate didn't know how to set up his computer. He didn't know anything, it appeared. He'd been hired to work on Dig Dug, and he was completely at sea. I had to teach him a lot, including how to program in assembly, how the Atari hardware worked, how to download stuff, how to debug. It was pretty bad."

Open Development

[Doc Ruby]

How I wish Atari had got that guy to teach everyone how to program the Atari 800 and 400. I had to teach myself from the most cryptic, sparse and often contadictory documentation. There was an "Internet" in the early 1980s, but practically no one had access (I did), so we depended on the few published books, occasional insights in magazines like COMPUTE!, Creative Computing and Byte.

It wasn't enough. Programming wasn't just hard because it required assembly code skills (or forth, hah!), but because it was completely hidden territory. There was no real way to get source code from the programs that some people managed to write and distribute, and certainly no obligtion for anyone to release it (except the occasional superficial magazine article).

The competing Apple ][+, IBM-PC and TRS-80, all had BBSes full of downloadable code (often including source). Their corporate vendors each published detailed programming guides. The TRS-80 was doomed because of the direction of its corporate parent (which should have stayed in the PC business, porting its OS on Intel HW when they all upgraded from 8 to 16 bits). But IBM and Apple survived, even thrived (as we all know), because it was easy to get in the programming game.

By the time Atari finally published its "De Re Atari", which was a good start (the source code to the OS), the small developer "community" had already chosen either Apple or PC. If Atari had taught us all how to program from the beginning, its superior hardware and attractive game platform would probably have left it a strong competitor to the PC, much as the Mac has. But we were all on our own, and our platformed disappeared.

The same dynamic is still true on new platforms. Make it easy to develop for it, and it will survive, even thrive.

Maybe they wrote their server in 16K!!

[nexusone]

Just to think I started programming that was a lot of memory, today code seems so bloated....

Re:Other Media of Related Interest

[Anonymous Coward]

I've seen the King of Kong documentary and after reading this article I was wondering how he managed to reverse engineer the game without beating it. TFA mentions that Atari reversed engineered their arcade ports without any help from the original developers. Given the fact that Donkey Kong is unbeatable and that only 2 people in the country have even seen the last level.. makes me wonder if he designed his own levels for the port or had to extract them from the rom or something.

Re:Open Development

[Tablizer]

But IBM and Apple survived, even thrived (as we all know), because it was easy to get in the programming game.

They survived largely because they were targeting multi-purpose usages whereas Atari was targeting mostly games. The game crash of '82 didn't stop general computer growth. IBM thrived because of the clone market (eventually hurting IBM) and Apple survived because of the desktop publishing market it helped spark. Amiga could've had a chunk of that market, but didn't bother catering to it well.
         

Re:Maybe they wrote their server in 16K!!

[Kjella]

Take off the rosy glasses and you'll remember all the bad things as well. I had a Commodore 64, and there were so many things that you couldn't possibly fit into that amount of space. For example, I doubt you can fit a simple truetype font rendering library with hinting in 16K. I'm glad I'm past that point where I need to think about the 200 byte structure I'm working on is passed by copy or reference, or whether this is a short or a long. I'm glad I can pass around a larger structure and not try to chase byte-size improvemets by calling everything on a need-to-have basis. I'm glad I can use standard library functions, even when they're ovrekill to invoke.

My primary metric is clear, do as much as possible with as little code as possible. By that I don't mean extreme LOC-compression or extreme cross-referencing, I'm talking about writing using standard functions to minimize maintenance, complexity and sources of bugs. Bloated? Well, you can say that I don't care how much memory the libraries eat, but I certainly don't want the *code* to be bloated.

Re:Nep0

[SuiteSisterMary]

Makes me miss the good ol' days when you didn't need a staff of hundreds and a multi-million dollar budget to make a good game. Back then one guy who didn't know anything could sit down and within a few months crank out a fun game for a popular console.

Well, nowadays, that's wht Xbox Live Arcade is for.