The Atari ST story
Dadhacker
Any sufficiently advanced technology is insufficiently documented
PART 1
One friday afternoon in July, 1984 the rumor floated through the halls: Jack Tramiel had bought Atari, and we were all going to be killed. Or laid-off. Or something. My office-mate had worked at Commodore a few years earlier (where Jack had been CEO) and said “If this is true, I’m quitting. I’m not working for Jack again; he’s a monster.” I didn’t know anything about Jack, but this wasn’t a good sign.
On Monday the rumor turned out to be true. Like all important happenings at Atari — layoffs, major management shake-ups, bad financial news and so on — we found out through the San Jose Mercury News rather than an official internal announcement. The paper said that Jack Tramiel had bought Atari from Warner Communications, and he and his people were on the way to San Jose to take the company apart and kill us. Or lay us off. Or something. The Merc didn’t exactly say that Jack was a monster, but that he had a hard, no-nonsense management style. This wasn’t a good sign.
I remember spending a crazy couple of days trying to concentrate on my current project; I sure didn’t feel like doing much (I was working on a computerized Trivial Pursuit game, something we’d code-named “Trivial Compute,” and was learning a lot about data compression algorithms, but my heart just wasn’t in it). The hallways were buzzing with rumors of entire buildings-full of people who had been nuked.
It took a little while for them to get to us. On Wednesday two of Jack’s “lieutenants” arrived at our building (we consumer games folks had been co-located with the coin-op division to save money). Someone had phoned ahead and said that the Tramiels were coming over and that news spread like wildfire. When they showed up, someone said, “I see them! They’re walking in the front door!”. I dialed-up the building’s intercom system and announced:
“Imperial storm troopers have entered the base! Imperial storm troopers have — Urk!”
then hung up abruptly. (Later, one of the two said that the timing couldn’t have been more perfect; my announcement happened as they had begun marching down the main hallway on the way to meet with the people they were going to lay off…).
There were interviews. Fast interviews that might better be described as grillings. We each had about five minutes to talk with Leonard Tramiel (Jack’s son) and John Feagans (a long-time Commodore employee, and someone that the Tramiels trusted). They asked questions like: Do you have any experience writing operating systems? I told them that I’d read Lion’s notes on Unix, and about my CS coursework at Maryland and the tools work that I liked to do. Did I want to work on a new computer? Sure, that sounded kind of exciting. I might have mentioned Soul of a New Machine and stuff about compilers. My memory of this is rather vague; I recall having a private conversation with the two of them, but others have said that we were interviewed in groups of five or six. It might have been both.
A couple hours later we were told to meet in a common area. There were about sixty of us. “Do you want the news individually, or all at once?” We took a vote, and most of us (veterans of many, many layoffs) just wanted to get things over with quickly. Leonard read two lists of names. Those on the longer list, about two thirds of the people there, were the ones getting a package. Those on the shorter list would be working for the Tramiels, at least for a while. My name was on the shorter list.
It was unclear if it would be better to be laid-off or to work for these people; they were tight-lipped and nearly complete ciphers. Who were the lucky ones? There was no way to tell. I helped my now-ex-cow-orkers pack their offices and load boxes into their cars. Out of the cluster of six programmers and an artist, people who I’d worked with and survived layoffs with for years, I was the only one left.
There was a lot of stuff left behind, and a bunch of VAXes that I could mess around with nearly all by myself. It wasn’t all that much fun.
– – – –
All of us programmers got VP desks.
The Tramiels had bought a lot of stuff — by contract they could have anything they wanted of the Warner Atari’s assets — and we needed to set up our offices in the new building that engineering was being consolidated in. We were moving from the coin-op building (since Jack hadn’t purchased the coin-op business, the doors to that part of the building, now a separate company, had been locked) to a building in Sunnyvale that had belonged to Corporate Research. Most of the people in Research had been let go; Lisp Machines and Vaxes were humming away without anyone to use them. Jack wasn’t interested in academics.
It turned out that we could have nearly anything from the old Atari that we wanted, since it didn’t cost anything extra. While the Tramiels were selling the more expensive items (like the Vaxes and Symbolics Lisp Machines that the researchers had been using), more mundane stuff could be had for the asking. You could have just about anything you wanted, and as long as Jack didn’t have to write a check for it (and was something that he couldn’t sell to make quick cash), he didn’t care.
Anything?
“Well,” said somebody, “There’s this warehouse full of stuff in Santa Clara…”
So we went over there. Remember the last scene in the movie Raiders of the Lost Ark where they wheel the boxed-up Ark into a gigantic warehouse with acres of huge boxes and whatnot? This was like that, but for real. This warehouse (and others like it) was where the office equipment from all of the now-empty Atari buildings had gone; maybe fifty or sixty buildings’ worth.
I think that Jim Eisenstein, one of our graphics guys, started it. “I’ll take that one, there,” he said to one of the warehouse workers. Jim pointed at a really nice, large desk. “Okay,” said the fellow with the forklift, and he got it down. No argument. Pretty soon we had all chosen really nice, large desks (and some nice chairs) and tagged them for delivery. The guys running the forklifts didn’t care.
Dave Getreu and I shared an office for over a year (he was the guy whose version of Centipede I had bettered, but he was pretty decent about that). Our two desks barely fit, but it seemed worth it; a symbolic finger in the eye of the old, crappy Warner-Atari management. I don’t know who had used my desk before me, but it was sure nicer than anything I’d had, and my guess was that for every dollar that my efforts had earned the company that the former owner had blown at least two bucks down the toilet in bad deals and clueless management.
Rule of thumb: If your company has more VPs than it does bathrooms, you’re in trouble.
– – – –
The Tramiels had bought Atari with a plan to make a little money immediately by quickly selling off assets, and more intermediate-term money by making minor updates to the existing Atari product lines (the 400/800/1200 series of 8-bit computers), but the biggest effort was going to be a completely new line of cheap computers. There were some other products in various stages of development (the Atari 7800, whose major engineering work had actually been done outside Atari, at a small company named General Computer, a new sound chip code-named Amy, and some others) that the Tramiels kept lightly staffed.
The new computer was going to be based on a 16-bit or 32-bit processor. The Tramiels were initially pretty closed-mouthed about things; they had brought some folks from Commodore with them, and I got the impression that they didn’t trust us that much, and in addition there was a legal fight going on with Commodore over trade secrets. During the next month or two the design of the new system solidified. It was going to be based on a 32-bit processor, have a 16-bit bus (thus ST, for “Sixteen, Thirty-two”), have 256K of RAM and 128K of ROM. It was going to have a mouse and a graphical interface of some kind. At first the National 32000 series processor was a serious possibility, but in the end the Motorola 68000 won out. [In retrospect this was a good choice; National chips looked great on paper and had a nice, clean instruction set, like itty bitty Vaxes, but in reality they were very buggy and quite slow].
There were a number of candidates for the ST operating system. Leonard Tramiel gave us some GEOS documents to evaluate, as well as some specs on something called Crystal (from Digital Research Inc), and there were one or two other contenders. Frankly, none of the choices seemed all that great. Ultimately the Tramiels signed a contract with DRI to port CP/M-68K and the still-being-developed GEM user interface to our still-being-developed hardware.
The schedule for the ST was very aggressive; we were starting in August, more or less, and working systems needed to be ready for the Consumer Electronics Show in January. With lead-time for the custom chips measured in many weeks (I don’t remember exactly, perhaps 6 to 8 ), this didn’t leave much time for development. So while the hardware guys were spending 20 hour days frantically designing chips and wire-wrapping prototypes, the software guys were spending a lot of time at the beach.
No, really. The software team temporarily relocated to Monterey, 70 miles south of Silly Valley and on the California coast, which was where Digital Research was located. Initially we stayed in hotel rooms a short walk from the DRI campus, but after a few weeks Atari rented some houses for us in Carmel, just a few blocks from the world-class beaches there. I used to leave work around 5, watch the sunset over the ocean (because it would have been a shame to waste those), then go back and work really late.
Our first meeting with the folks from DRI did not go very well. One of their engineers tried to give us a chalkboard introduction to C (which I’d been using for five or six years at that point), and his “this is a for loop, this is a struct” talk didn’t go over very well (you can’t effectively teach a language in an hour like this anyway). Another engineer attempted a tutorial on assembly language (to video game programmers, ha). This attitude colored the whole Atari-DRI engineering relationship; in addition to the project’s incredibly short schedule, which put everyone under a lot of pressure, there was an uneasy division of turf: DRI got to call the shots on their code and architecture, while Atari had to make it work. Things didn’t always go smoothly; when we found bugs or design problems, egos sometimes got in the way and there was an occasional temper flare-up.
Stress: A number of us learned how to juggle. One of the DRI people had a nervous tick in the form of a “quacking” sound, and this spread through the group (a year later some of us were still doing it a little). The word “fine” became a pejorative: “Don’t worry, everthing will work out just fine.” How are you feeling? Fine, okay?
Getting access to working hardware was a problem. There was a wire-wrap prototype of the hardware in Sunnyvale, but it was flaky as hell and certainly not transportable. You could run something, have it crash, then wiggle a board slightly and have the code work just fine. There were attempts to get the software engineers hardware earlier, but they were always unreliable (e.g., big, expensive machine-wire-wrapped boards that almost worked, but that turned out to be just too dodgy to trust).
Wire-wrap: Imagine a board, say two feet by three feet, crammed with chips. On the flip side of the board are thousands of half-inch metal pins. Now, the pins have to wired-up to each other in order for the chips to talk, and the way you do this is to wrap a fine wire tightly around a one pin, run the wire up and about, then wrap it around the other pin and cut the wire. Hilarity ensues. There are thousands of wires to keep track of, and only so many colors of wire available. Little bits of wire will flake off, get buried and short out contacts. Wires will work themselves loose. Wires carrying signals at high speed will interfere with each other and cause ghost signals. Wires will break internally and invisibly, become unwrapped, mysteriously stop conducting electricity (sometimes), and this is all behavior that doesn’t include the simple boneheaded mistake of somebody mis-wiring two pins out of those thousands because they were short on sleep.
The nasty thing about wire-wrap prototypes was, if your code didn’t work, you could just shake the boards (there were three or four of them you could do this to), and if everything settled down right your code might actually run. Or bomb in a different, exciting way. Software progress was slow. There were attempts to get us more stable prototypes, but they never really worked that well.
Sometime in December we started getting chips from the fabs and the real hardware began to come to life. We booted the ST for the first time (it was exhilarating to see the floppy disk spin and seek under OS control — this is something that you take for utterly for granted until you have to make it work yourself).
The original budget of 128K of ROM was blown pretty early on, and we targeted 192K. Initially this was so that the machine could incorporate a built-in BASIC interpreter. Up until this point it was virtually unthinkable that you could ship a consumer computer without BASIC in ROM (the Apple II, the Commodore line, and all of the Atari computers had built-in BASIC).
DRI had a version of BASIC available, and one of our engineers (someone the Tramiels knew) was hired and given the task of porting it. I don’t remember precisely what went wrong, but it just didn’t happen. It’s possible that the DRI BASIC wasn’t very good, or was too full of platform-specific garbage to easily port, and it’s also possible that the engineer given the job just wasn’t up to it. Regardless, we started to realize that just the operating system alone was going to use up the entire 192K (and in fact, blew past it and had to be pared down during a 2-3 week crunching period just before we shipped the ROMs), and BASIC simply would not fit.
The other thing that was clear was that the software was going to be late; the ROM version wasn’t going to make it in time for CES. We had disk-based versions of the OS (called TOS, for “The Operating System” — catchy) booting, and that’s what we showed. The hardware guys doubled the amount of RAM in the system so the OS could live in RAM with room left over for applications.
Jack didn’t pay for all of the engineers to fly to Las Vegas, but he was willing to put us up in a hotel and get us CES badges if we arranged our own transportation, so a few of us did a road-trip. The show was fun; there was a lot of excitement and speculation about Atari’s new products. What people didn’t know is that there were only about five working ST systems in existence, and they kept dying on the show floor (possibly due to heat problems, bad connections, or barely-working custom chips going south) and had to be resurrected from time to time in a back room where techs were hidden away with soldering irons, a limited number of spare chips, and a liberal supply of invective.
We’d shown the ST to the public. Now we had to make it work.
PART 2
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.”
“Woof!”
“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 . . . .