In the fall of 1981 I was going to college and became addicted to the Atari arcade games Centipede and Tempest. I knew a little bit about the hardware of the Atari 400/800 home computer systems, and decided to make a scary purchase on my student budget and buy an Atari 400 and a black and white TV (which was all I could afford). I messed around in Basic for a while, then bought an Assembler/Editor cartridge and started hacking away on a Centipede clone. I didn’t have much to go on in terms of seeing prior designs for games and had to figure everything out myself. Like most of the school problems, you really just have to work things out with a few hints from the textbooks and lectures.
Anyone who’s worked with that Asm/Editor cartridge probably bears the same deep emotional scars that I do. It was unbelievably slow, the debugger barely worked, and I had to remove comments and write in overlays of a couple K in order to squeeze in enough code. My game, which I called Myriapede, took about three months to write. I still have the original artwork and designs in my files; graph paper marked up with multi-colored pens, with the hexadecimal for the color assignments painstakingly translated on the side.
[I had to guess at colors. All I had was that cheap black and white TV, and I had visit a friend’s and his color TV for a couple hours in order to fine tune things].
The Atari Program Exchange (a captive publishing house) was holding a contest. The grand prize for the winning game was $25,000. I’d spent a semester of college blowing off most of my courses and doing almost nothing except work on Myriapede. I finished it with a week or two to spare and submitted to the contest.
A few weeks after I mailed Myriapede off to the contest, I got a letter from Atari that said (1) they were very impressed with the work, but (2) it looked to them like a substantial copy of Centipede (well, it was) and that they’d rejected it for that reason. The subtext was they would probably sue me if I tried to sell it anywhere else, too. I was crushed. I wound up going to a local user group and giving a couple copies of it away; I assume that it spread from there. I hear that people liked it (“best download of 1982″ or something like that).
A few weeks later I got a call from Atari; they wanted to know if I was interested in interviewing for a job. I was practically vibrating with excitement. I flew out and did a loop, and made sure to show Myriapede to each interviewer; it was a conversation stopper every time. Until they saw it they kind of humored me (“yeah, okay, you wrote a game”), then when the game started up they started playing it, got distracted and (“ahem!”) had to be reminded that they were doing an interview! One of the guys I talked to was the author of Atari’s “official” Centipede cartridge. He said on the spot that my version was better than his.
A couple weeks later they gave me an offer. Atari moved my single roomful of stuff out to California. I flew out and spent two weeks in a hotel waiting for my things to arrive; Atari wanted me out there real bad.
Now, there were two popular arcade games that I simply could not stand; the first was Zaxxon, a stupid and repetitive scrolling shooter. The second was Donkey Kong — it was loud, pointless and annoying. Of course, the reason they wanted me in California was so I could work on a Donkey Kong cartridge. After a few moments of dispair (and faking enthusiasm in front of my bosses) I gritted my teeth, got a roll of quarters and spent a lot of time in the little arcade that my hotel had, playing the DK machine there and getting to know it really, really well.
I should explain how Atari’s Arcade conversions group worked. Basically, Atari’s marketing folks would negotiate a license to ship GameCorp’s “Foobar Blaster” on a cartridge for the Atari Home Computer System. That was it. That was the entirety of the deal. We got ZERO help from the original developers of the games. No listings, no talking to the engineers, no design documents, nothing. In fact, we had to buy our own copy of the arcade machine and simply get good at the game (which was why I was playing it at the hotel — our copy of the game hadn’t even been delivered yet).
So I played about as much Donkey Kong as I could stand, and started fiddling around with ideas. I wrote a 25-30 page design document that broke out the work into modules, and estimated the work at five months (this was early November of 1982) and handed it to my boss, Ken, with some trepidation. Was it good enough? Would they send me packing for not being a real designer and games programmer?
“We’re totally blown away by that spec,” said Ken. I’d simply enumerated the objects in the game, written some psuedo code for some major game modules, and assumed that it was a starter for a real specification. But everyone else treated it like the whole thing. I just needed to code it up. That was kind of scary.
“Marketing wants it by Christmas,” said Ken. I had made a careful estimate, and came up with about 150 days of work. There was no way the game would happen in a couple of weeks, but the sense of pressure was clear. With nothing else to do (besides find an apartment and wait for my stuff to arrive), I began to spend almost every waking hour at work. I did my first ever all-nighter, cranking the stereo notch by notch to keep pace with a guy in the office next to mine who was also doing an all-nighter. The company cafeteria was open for three meals a day.
The neat thing is that once you’ve gotten into a project to this extent, the project tends to write itself and you’re just along for the ride. Life is defined by work, and then the boring eating/sleeping stuff. I know that sounds hellish, but it’s really a tremendous amount of fun. I was was like 21 years old and being paid to do something that I think I would have done for free.
We used a Data General minicomputer, an MV/8000, for cross-development. This was the machine that Tracy Kidder’s book Soul of a New Machine was all about. While it wasn’t a VAX running Unix (which I would have preferred) it was still pretty easy to use and had some decent tools (no Emacs, though). We used a version of the Atari Macro Assembler that had been ported to the MV/8000, and that was worlds better than the miserably slow Assembler/Editor cartridge I’d done Myriapede on, but everything had to be downloaded to our development systems at 9600 baud, so turnaround time became a big issue toward the end of a project, especially since we had to share the MV/8000 with fourty or fifty other people during the day, just like the overloaded mainframe back in college. I’d often stay late, and after about six PM the systems were pretty fast again (five minutes, instead of nearly an hour).
– – – –
My very first day at work I arrived at my office after orientation and found an Atari 800 computer in a boxes. I spent a little while setting the machine up, got it working, and went to get coffee.
When I returned, a staffer appeared in my door. “Oh,” she exclaimed, “You knew how to set up your computer! I was going to do that.”
“Well, thanks, but…” Didn’t everybody know how? Setting up an Atari computer wasn’t amazingly simple and obvious, but it wasn’t all that hard, either.
It was a portent of things to come. 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.
That would be a general theme throughout my tenure at Atari. Newly hired people didn’t necessarily know how to do their jobs, and I spent a lot of time helping them figure stuff out that they should have known in order to land a job in the first place. Atari’s hiring practices were not very careful.
– – – –
I’d been writing in C for a number of years, and I developed a sort of pidgin C that I used in fleshing out modules. I’d write a few pages in this high-level pseudo-C, then spend half a day “compiling” it into 6502 assembler. Sometimes a significant chunk of code would work the first time (this is a scary experience, really it is).
The other thing I “got” somehow was that comments were important. I’d seen a bunch of OS code (including the 400/800 OS sources) and it was really nice and understandable. But most of the game sources I saw in the consumer division were crap, just absolute garbage: almost no comments, no insight as to what was going on, just pages of LDA/STA/ADD and alphabet soup, and maybe the occasional label that was meaningful. But otherwise, totally unmaintainable code. For the most part that was okay in the games industry, since almost none of the code in the company was ever re-used or shared (the exception being well-debugged subroutines in the Atari Coin-Op division for doing math and operating the coin mechanisms of the arcade machines).
I think that DK is one of the best-commented consumer games that Atari shipped (Super Pac-man is better, but it arguably didn’t ship). Customers don’t see comments, but other engineers do, and it’s worthwhile for them to learn from what you’ve done. For instance, Mario’s jump moves are derived from basic physics of motion, and the calculus-based equations are in the source, nicely formatted so you can see where the magic equates just below came from. After DK shipped, a cow-orker of mine got a copy of the source listing, spent a week reading it and said that he was blown away (“I don’t know how you could have typed all that, certainly not in just five months, and when I saw the motion stuff my jaw hit the floor.”) Blush. Code should both entertain and educate.
Donkey Kong shipped in mid-March of 1983. I vaguely recall a small party at work, but mostly I was glad it was all over.
– – – –
Technical details. Kong is in graphics mode $E (192 scanlines by 160 color clocks wide). When a level is started up, the background is stamped once. Barrels and other creatures are XOR’d onto the screen (I had some mask-and-repaint code at one point, but it was way too slow). Mario is a few player objects (three, I think). The “prize” objects (umbrellas, etc.) are the remaining players. The XOR graphics are pretty annoying to me, but most other people didn’t seem to mind and some people even thought it was cool.
All of the sound was done by Brad Fuller. Mona Lundstrom did a lot of the graphics design (but I wound up replacing most of it). The ‘cartoon’ sequences were given to another engineer, whose code I had to entirely replace (he originally wanted to do the job in FORTH, and didn’t understand that the game couldn’t afford to devote half the cartridge space to a FORTH interpreter just to make his life easier).
At its peak DK was about 20K of code, and it had to go on a diet to fit in the 16K cartridge; a lot of the images were compressed (notice that Kong himself is symmetrical). Towards the end I was crunching out only a few bytes a day, and it shipped with maybe a dozen bytes free.
There’s an easter egg, but it’s totally not worth it, and I don’t remember how to bring it up anyway (something like: Die on the ‘sandpile’ level with 3 lives and the score over 7,000).
For tuning difficulty, I slowed the game way down and simply made sure that it was possible to play. Some of the object movement is random, but should be within beatable constraints, assuming you are fast enough.
– – – –
The first division meeting I went to strongly hinted at the future of Atari. It was greek to me, but the basic message from management was that sales were slowing, margins were plummeting, and that the company was going to have to restructure to stay profitable.
The building next to mine was the first to go; Atari used it to manufacture the 2600 game console. They moved the building’s manufacturing overseas and laid off most of the people who worked in it.
There were some distant purges in marketing. The little “conversion” group of 8 programmers I was in had been moved to a satellite location far away from any of Atari’s major buildings, so we were pretty isolated from what was going on, but even from a distance it was clear that things weren’t going well. The game industry had essentially crashed, and Atari was putting millions of unsold cartridges into landfills. All of the mistakes that wild success had covered up were coming around to bite hard.
My office-mate had finally finished Robotron. By request, she made three versions of the ROM image, located at different ROM addresses. Unfortunately, the Q/A staff was only able to test two of the images. Guess which image Atari sent to be manufactured? Guess which image had a fatal bug? I saw a hardware engineer struggle to come up with a cheap gate-or-two fix that would make the game work; only a few bytes of it were wrong. In the end, Atari threw $200,000 worth of ROMs away.
I have the impression that mistakes like that were being made all over. This was compounded by the fact that games were just not selling; fueled by time-to-market, Atari marketing had forced its engineers to write games that lacked polish and fun, and that practice had come back around. People were bored with playing the same old junk.
There were layoffs and reorgs every few months. Our little group moved to one corner of the Coin-Op division’s building; a consolidation to save money. I was working on Super Pac-Man and nobody seemed to care, so I took my time on it and did a good job.
Eventually Jack Tramiel bought the parts of Atari that he wanted, and I would up working on the Atar ST, but that’s another story.