My memory of the ST project is scattered and biased, but here’s how I remember it, starting in July of 1984. There are a lot of details missing; for the most part I remember the bits that I worked on, but the other folks on the project almost certainly remember different or conflicting stuff. Forgive my omissions in advance; it’s been a while.
July: Tramiels buy Atari and consolidate the people that they don’t lay off into a single building. The “ST” plan is bandied about, but nobody knows a whole lot.
August: The ST hardware becomes clearer. We evaluate other OSes, etc.
September: Work starts in Monterey, near the Digital Research campus.
October: Work. We get (rented) houses in Monterey.
November: More work. We barely see those houses.
December: Much more work. The ST boots TOS for the first time.
January: CES (with STs running CP/M-68K). Decision made to move to new file system (GEMDOS).
February: 16K boot ROMs written (a couple-week side effort).
March: Even more work. Two weeks to crunch TOS to fit into 192K.
April: ROMs actually work (do you know how long it takes to burn 192K of ROM, not to mention UV-erasing older chips?)
May: ROM TOS 1.0 shipped. Phew!
Well, and there are some details.
– – – –
The other engineer was screaming at me: “If you’ll be patient with me, I’ll be patient with you!”
He stomped away to his office. Not his real office, which he would have been delighted to stomp back to. His real office was in Digital Research nirvana, in the buildings that we were forbidden to visit. Instead he had to be happy with stomping off to his crappy shared office in the building where he was temporarily relocated, where he had to work with . . . us. The pushy Atari guys. The hicks from Silly Valley who just wanted stuff to work.
We’d been in the satellite building next to the DRI campus for several months. Early prototype hardware was still maybe a month away (though we didn’t know that then). The pressure to get something working was intense, and the truth about what we had purchased from DRI was becoming clear: The software wasn’t technically sweet, and getting it running on the Atari hardware wasn’t a matter of just doing a port because large parts of GEM simply weren’t finished.
Theoretically you can write very portable code in C. As long as you stick to certain rules and have a reasonable degree of paranoia you have a good chance of your code running on different platforms, with minimal effort. The best way to do this is to have your code running, from day one, on several different machines using several different compilers. DRI had not done this with everything, and the resulting issues ranged from simple errors that were caught by the compiler and were easily fixed, to deeper issues that required design work if the code was going to run on anything other than an 8086. It was slow, frustrating, and there was a lot of friction. And some yelling.
That’s a dismal picture of the DRI / Atari relationship. Very often, things worked great. Some of the DRI guys were hilarious and fun to work with. But we all had our faults. If the worst of the DRI engineers thought they were programming gods who could code no wrong, then the worst of the Atari engineers were pushy bastards who just wanted stuff to work. Sometimes things clicked, but sometimes we were like scorpions in a bottle.
I forget what the “patience” argument was about. The other engineer was right, or I was right, or maybe we were both horribly wrong. An hour later we apologized to each other and sat down and just got the job done. But a couple of years later, long after we had returned to Atari’s Sunnyvale office, we still remembered that argument in lunchtime banter.
– – – –
The Atari side of the ST software team roughly broke down into six small groups:
Graphics. Two or three guys took the DRI-specified graphics layer and wrote font renderers, blits, line-drawing and other primitives. In my opinion the graphics guys were having the most fun, and since they were video game programmers (well, technically speaking, ex video game programmers now) they were running architectural rings around the rather pedestrian graphics abstractions that DRI had decided on. The graphics primitives on the ST had interesting extensions, and GEM only used a subset of what was available.
Porting Getting GEM working. Two or three more of our people were helping get GEM onto the 68000. This wasn’t just “compile, debug, rinse, repeat” deal, since GEM wasn’t really finished. These guys worked really closely with DRI engineers every day, and they were probably the most frustrated of us all.
BIOS (drivers) and OS (two guys, including me). Straight-forward systems bringup stuff. Lots of work, but mostly ho-hum.
Infrastructure: Build wrangling, source management, odd-and-ends, and pithy observations about the nature of humanity as it pertained to its use of computers, and in particular, nasty habits in source code. We didn’t use source control. I’m not sure we even used diff. Mostly we had several directories-full of source files that were compiled by a guy who knew how to do it. Rustic, but it worked.
Applications. Well, application, we had a guy working on porting the DRI Basic. It was pretty much a disaster, though the work eventually did get done. I have vague memories of an engineer hired by the Tramiels who didn’t do a very good job — I think he ran into a bunch of portability minefields, got discouraged and beat up on by management (we hadn’t truly grokked the unpolished and unported state of a lot of the DR software yet). He wound up quitting or being fired, and I can’t remember which.
Morale (in the form of a very friendly german shepherd doggie, who was capable of playing frisbee far beyond human endurance; very useful for destressing).
– – – –
Before the ST hardware started to work, we had to use existing 68000-based systems for cross development. The graphics guys had Apple Lisas that were running CP/M-68K; the Lisas had nice bitmap displays which we used as “practice” STs. The disks on these machines took forever to come back after a crash (tens of minutes). For some reason the boot code on these machines had been written to display a bitmap of a fish. You’d hear a mutter or curse from down the hall (crash), then the creaky footsteps of someone walking around, cooling their heels and waiting for their “God damned” Lisa Profile drives to boot, then a triumphant yell “CarpDOS!” and typing sounds.
The BIOS/OS guys had some Motorola VME-10 workstations that were (ahem) “Unix Ready!” (the boxes they came in said so, in large, proud letters) but instead we had them running CP/M-68K, and I’m sure they felt sad inside; I know I did. The VME-10 systems were very flaky; my own system died and needed repairs three times in six months. (A year and a half later, Gary Tramiel, the son who was heading the financial arm of Atari, asked us if we were still using the VME systems. By then we had moved all our development over to the ST itself, and the VMEs were gathering dust in a corner. “Hell no,” I said. “Fine,” said Gary, “Then we won’t pay the repair bill.” A good lesson in the Tramiel school of start-up economics).
– – – –
DRI had us housed in an old TV studio building (KMST, if you care) that was about a hundred yards from the rest of their buildings. The building was cold and creaky, and when it rained (which, during the fall and winter we were there, was a lot) the steps got pretty slippery.
Typical workday: Get up and do the usual stuff (coffee!) in our rented house in Carmel, two blocks from the beach. Usually we could hear the ocean, and sometimes I’d get quick beach fix in, if it wasn’t raining. Drive five miles to DRI, go up the creaky steps without breaking my neck. Make awful instututional-style coffee from the horrid little mylar bags of Columbian bridge-sweepings (put two in, just to make sure the coffee isn’t totally crappy).
Go into the office. Huh, the VME/10 won’t boot again. Flip power switch on and off for a while until it finally works (leave it on the rest of the day).
Make a backup right now because (a) it’s a nice, warm fuzzy feeling, especially when you can’t trust your stupid workstation to even fucking turn on, and (b) was the one I did last night at 1am really any good?
Flail about at drivers. Trace through file system code that mostly works, but sometimes doesn’t. Wish for working hardware. Try to decode the latest spec from the hardware guys. Stare at the ceiling (“That doesn’t make any sense.”) Stare at the wall (“That can’t possibly work.”) Write some more code anyway.
– – – –
There was a bug that had been causing all kinds of grief; some kind of simple botch. I’d spent half of the previous day working out exactly what was going on, and it turned out to be in some DRI code. I groaned. Not that guy again.
The DRI engineer responsible for that part of the system was notoriously arrogant. I tried to explain the problem to him, down to the offending line of code, and he was objecting all the way. But later I overheard him saying to his office mate, “Hey, I found a bug in my code that could explain that weird problem.”
This just drove us batshit.
I took a doggie break. One of the Atari engineers had a wonderful german shepard named Divot. You could take Divot outside with a frisbee and she’d play fetch until one of you dropped from exhaustion (and she could fetch for hours). It’s hard to get worked up about a screwed-up OS when someone is utterly dependent on you for the next frisbee toss.
“He’s a bozo, Divot.”
“So what if he came from HugeCorp and did systems programming on machines so big he couldn’t lift them; he’s a graduate of the Arrogant Jerk Academy and he doesn’t know how to interact with humans.”
“Woof, woof!” [Speaking of interacting, throw the stupid thing already, okay?]
I went back inside. Whereupon: Much more programming, a late-night run for chinese food of dubious quality, and work, work, work. One big happy family, hatching an operating system out of thin air and ego and fear. Oh yeah.
– – – –
CP/M-68K was an “Operating System” that had its roots in the 70s. About ten years earlier Gary Kildall had worked on some DEC PDP-11 systems, liked them, and had been inspired to write a small OS for the very early 8080-based microcomputers. For years CP/M had been a defacto standard. Gary had started a company called Inter-Galactic Digital Research to further develop and market it. MSDOS had only been out for a couple of years, and DRI (renamed — sensibly losing the Intergalatic bit so that people, especially conversative suit-types, would take them more seriously) was vying for market share with a port of CP/M to the 8086, the CPU of the IBM-PC.
CP/M-68K was a port the 68000, and was the OS that the Tramiels had contracted for.
CP/M (in any of its variants) didn’t really do a whole lot. There was a simple flat file system. There was some character-at-a-time console output (useless on a computer with a graphical interface). And CP/M could load and programs. That was about it. (By modern standards it was missing: A heirarchical file system with directories, networking, memory management, processes and process scheduling, a notion of time, synchronization and locking primitives, a driver architecture, graphics, fonts, character sets . . . you get the idea).
GEM was was bolted on top of this primitive base. Since the underlying OS didn’t support more than one task, GEM had a lot of its own stuff to enable things like “desk accessories” that could run concurrently with (say) a word processor. It was pretty clunky.
None of us liked CP/M-68K. So when we heard that someone at DRI had been doing something much better, even though it was still unfinished, we unofficially jumped at it. GEMDOS started as a skunkworks project by a DRI engineer who had a reputation for being a loose canon. GEMDOS had a heirarchical file system that was compatible with MSDOS; it had a few other improvements, but this was the biggie. But in December 1984 GEMDOS was still being written.
The STs that went to the CES show were running CP/M-68K. In late January, after a bunch of hand-wringing, Leonard Tramiel made the decision to go with GEMDOS. We’d had it substantially working for several weeks, and it looked like it was going to be fine. Notably we did not have any hard disks to try it out on, so all of our testing was done on floppy disk based systems — this would come back to hit us hard later.
– – – –
It was pretty clear that TOS was going to be late. But we had the boot code working fine, so we spent a few weeks doing a small 16K loader ROM. All it did was paint some pretty graphics, load a sector from floppy disk and run it. We sent the boot ROM images out without actually knowning if they’d boot an OS, but they worked fine.
Around the time the boot ROMs were sent off, the software team was feeling pretty blue. Things were taking much longer than we had expected; there were lots of bugs to fix, there were missing features, there were features that would never make it into the product, and it was pretty clear that the Mac had us outclassed. Also, most of us were feeling pretty burned-out.
Jack Tramiel called a meeting. We didn’t often meet with him, and it was a big deal. He started by saying, “I hear you are unhappy.” Think of a deep, authoritarian voice, a lot like Darth Vader, and the same attitude, pretty much.
Sorry, Jack, things aren’t going all that hot. We tried to look humble, but we probably just came across as tired.
“I don’t understand why you are unhappy,” he rumbled. “You should be very happy; I am paying your salary. I am the one who is unhappy. The software is late. Why is it so late?”
Young and idealistic, I piped up: “You know, I don’t think we’re in this for the money. I think we just want to ship the best computer we can –”
Jack shut me down. “Then you won’t mind if I cut your salary in half?”
I got the message. He didn’t even have to use the Force.
– – – –
We got busy again and shipped the first ROM-based systems a month or two later. My memory of this has really faded, but a few things stick:
TOS wasn’t going to fit even in the 192K of ROM. It was well over 200K (210? 220?) and still climbing. So for two weeks everyone dropped what they were doing and started removing code. It’s amazing how much stuff you can toss out if you really try. Our linker didn’t do dead-code stripping, but even if it had that wouldn’t have shown us the fat pieces of common code, the pathetic reimplementations of strlen and strcpy that were everywhere, and the useless crap and horrible layering that could be replaced with a few simple lines of code.
[I've since found that removing code is a great way to improve an existing system; not only do you get rid of a lot of bugs, but the result is usually easier to understand, and often runs faster. Have a large, unwieldy project that takes forever to build and you have trouble making changes to? Wade in and start deleting. Become a ruthless of constructive destruction; if you accidentally nuke something critical, just resurrect it from the project depot. Software is great!]
A little while after the first TOS ROMs shipped, Leonard Tramiel arranged a celebratory dinner for the engineers and managed to get Jack to come as well. About halfway through the meal (which was at a wonderful Chinese place called Fung Lum, in Campbell), Leonard started relating the story of how he and John Feagans had arrived at the Atari Coin-op building to interview people and see who they wanted to keep.
“Then this voice called out over the intercom –”
— oh, shit. One thing you need to know about Jack is that when he was twelve years old, he was in the concentration camp at Auschwitz. I’ve seen the tattoo. That he survived being there pretty much defined him, as far as most people were concerned. And —
“– and the voice called out, ‘Imperial storm-troopers have entered the base!'”.
Jack hadn’t seen Star Wars, not ever, and didn’t get the reference. And to him, the phrase “Storm Trooper” has a completely different meaning. It took a little while for Leonard to convince Jack that it was really a funny thing, no, honestly, really it was a joke, okay? And I’m not sure that Jack really understood. But in the end he gave a little laugh; everyone else seemed to enjoy the story.
I kept my job.
I hung on for another couple of years before going to Apple. There were some nasty bugs in GEMDOS that were never really fixed (you can download the sources — I did, a number of years ago, and found the same set of unsatisfactory fixes that I’d come up with, but that I’m not sure ever shipped). I took an ST with me, but I didn’t ever do much with it. I don’t keep in touch much with the people on the ST team; some light email, but that’s about it.
The ST community did really awesome things; some actual decent multi-tasking operating systems, a ton of music-related software and so on. It’s neat having had a part in helping all of that happen. I also know what I’d like to be able to do a second time around on a project like the ST. I’ve got this little list . . . .