Sony PRS-505 Review

I never leave the house without a book. Half of you are nodding, the other half shaking your heads. My parents were in the latter camp and didn’t understand, apparently thinking “capability equals intent” and that all I wanted to do all the time was read. Well, ahem, this was true, but mostly I have a horror of being caught flat-footed with nothing to do except stare at the walls for hours. Meditating monks might get something out of that; I go bonkers.

A few years ago I started reading books on my cell phone; it has a rudimentary HTML browser, so I put a couple hundred books on a flash chip. I can call ’em up any time I’m caught without a real book. The cell phone screen is not so bad after a while, but I’ve been tempted to do a bit of cell-phone development to add things like bookmarking and better scrolling. No time to actually write code for this, though.

My wife gave me a Sony PRS-505 book reader for my birthday. I’ve got a few hours on it (enough to run through a few books), and here are my impressions so far.

Everyone will tell you that the screen is drop-dead gorgeous. It is. It’s fantastic. The annoying second-or-so of flashing when you turn a page becomes much less annoying after a while; I really don’t notice it any more. The flashing is a small price to pay, believe me.

It does a wonderful job of being a book reader. Bookmark support is great, navigation is pretty painless, and button placement is decent. It handles plain text files wonderfully. Converted RTF files are not bad, either.

PDF support is there, but it is very weak. Paging through a PDF document is glacial, and the device doesn’t fully scale-up PDF documents. Reading a typical academic paper involves clicking “next page” (wait…) then “zoom” (wait…) whereupon you still can’t easily read the text. There is some transcoding software available that is supposed to address this, and a rumored, incipient flash update is also supposed to make PDF reading better.

I wish it supported HTML. Again, conversion software does a nice job here, but even simple support of (say) H1/H2/H3 and paragraph/line breaking (dumping everything else) would have made me happy.

The 505 will play music and show photos. I haven’t tried these.

I’m worried about what happens when the non-replaceable battery dies, but I’m handy with tools and this shouldn’t be a real issue when the thing’s battery does go under.

In short, the PRS-505 is a fine book reader, and with a little hacking of content (which itself an enjoyable task, mostly) I should be able to replace piles of papers and a backpack full of books with a few flash cards and a charger.

[Yeah, I’m still writing about old Atari days. It’s going slowly; I’m trying not to make it a super boring “we did things A, B, C in order.”]

Interim mumbling

[Still writing. Being a Dad and doing a bit of a crunch at work is taking precedence over scribbling. But here is a little piece I wrote a while back that attempts to make a (weak) connection between glowing pickles and the fundamental gulf between hardware people and software people: link]

[Well . . . and I’ve been playing Bully. Let’s just say that it’s been cathartic.]

The Atari ST (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.

Slashdotted [and Boinged]

I think the Slashdot / Reddit effect has more or less passed.  Phew.  My regular 12 (now, 11) readers should have no trouble getting to the site now.

Mom: “What’s the Slashdot effect?”

Oh man, that’s really going to be hard to explain… 🙂

Update: Welcome, Boing-Boingers.  (One of my favorite, er, “directories.”)  I hope the server holds up.

 

More wisdom

Every time you use “#define”, God kills a start-up.

The inability to spell is still no excuse for abbreviations like CUST_TBL and PROD_REM. At some point before this you’ve crossed into being lazy.  [It might have been an excuse in the days of 80 column punch cards, but you’ve got a 21″ monitor now, don’t you, you lazy bastard, and I’m not really worried that meaningful identifier names are crowding out the pixels currently devoted to Reddit and Facebook.  Really not.]

Donkey Kong and Me

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.

Never the twain shall…

Our little boy (“No: Big! I’m a *Big* boy”):

  • Loves apple juice
  • Loves dried apples (especially the ones his grandmother makes)
  • Hates apples (“Yuck!”)

It’s ironic.  I’d like to try mixing the two to see if he’ll eat the result.  (On the other hand, pleas along the lines of “But, it’s the same stuff that bread is made of!” to get me to eat cream-of-wheat never worked, and never will).

He also claims to like Brussel Sprouts, and I am tempted to try him on that.  Who knows?