Tag Archives: trs-80

Binning the Trash-80

The microcomputer landscape of 1980 looked very different than it had when the trinity of 1977 first hit the scene. The hackers and early adopters who first made the TRS-80 a success were a step closer to sane than the solder-iron-wielding crazies who had constructed Altairs in their garages out of a set of diagrams and a loose pile of chips, but only a step. Owning and operating a computer was still expensive and difficult, and the question on the lips of wives and girlfriends across the country — “But what is it really good for?” — did not have any particularly strong answers. By 1980, though, that was changing, sufficiently so in fact that segments of the population were beginning to purchase computers not out of fascination with the technology itself, but rather because of what the technology would allow them to accomplish. That was due to the work of all those early adopters, who hacked like mad to create useful things that would justify their time in the terms that matter most in a market economy, dollars and cents, and thus in turn buy them yet more time to hack.

The most celebrated of these early killer apps today, perhaps due to its having been featured on The Triumph of the Nerds documentary, is VisiCalc, the spreadsheet program whose basic approach is still echoed in the Microsoft Excel we all know and love (?) today. Introduced in late 1979, it gave accountants, small-business owners, and even home users compelling reasons to own a microcomputer — whether to calculate taxes or accounts receivable and payable, or just to keep the checkbook balanced. But there are other examples. The first crude word processing application was called The Electric Pencil; it predated even the trinity of 1977, appearing for the early kit computers in December of 1976. It took WordStar, however, to refine the concept into a program flexible and powerful enough to begin to replace the expensive specialized word-processing machines found on secretary’s desks around the country upon its release in September of 1978. dBase, the first programmable relational database for microcomputers, made its first appearance in 1979. And while they were seldom openly mentioned as a reason to buy these early computers, games were always present as a sort of guilty pleasure and secret motivator. They were still crude and limited in 1980, but growing by leaps and bounds in both ambition and sales as the first specialized entertainment publishers such as Adventure International got off the ground, and as new microcomputers much more suited for play began to appear in the wake of the Atari VCS game-console sensation which began sweeping the country in earnest during the holiday season of 1979.

Ah, yes, the new machines. As new applications showed how useful and/or entertaining computers could be in both businesses and homes and as their sales figures responded, plenty of new players came rushing into the market. Some, such as the Exidy Sorcerer and Texas Instruments 99/4, found little traction, becoming mere historical footnotes and modern collector’s items. Others, though, heralded major new technological and cultural developments. We’ll get to these at some point, but for this post let’s see if we can bring some sort of order — i.e., some categories — to the crazy quilt of microcomputers available by 1980. Oddities like the TI 99/4 (the world’s first 16-bit microcomputer based on a CPU of TI’s own design) aside, most computers were based on one of two 8-bit CPU architectures.

First there was the Intel 8080, the chip at the heart of the original Altair kit computer and its contemporaries, and the Z80, a mostly compatible CPU from Zilog that nevertheless offered a more flexible, efficient design; this, you may recall, was the chip Tandy chose for the TRS-80. Apart from the TRS-80, which for better and (as we shall shortly see) for worse remained largely its own thing, these machines generally ran the first widespread platform-agnostic operating system for microcomputers, CP/M (Control Program for Microcomputers). Developed by Gary Kildall at the very dawn of the microcomputer era and published by his company Digital Research, CP/M was the MS-DOS — or, if you like, the Microsoft Windows — of this early era, a de facto if not official standard that allowed machines from a huge variety of makers to share software and information. (There is also a more tangible link between CP/M and MS-DOS: depending on whom you talk to, the original MS-DOS from 1981 was either “inspired by” CP/M or an outright unauthorized reverse engineering of the earlier O/S. But that subject will doubtlessly come up again in later posts…) For a computer to run CP/M, it required two things: an Intel 8080 or Zilog Z80 CPU, and a certain standard bus design for communicating with its disk drives and other peripherals, known as the S-100 — a design which had its origins as far back as the original Altair.(UPDATE: As Jonno points out in the comments, an S-100 bus was not a strict requirement for CP/M.)

CP/M and the Intel- and Zilog-based architectures on which it ran became the standard environment for “serious” microcomputing of the late 1970s and early 1980s, the kind done in corporate offices and small businesses. WordStar and dBase were both born there, and VisiCalc, although conceived on the Apple II, quickly found its way there. CP/M had, however, no graphics capabilities at all and only limited support for real-time operations, making it problematic as a platform for many types of games and even educational software. It also relied upon the existence of at least one disk drive on its host platform at a time when such devices tended to be very pricy. These factors made CP/M and the 8080 a poor fit for the less expensive, usually cassette-based computers generally chosen by home users. That market was dominated by another hardware architecture, that of the MOS Technologies 6502 CPU.

When the 6502 first appeared in 1975, MOS was a tiny independent chip-maker, but that changed when Commodore purchased the entire company in late 1976. This move, one of the smartest that Commodore head Jack Tramiel ever made, left Commodore in the enviable position of making money not only when it sold its own machines such as the PET, but also every time a rival purchased 6502s for its own products. Said rivals initially included only Apple with its Apple II line and a number of kit-based computers from various small manufacturers, but that would change soon enough.

A CP/M equivalent for 6502-based machines was never developed, meaning that they remained largely incompatible with one another. BASIC did serve as a partial lingua franca, as virtually all of these machines housed a version of Microsoft’s industry-standard BASIC in their ROMs, but there was enough variation from implementation to implementation that most programs needed at least some customizing. And of course when one progressed beyond BASIC to assembly language to take full advantage of everything a 6502-based machine had to offer — especially graphics and sound, which capabilities varied wildly from model to model — one was faced with essentially coding everything from scratch for each machine one wished to support. Crazy times — although with the ever-increasing proliferation of incompatible mobile computing devices in our own times it’s starting to look like 1980 all over again.

What the 6502 world lost in compatibility it gained in flexibility. Freed from the need to work through a comparatively complex and inefficient OS like CP/M, programmers could code right to the metal on these machines, manipulating every element of the hardware directly for maximum efficiency. Further, the 6502-based machines, being generally aimed at the home and education markets, tended to feature the graphics and sound capabilities that were missing from the bland, textual world of CP/M; the Apple II, for instance, was the only member of the trinity of 1977 with support for proper bitmap graphics, a subject I’ll begin to discuss in more detail in my next post.

But now you might be wondering where all of this left the TRS-80, which fit neatly into neither of the two categories just described. Although the TRS-80 was built around the Z80 CPU, Radio Shack had chosen in the name of penny pinching not to implement the S-100 bus design. (UPDATE: As happens from time to time around these parts, this is not correct. Actually, the problem involved the memory map of the original TRS-80, in which ROM preceded RAM; a CP/M machine required the reverse. Thanks to Jonno for pointing this out in the comments.) This made CP/M a nonstarter. Despite being a huge success in its early years and still having the largest installed base of any microcomputer, the TRS-80’s future was, at least in retrospect, already clouded in 1980. Its incompatibility with CP/M left it cut off from the quickly growing base of serious business software found on that OS. In spite of the TRS-80’s relatively cheap price, Radio Shack’s reputation as purveyors of cheap junk for the masses did little to attract business users, and in a classic chicken-or-the-egg scenario this lack of business users discouraged developers from porting their products from CP/M to the little oddball Tandy machine. And in the other half of the microcomputer market, the 6502-dominated world of games machines and hobbyist computing, the TRS-80 was also looking like an increasingly poor fit with its almost complete lack of graphics and absolutely complete lack of sound. The arrival of the Atari 400 and 800, colorful 6502-based machines with superb graphics and sound for the time, and, a bit later in early 1981, the Commodore VIC-20, a much less capable machine in comparison but one nevertheless sporting color graphics and sound for an unprecedentedly low price, were particularly ominous signs.

While the wisdom of many of its moves is debatable, Tandy at least did not stand entirely still in the face of these developments. In fact, it released quite a blizzard of new machines, none of which came close to recapturing the market share the TRS-80 enjoyed in the late 1970s.

Tandy released a new machine called the TRS-80 Model 2 (the original TRS-80 being now retroactively renamed to the Model 1) in late 1979. The Model 2 was designed to capture the business computing market that was passing the Model 1 by; it sold with integrated disk drives and did properly implement the S-100 bus included bank-switchable ROM, thus allowing it to run CP/M. But it was also a much more expensive machine than the Model 1 and, most dismaying of all, completely incompatible with it. Thanks to Radio Shack’s usual lack of marketing acumen and genius for clunky, tacky-looking design as well as its high price, it was not a big success in the business market, while its incompatibility made it of little interest to existing Model 1 owners.

The Model 3 which appeared to replace the Model 1 in the summer of 1980, meanwhile, was rather forced on Radio Shack. The Model 1 had put out so much radio interference that, in an example of the boundless ingenuity that marked the early microcomputer era, people began writing programs to manipulate memory so as to make music using this interference along with a nearby transistor radio to pick it up. New FCC regulations for 1981 forced Radio Shack to build in proper RF shielding, and thus spoiled that particular kind of fun. In addition to fixing this issue, the Model 3 also sported a slightly faster version of the Z80 CPU and (hallelujah!) real lower-case letter support for both input and output amongst other modest improvements. Yet it did nothing to improve the Model 1’s meager display capabilities. And, in the one-step-forward two-steps-back dance that seemed to define Radio Shack, the Model 3 was optimistically said to be just “80%” compatible with the Model 1, while, once again, no S-100 bus meant no the design did not allow for CP/M. Radio Shack in their marketing genius now had three separate machines labeled the TRS-80, each now partially or entirely incompatible with its siblings. Just imagine trying to figure out what software actually worked on your version…

And incredibly, there was yet another completely incompatible TRS-80 released in 1980, this one the most significant of all. Although officially called the TRS-80 Color Computer, it was a radical departure from anything seen before, being built around perhaps the most advanced 8-bit CPU ever produced, the new Motorola 6809E. Like so many Radio Shack systems, it offered intriguing potential bundled together with some dismaying weaknesses. On the plus side were the powerful 6809E itself and an advanced Microsoft BASIC that made it a favorite among hobbyist programmers; on the weak side were sound and graphics capabilities that, while a step up from the other TRS-80 models, were still not competitive with new and upcoming models from companies like Atari and Commodore. In spite of that the CoCos, as they soon became affectionately known, had a long run during which they consistently flew under the radar of the mainstream, attracting little in the way of games or applications from most publishers or even from Radio Shack itself, but survived on the back of a sort of cult industry all their own sustained by a fanatically loyal user base. The CoCo line did not finally go out of production until 1991.

There are many more interesting stories to tell about Radio Shack’s quirky little computers, but none would ever come close to dominating the industry the way that the TRS-80 Model 1 did for those first few years. In truth, even the Model 1 was popular because it was widely available at a time when distribution channels for other brands were barely extant and because its price was reasonable rather than because of any sterling technical qualities of the machine itself. The TRS-80 was really not so far removed from Radio Shack’s other products: it basically got the job done, but in about the most uncool and unsexy way imaginable. It primed the pump of the home computer industry and brought adventure games into the home for the first time, but already in 1980 its time was passing.

So, we’ll bid adieu to the old Trash-80 and move on next time to look at the machine that made the company that has come to define cool and sexy in technology. Yes, I’m talking about those two plucky kids in that California garage.


Posted by on September 6, 2011 in Digital Antiquaria, Interactive Fiction



Robert Lafore’s Interactive Fiction

Quick: Who first coined the term interactive fiction? And why?

Assuming you had an answer at all, and assuming you’re a loquacious git like me, it may have run something like this:

The term originated, many years after the birth of the genre it describes, in the early 1980s with a company called Infocom. At that time, games of this sort were commonly known as “adventure games” or “text adventures,” the latter to distinguish them from the graphical brand of story-based games which were just beginning to compete with text-based titles in the marketplace of that time. Indeed, both terms are commonly used to this day, although they generally connote a rather “old-school” form of the genre that places most of its emphasis on the more gamelike, as opposed to literary, potentials of the form. Infocom decided that interactive fiction was a term which more accurately described their goal of creating a viable new literary form, and following that company’s demise the term was appropriated by a modern community of text-based storytellers who in many ways see themselves as heirs to Infocom’s legacy.

That, anyway, is what I wrote five years ago in my history of interactive fiction. I still think it describes pretty accurately Infocom’s motivation for replacing the term text adventure with IF, but it’s inaccurate in one important sense: the term did not actually originate with Infocom. It was rather the creation of a fellow named Robert Lafore, who founded a company under that name in 1979 and published software from 1980 to 1982 through Scott Adams’s Adventure International. By the time that Lafore came to AI, he already had three titles in the line ready to go. Local Call for Death and Two Heads of the Coin are mystery stories with an obvious debt to Dorothy L. Sayers’s Lord Peter Wimsey and Arthur Conan Doyle’s Sherlock Holmes respectively, while Six Micro-Stories presents six brief vignettes in a variety of settings and genres. Over the next year or so he wrote two more: His Majesty’s Ship Impetuous, in the style of C.S. Forester’s Horatio Hornblower novels; and Dragons of Hong Kong, in the spirit of Sax Rohmer’s Fu Manchu series of oriental mysteries.

To understand what Lafore’s concept of IF is and how it works, let’s begin with some promotional copy. After asking us to “step into a new dimension in literature,” Adventure International’s advertisement for the line continues:

Traditionally, literature has been a one-way medium. The information flow was from the novel to the reader, period. Interactive fiction changes this by permitting the reader to participate in the story itself.

The computer sets the scene with a fictional situation, which you read from the terminal. Then you become a character in the story: when it’s you’re turn to speak, you type in your response. The dialog of the other characters, and even the plot, will depend on what you say.

Wow. No previous computer “game” had dared to compare its story to that of a novel. Just the text above, divorced from the actual program it describes, demonstrates a real vision of the future of ludic narrative.

But as anyone who’s had experience with early computer-game ad copy knows, the reality often doesn’t match the rhetoric, with the latter often seeming aspirational rather than descriptive, corresponding more with the game the authors would like to have created than with the technical constraints of 8-bit processors and minuscule memories. Here’s a complete play-through of the first of the vignettes of Six Micro-Stories, “The Fatal Admission”:

Admittedly, this is not Lafore’s finest hour, so let’s try to be gentle. Let’s leave aside the fact that an admiral could only have been in the Kriegsmarine, not the Gestapo, as well as Lafore’s obvious cluelessness about German. Let’s also leave aside the illogicality of the question on which the story turns. (If I’ve been actively impersonating Colonel Braun for so long, how could I not know what flight wing I am with?) And let’s leave aside the unfair, learning-by-death aspect of the whole experience. I just want to get down to how the program works right now.

As will probably surprise no one, the program is not parsing the player’s responses in any meaningful sense, but rather doing simple pattern matching on the player’s input, somewhat in the style of Eliza but without even that program’s sophistication. Given this, it’s inevitably very easy to trip the program up, intentionally or unintentionally. Consider the following response to the admiral’s question about Captain Eiderdown:

What’s happened here is that the program has found the “not” in the player’s input and thrown out everything else, assuming the sentence to be a negative answer. This is not an isolated incident. Let’s try yet again to answer the trick question about the 57th Air Wing correctly and stay alive.

Cool! Now we can accept our new assignment and learn even more juicy Nazi secrets.

Woops. The program has failed to understand us entirely that time, which is at least better than a misunderstanding I suppose.

Obviously simple answers are the best answers.

Various vignettes in Six Micro-Stories do various things with the entered text. Perhaps the most complex and computationally interesting entry in the collection is called “Encounter in the Park,” in which you must try to get a date from a young lady you meet by chance in the park. It plays like a goal-directed version of Eliza, albeit a very primitive one. In case the connection is not obvious, the love interest’s name is even, you guessed it, Eliza.

The ultimate solution is ice cream; the mere mention of it causes Eliza to shed her sophisticated Updike-reading trappings and collapse into schoolgirl submissiveness. (The implications of this behavior in a paternalistic society like ours we will leave for the gender-studies experts.)

Another vignette is little more than a multiple-choice quiz on the age-old question of the definition of art.

And then there’s this nihilistic little number, in which nothing you type makes any difference whatsoever:

Lafore was either in a pissy mood when he wrote that one or homing in on some existential truth the rest of us can’t bear to face — take your choice.

But these are exceptions. When we get past the parser to look at the player’s actual options (thank God for BASIC!), we find that the remainder of the vignettes, as well as all of the vastly more compelling full-length stories, are really multiple-choice narratives, in which the player can choose from (usually) two or (occasionally) as many as three, four, or five options in a series of hard-coded decision points. In other words, these are really choose-your-own-adventure stories / hypertext narratives / choice-based narratives (choose your term). They are much closer to the Choose Your Own Adventure books that were just beginning to flood bookstores in 1980 than they are to the text adventures of Scott Adams or, indeed, to the interactive fiction that Infocom would soon be publishing. It’s just that their real nature is obscured by the frustrating Eliza-esque “parser” which adds an extra layer of guesswork to each decision. Sure, there are arguments to be made for the parser here. Theoretically at least, allowing the player to make decisions “in her own words” could help to draw her into the story and the role she plays there. In practice, though, the opportunities for miscommunication are so great that they outweigh any possible positives.

In a demonstration of just how ridiculously far I’m willing to go to prove a point, I reimplemented what I consider to be the most satisfying of the longer stories, His Majesty’s Ship Impetuous, using the ChoiceScript system. (Well, okay, I did want to try out ChoiceScript as well, and this project made a good excuse…) If you care to play it, you’ll find that it’s a much more complete and satisfying effort than those I’ve highlighted above, if not totally free of some of their design problems, in that getting an optimal outcome requires a bit of learning from death. Still, Lafore’s writing is sharp and well suited to the genre, and the story as a whole is carefully thought through; this represents easily the most competently crafted fiction yet to grace a computer screen in 1980. Its good qualities come through much better shorn of the Eliza trappings. Indeed, it’s much more interesting to consider in this light, because choice-based narratives had not yet made their way to the computer before Lafore set to work.

I don’t want to try to formulate a detailed theory of choice-based narrative design here, particularly because Sam Kabo Ashwell is gradually doing exactly that via his amazing series of analyses of various works in the form — a series to which nothing I say here can bear comparison. I do, however, want to note that parser-based and choice-based narratives are very different from one another, yet are constantly confused; Lafore was perhaps the first to make this mistake, but he was hardly the last. For example, the Usenet newsgroup that was the center of IF discussion for many years,, was originally founded by hypertext aficionados, only to be invaded and co-opted by the text-adventure people. And even today, the very interesting-looking Varytale project bills itself as “interactive fiction.” Choice of Games doesn’t go that far, but does actively encourage authors to submit their ChoiceScript games to IF competitions, something that doesn’t really bother me but that perhaps does bring two sets of expectations into a collision that doesn’t always serve either so well.

The primary formal difference here is in the granularity of the choices offered. Parser-based IF deals in micro-actions: picking up and dropping objects, moving from one concretely bounded space to another, fiddling with that lock in exactly the right way to get that door open. Choice-based narratives at their best deal in large, defining decisions: going to war with Eastasia or with Eurasia, trying to find your way back to the Cave of Time or giving up. Even when the choices presented are seemingly of an IF-like granularity, such as whether to take the left or the right branch in that dungeon you’re exploring, they should turn out to be of real consequence. A single choice in a choice-based narrative can encompass thousands of turns in a parser-based work of IF — or easily an entire game. When authors combine a choice-based structure with an IF-like level of granularity, the results are almost always unfortunate; see for example 2009 IF Competition entry Trap Cave, which attempted to shoehorn an Adventure-style cave crawl into a choice-based format, or Ashwell’s analysis of a Fighting Fantasy gamebook. A choice-based narrative needs to give its player real narrative agency — at the big, defining level of choosing where the plot goes — to be successful. Parser-based IF does not; it can let the player happily busy herself with the details while guiding her firmly along an essentially railroaded plot arc.

Given that they can tell such large swathes of story at a hop, we might be tempted to conclude that choice-based games allow deeper, richer stories. In a way that’s true, especially in the context of 1980; it would have been impossible to pack even 10% of the story of His Majesty’s Ship Impetuous into a Scott Adams-style game. It’s also true that choice-based narratives are generally not so much about challenging their players with puzzles or tactical dilemmas as they are about the “pure” experience of story. A contemporary reviewer of His Majesty’s Ship Impetuous writing in SoftSide magazine, Dave Albert, very perceptively picked up on these qualities and in the process summarized the joys of a choice-based narrative as well as some of the frustrations of Lafore’s early implementation of same:

Lafore has tried to write an open-ended story with several possible endings, and he has tried to structure it so that the reader/player is unaware of the import of the decisions made. Where in previous stories the player is allowed to ask any question that comes to mind (with often incongruous and confusing results), in Impetuous yes or no decisions are presented. There is no way to work around this structure, and it is greatly to the benefit of the program that such is the case. There is no puzzle to solve, only a story to develop. The end goal is to survive and the decisions that you make will dictate whether you do or not. However, you cannot decipher what is the proper course of action that will guarantee your success. There are enough critical points (decisions) in the program to make you uncertain of your actions after several games. This greatly enhances the value of the program.

I wouldn’t frame all the specific design choices in Impetuous quite so positively as Albert, but I think the larger points stand. Choice-based works encourage the player to view them from on-high, like a puppet master manipulating not just her character but the strings of the plot itself; note that Impetuous is written in the third-person past tense. The player manipulates the story, but she does not always feel herself to be in the story. Some more recent choice-based works have even divorced the player entirely from any set in-world avatar. Parser-based IF, however, excels at putting you right there, immersed in the virtual reality you are exploring. Both approaches are valid for telling different kinds of stories, creating different kinds of experiences, and both can go horribly awry. Too many choice-based works leave their player feeling so removed from the action that she ceases to care at all (this, I must admit, is my typical reaction when playing even the modern ChoiceScript games, and the main reason my heart belongs firmly to the parser-based camp); too many parser-based works, especially early ones, become so fiddly that they only frustrate.

Minus the parser frustrations, Impetuous is a fairly successful piece of work, written at an appropriate level of abstraction for the choice-based form. If many of its choices are ultimately false ones, having no real effect on the plot, it disguises this well enough that the player does not really realize it, at least on the first play-through, while enough choices do matter to keep the player interested. Best of all, and most surprisingly when we consider the structure of, say, the early Choose Your Own Adventure books, there are no arbitrary, context-less choices (will you go right or left in this dungeon?) and no choices that lead out of the blue to death. Some of its ethical positions are debatable, such as the way it favors plunging headlong into battle versus a more considered approach, but perhaps that’s par for the course given its genre.

One of the amusing and/or disconcerting aspects of writing this blog has been that I sometimes find myself honoring pioneers who have no idea they are pioneers. Lafore traded in his entertainment-software business after writing Dragons of Hong Kong for a long, successful, and still ongoing career as an author of technical books. I’m going to guess that he has no idea that the term he invented all those years ago remains vital while the works to which he applied it have been largely forgotten.

By way of remedying that at least a little bit, do give my implementation of His Majesty’s Ship Impetuous a shot. I think it works pretty well in this format, and is more entertaining and well-written than it has a right to be. (Credit goes to Lafore for that, of course.) And if you’d like to play the originals of either Six Micro-Stories or His Majesty’s Ship Impetuous, you can do that too.

1. Download my Robert Lafore starter pack.
2. Start the sdltrs emulator.
3. Press F7, then load “newdos.dsk” in floppy drive 0 and either “microstories.dsk” or “impetuous.dsk” into floppy drive 1.
4. Reboot the emulator by pressing F10.
5. At the DOS prompt, type BASIC.
6. Type LOAD “STORY:1″ for Six Micro-Stories; LOAD “STORY1:1” for His Majesty’s Ship Impetuous.
7. Type RUN.

Next time I want to have a look at the evolving state of the computer industry in 1980 — and begin to execute a (hopefully) deft platform switch.


Posted by on September 1, 2011 in Digital Antiquaria, Interactive Fiction


Tags: ,

A Busy 1980

When we last left Scott Adams at the end of 1979, he was poised to take this adventuring thing to the proverbial next level, with a solid catalog of games already available on a number of platforms, with perhaps the best name recognition in the nascent computer-game industry, and with a new company — Adventure International — ready to publish his works and the works of others under its own imprint. The following year saw him realize all of that potential and more, to take a place at the forefront of a new industry.

Adventure International grew by leaps and bounds for the next few years, while always remaining, like everything Adams touched, indelibly stamped with the personality of its founder. AI was the Dollar General of the early software industry. Its catalogs are filled with a ramshackle collection of software of every stripe. In addition to the expected text adventures from Adams and others (many of these also using Adams’s engine), there were arcade clones (“far superior to any Space Invader game for the TRS-80 microcomputer so far”, announces the blurb for Invaders Plus, with more honesty than legal wisdom); space strategy games (Galactic Empire and Galactic Trader); chess programs (“although a graphic display of the chessboard is provided, it is recommended that an actual chessboard be used during play…”); board game adaptations (Micropoly, which is once again foolish enough to advertise that it is a clone of Monopoly right in the promotional text); even TRS-80 Opera, which let one listen to the William Tell overture via a transistor radio set in close proximity to the machine’s cassette port (the TRS-80’s lack of proper RF shielding was not always such a bad thing). And for when fun-and-games time was over, there were also math programs, print spoolers, programming tools, drawing programs, and educational software to hand, the latter evincing the usual fascination with states and their capitals that was so common amongst early programmers. All of this software was relatively cheap, with $9.95 or $14.95 being the most common price points, and somewhat… variable… in quality. Still, there was a thrill to be had in walking the virtual aisles of the AI catalogs, gazing at the shelves groaning with the output of an expanding new industry, wondering what crazy (not to say hare-brained) idea would be around the next bend. Hovering over the whole scene was always the outsized personality of Adams himself, who would remain throughout AI’s brief but busy lifetime an unusually visible company leader. (A reading of the legal fine print shows AI itself to be merely “a division of Scott Adams, Inc.”)

The year 1980 represents an important historical moment for the entertainment-software industry. A few exceptions such as Microsoft and Automated Simulations aside, computer games had previously been distributed as a sideline by semi-amateurs who hung their Ziploc baggies up in the local computer store and signed up with the hobbyist distribution services run by SoftSide and Creative Computing magazines. Now, though, companies like AI and a few others that sprung up around the same time began to professionalize the field. Within a few years the Ziploc baggies would be replaced with slick, colorful boxes stuffed with glossy manuals and other goodies, and the semi-amateurs in their home offices and bedrooms with real development studios whose members did this stuff for a living. Computer games were becoming a viable business, bringing more resources onto the scene that would soon allow for bigger and more ambitious creations than anything yet seen, but also bringing all the complications and loss of innocence associated with monetizing a labor of love.

In light of the explosive growth of his company, it’s no surprise that Adams’s creation of new adventures slowed down dramatically at this point. Some of his energy was consumed — and not for the last time — with repackaging his already extant games. All received pen-and-watercolor cover illustrations courtesy of an artist known as “Peppy,” whose colorful if unpolished style perfectly suited the gonzo enthusiasm of Adams’s prose.

AI released just two new Adams-penned adventures in 1980: the Western pastiche Ghost Town in the spring and Savage Island Part One, first of a two-parter advertised as difficult enough for the hardcore of the hardcore, just in time for Christmas. I thought we’d take a closer look at the first of these to see how far Adams’s art had progressed since The Count.

The simple but painful answer to that question is: not at all, really. In fact, it has regressed in many ways. The Western setting was apparently merely the next on Adams’s list of genre touchstones to cover, as it does little to inform the experience of play. Ghost Town is a plotless treasure hunt, just like Adventureland; it’s as if the The Count never happened: “Drop treasures then score.” Sigh.

We rob the saloon of its cash box just because it’s there. Double sigh.

Worse, even as a treasure hunt Ghost Town is neither entertaining nor satisfying. A few quips such as the response to trying to GO MIRROR (“I’m not Alice!”) aside, Ghost Town has lost some of the friendly warmth that made one somewhat willing to forgive the earlier games their own dodgy moments. The useful HELP command with its little nudges and food for thought has disappeared entirely, while the puzzles have devolved into a veritable catalog of design sins. Adams had been slowly ramping up the difficulty of each successive game that he wrote, apparently expecting his player to work through the games in order and thus to be prepared by the time they faced Ghost Town. I suppose that’s a reasonable enough approach in the abstract, but in reality there is no way to train for the puzzles in Ghost Town. Even some of the least objectionable require considerable outside knowledge, of things like the composition of gunpowder or the translation of Morse code.

Of course, in 1980, a time when Wikipedia was not a browser bookmark away, tracking down this sort of information might require a trip to the local library.

Other puzzles require us to see the room in question exactly as Adams pictured it, despite his famously terse room descriptions that do little more than list the objects therein. Still others reward only dogged persistence rather than insight, such as requiring us to tote a shovel around the map and dig in every single room to see whether anything turns up. Yet more, the worst of all, are protracted battles with the parser. How long it would take the average player to divine that she must SAY GIDYUP to get the horse to move is something I don’t even want to think about — nor how long she might fruitlessly try mixing the charcoal, sulfur, and saltpeter together before finally just typing MAKE GUNPOWDER. At times the parser seems not just technically limited but intentionally cruel.

Typing just GUNPOWDER as opposed to WITH GUNPOWDER at the above prompt results in a generic failure message. My experience with Ghost Town makes me more enamored than ever of the idea that these early games were simply too technologically limited to support difficult puzzles that were also fair and logically tenable, that ramping up their difficulty beyond a certain rather low threshold inevitably resulted in nonsense like so many of the puzzles in Ghost Town and the absurd end-game of Adventure.

It’s also tempting to conclude that Adams himself simply lacked the vision to continue to push the text adventure forward. Tempting, but not entirely correct. For a couple of years Adams wrote an occasional column for SoftSide magazine. In the November, 1980, edition he announced a planned new adventuring system called Odyssey, which would take advantage of disk-drive-equipped systems in the same way as did Microsoft Adventure, using all of that storage space as an auxiliary memory store. His plans were ambitious to say the least:

1. More than one player in an Odyssey at one time. Players may help (or hinder) one another as they see fit!
2. Full paragraphs instead of “baby talk,” e.g., “Shoe the horse with the horseshoe and the hammer and nails.”
3. Longer messages;
4. sound effects; and
5. expanded plot lines.

To develop this system I have actually had to develop a new type of computer language which I call OIL (Odyssey Interpretive Language) which is implemented by a special Odyssey assembler that generates Odyssey machine code. This machine code is then implemented on each different micro, e.g. Apple, TRS-80, etc., through a special host emulator to simulate my nonexistent Odyssey computer.

Currently (as of the Washington computer show, Sept., 1980) the system is in the final stages of implementing a host emulator on a TRS-80 32 K disk system and writing the first Odyssey (which has been sketched out and is tentatively entitled Martian Odyssey) in OIL to run on the emulator. I hope that by the time you are reading this, Odyssey Number One will be available from your local computer store or favorite mail order house.

The technical conception of Odyssey sounds remarkably similar to what would soon be rolled out by a tiny Massachusetts startup called Infocom. Interestingly, Marc Blank and Stu Galley of Infocom had laid out in the abstract the design of their virtual machine, the “Z-Machine,” in an article in Creative Computing just a couple of months before Adams wrote these words. Could he have been inspired by that article?

Whatever the answer to that question, Martian Odyssey of course never appeared, and to my knowledge Adams never mentioned the Odyssey system again. For better and (ultimately) for worse, he elected to stick with what had brought him this far — meaning treasure hunts runnable on low-end 16 K computers equipped only with cassette drives. That strategy would continue to pay off handsomely enough for a few more years, yet it’s hard not to wonder about the path not taken, the territory ceded without a fight to Infocom and others. From 1980 on, Adams is more interesting as a businessman and an enabler for others than as a software artist in his own right. On that note, I want to talk about a few of the more interesting creations to stand alongside Adams’s own adventures in the jumble of the Adventure International catalog next time.

If you’d like to try Ghost Town, here’s a version you can load into the MESS emulator using its “Devices -> Quickload” function.


Tags: , ,

Temple of Apshai

In 1978 a fellow named John Connelley purchased a Commodore PET to aid in the bookkeeping of the Dungeons and Dragons campaign he was running. When he got the thing home and perhaps realized that the 8 K wonder’s utility for such a purpose was limited at best, he was afflicted with a bit of buyer’s remorse at the money he’d spent on it. Since he loved games, he hit upon the idea of writing one for the machine. Even if he didn’t sell enough copies to make any real money, he could at least use the project to justify writing the PET off on his taxes as a “business expense.” Unfortunately, Connelley was a better programmer than a game designer, and so his initial attempts went nowhere. In the end he turned to one of his D&D players, Jon Freeman, for help. Freeman was in just the opposite boat: he had been working for several years as a freelance games journalist and had a strong aptitude for game design, but knew nothing about programming. And so a marriage of convenience was born.

The first fruit of this union appeared before the end of the year in the form of a space strategy game called Starfleet Orion. To release it, Connelley and Freeman formed Automated Simulations, the first software publisher dedicated solely to games. Starfleet Orion looks rather bizarre when viewed through modern eyes, seeming more a sort of ludic construction set than a completed videogame. Its manual lays out an elaborate back story to justify a dozen space-battles scenarios between two alien races. The setup and order of battle for each of these is given, tabletop wargame style, in the manual; as the first step before actually playing one must key all of this data into the program and save it to a blank cassette using a separate program called BUILDER. In a touch that seems particularly bizarre to modern sensibilities, the BASIC source code for the game itself is also given in full in the manual, in case the player wants to tinker or the cassette on which the game is housed gets corrupted. Not only is Starfleet Orion two-player only, but it requires quite a time commitment; the manual estimates the climactic scenario to require about six hours to play, with no provision for saving state. Freeman and Connelley addressed these issues at least somewhat with Invasion Orion, a more accessible sequel with provision for solo play that they released early in 1979.

The really big release of 1979, though, took them out of space and into the dungeon. For Temple of Apshai, they brought in a third partner from their D&D group, Jeff Johnson, to help with an even more ambitious game design. Apshai was to be a full-fledged CRPG, drawing from the PLATO tradition of games like dnd, but also, in keeping with its designers’ background, paying very explicit homage to the deeper tabletop D&D experience that had brought them together in the first place. Its manual opens with a description of experiential gaming that is drawn straight from the tabletop RPG experience:

Role-playing games are not so much “played” as they are experienced. Instead of manipulating an army of chessmen about an abstract but visible board, or following a single piece around and around a well-defined track, collecting $200 every time you pass Go, in RPGs you venture into an essentially unknown world with a single piece — your alter ego for the game, a character at home in a world of demons and darkness, dragons and dwarves. You see with the eyes of your character a scene described by the “author” of the adventure — and no more. There is no board in view, no chance squares to inspect; the imaginary landscape exists only in the notebooks of the world’s creator (commonly called a referee or dunjonmaster) and, gradually, in the imaginations of your fellow players. As you set off in quest of fame and fortune in company with those other player/characters, you are both a character in and a reader of an epic you are helping to create. Your character does whatever you wish him to do, subject to his human (or near-human) capabilities and the vagaries of chance. Fight, flee, or parley; take the high road or low: the choice is yours. You may climb a mountain or go around it, but since at the top may be a rock, a roc’s egg, or a roc, you can find challenge and conflict without fighting with your fellow players, who are usually (in several senses) in the same boat.

Like the Orion games, Apshai foregrounds its experiential aspect. Games such as dnd quickly devolved into abstract exercises in tactics and strategy, with little thought paid to their fictional premise of dungeon exploration. Apshai, however, goes to great pains to try to get its player not to adapt that mindset. It plainly wants us to put ourselves right there in its dank dungeons, through the aforementioned proselytizing introduction; through an extended backstory justifying the existence of the dungeon you explore and describing a character you are free to imagine as your alter ego (“Brian Hammerhand”); and, most notably of all, through a set of D&D adventure module-style room descriptions the player is expected to read from the manual as she explores:

Room One — The smooth stonework of the passageway floor shows that advanced methods were used in its creation. A skeleton sprawls on the floor just inside the door, a bony hand, still clutching a rusty dagger, outstretched toward the door to safety. A faint roaring sound can be heard from the far end of the passage.

Unlike other early dungeon crawl games, whose dungeons were randomly generated or put together so haphazardly that they might as well have been, Apshai‘s dungeons are crafted to feel like a real place, even though that means that its monsters must be limited largely to sewer inhabitants (giant rats, various giant insects) and, on the lower levels that house the temple proper, various undead.

To be honest, all of this experiential gilding can feel a bit ridiculous to modern sensibilities because… well, to start, here’s what the actual game looks like in its original TRS-80 incarnation:

The fact that this display is a bit underwhelming is not the fault of Apshai‘s designers. The TRS-80 was limited to black and white (not gray-scale, mind — exactly two colors, black and white). Further, it wasn’t really capable of graphics at all in the way we think of them today, only character graphics. (In addition to a set of 64 commonly used English glyphs, it includes 64 more graphical tiles, each containing a simple abstract shape in lieu of a character glyph. By combining these together, it was possible to build larger pictures out of what remained essentially a text-only display.)

Viewed in the light of such a display system and the 16 K cassette-based computer on which it ran, Apshai is actually quite a technical achievement. Its rules also bear the stamp of an experienced game designer. They actually do not draw as heavily from D&D as one might expect given the game’s origins and the extended praise of the tabletop experience that fills its manual. While the expected six character attributes are present, and while they even number from 3 to 18 just like in classic D&D, combat and movement is very much its own thing here, a pseudo-real-time system that shows a willingness to harness the unique capabilities of the computer rather than just translate a pen-and-paper rules set into code. In fact, Apshai plays better in some ways than it has a right to; there’s a real tension to navigating through this labyrinth, deciding whether to press your luck and venture onward or turn for the exit, dreading the appearance of the next wandering monster as you do trudge back heavily wounded, having perhaps pressed your luck too far. There’s a visceral feel to the experience that many later dungeon crawls would fail to capture. This quality owes its existence partly to the real-time nature of play, but also to other choices that have no counterpart in tabletop D&D. As your character loses health, for instance, he moves more slowly, gets fatigued faster, and becomes less effective, bringing home his state in a palpable way. Freeman’s design is a very smart one, in many ways very original even in comparison to games that would follow.

But there are inevitable limits to what even a smart designer can do on a 16 K TRS-80. One can easily forgive the fact that magic is not present at all in the game; the player is restricted to playing what amounts to the D&D fighter class. Of more concern is the fact that the two components of the game, the “Innkeeper” which is used for character management, and the “DunjonMaster” where the dungeon delving actually happens, don’t really talk to one another. The player is expected to keep a list of her attributes and the items she finds in the dungeon on each expedition, then enter those manually when she returns to the Innkeeper! Rather than being linked together, the four levels of the dungeon can each only be entered separately; there is absolutely nothing preventing the player from entering a super-character into the Innkeeper and starting out on level 4. There’s not much point to methodical exploration anyway, as there is absolutely no way to really win the game. For all its emphasis on the experiential, one cannot bring Apshai to any conclusion. One merely explores, levels up, and collects until one gets tired of the whole thing.

Still, even dictated as it is by technical limitations, there’s an odd sort of charm to Apshai. Rather than delivering a story, it really does expect its player to work with it, to build a story that exists as much in the imagination as it does in the computer. “Sure, you are free to ‘cheat’ and create a character with stats of all 18,” it says, “but what fun would that be?” Similarly, if the game doesn’t deliver an ending like we’ve come to expect, that doesn’t prevent the player from making up one of her own. There is an encounter on level 4 that feels kind of like a climax — or maybe the player just sets her own goal of visiting every single room and collecting every single treasure. Apshai expects you to work with it to make your own fun. Anyway, as Freeman wrote of a tabletop RPG campaign, “It never stops, except temporarily: there is no final victory, no point to playing except playing, and no ultimate aim except the continuing development of your character.” Why should the computer equivalent be any different? Indeed, if played as its designers imagined Apshai doesn’t really feel like a pure computer game, but some hybrid — a computer-assisted solo RPG rather than a CRPG, if you like.

In an article in Byte magazine, Freeman described the differences between the RPG’s simulational approach to narrative and the text adventure’s preference for set-piece design, while leaving little doubt which he preferred:

There is no real role-playing, for instance, in the Adventure/Zork family: the protagonist is just you in a strange setting. Games of that sort concentrate on the perceived open-endedness of action: not only is there a multitude of command options available (typically far more than Dunjonquest‘s eighteen or so), but also they are not made known to you except by trial and error. It can be quite challenging to find the right key, the right moment, and the right command necessary to insert it in the right lock; but once you do, the door will always open — always. Thus, a game like Adventure is really a puzzle that, once solved, is without further interest.

The Dunjonquest series employs a different approach. For one thing, situations are primarily defined graphically, not textually: you see the situation rather than just being told about it. More to our present purpose, while some Dunjonquest games, like Morloc’s Tower, have a specific object (finding and slaying the mad and elusive wizard Morloc), there is an open-endedness of result in all of them on the micro level (if you’ll excuse a small pun). Generally speaking, there are no “right” answers; the outcome of events is probabilistic, not predetermined.

Brian Hammerhand, the assigned alter ego/protagonist of Morloc’s Tower and The Datestones of Ryn, can, for example, slay a dire wolf nine times out of ten, but on any particular occasion he may survive the encounter unscratched, or limp away badly mauled and out of breath — and there is also that tenth time. Moreover, the exact outcome of any encounter depends both on the tactics you choose and on the specific traits of your surrogate character. The experience is different every time you play and quite different with each new character you take on your adventure. You are role-playing: getting outside yourself and into the skin of another (albeit imaginary) being.

The contention that the simulational approach leads to role-playing while the set-piece approach does not is highly suspect — although we should remember that at the time Freeman wrote this passage IF protagonists were universally of the “nameless, faceless adventurer” type. Still, the tension between the two approaches that Freeman describes here remain with ludic narrative right up to the present, often within the same design. We’ll doubtlessly be revisiting the topic many more times as we continue on this little historical journey.

If you’d like to experience Temple of Apshai for yourself, here are some instructions to get you started. Note, however, that you’ll need the patience of a saint; by modern sensibilities the original TSR-80 version is all but unplayable, what with the sloooooow speed of its screen updates and the aforementioned divide between the two halves of the program.

1. Download my neat little Temple of Apshai starter pack.
2. Start the sdltrs emulator.
3. Press F7, then load “newdos.dsk” in floppy drive 0 and “apshai.dsk” into floppy drive 1.
4. Reboot the emulator by pressing F10.
5. At the DOS prompt, type BASIC.
6. Type LOAD “INN:1”.
7. Type RUN.

The manual and quick reference card in the zipped download above should see you through the rest.

We’ll continue to check in on the developing CRPG in the future, but next time we’ll get back to text adventures, and see what our old friend Scott Adams got up to as the 1980s began.


Tags: , , ,

Microsoft Adventure

There’s a good chance that you’ve received a forwarded email at least once or twice during the past ten years or so with the photograph above and a snarky caption such as, “Would you have invested?” The picture shows eleven of the thirteen Microsoft employees as of December 7, 1978, just before the company decamped from its first home in Albuquerque, New Mexico (initially chosen because it was the home of Microsoft’s first customer, the now increasingly irrelevant MITS) for the big time in Seattle. The twelve-year-old at the bottom left is of course Bill Gates himself… and, believe it or not, he’s actually already 23 there.

Ah, what can I say about Bill? I suppose you don’t become a multi-billionaire without leaving some bruised egos in your wake, but old Bill has always had a special knack for pissing people off and generally coming off like the computer industry’s own version of Darth Vader. In the abstract, I’m not sure that he was really so much more evil than most of his peers. Even by the time this photo was taken, the digital utopianism of the People’s Computer Company and Creative Computing was beginning to take a beating from a whole lot of would-be titans of industry looking to get a piece of the new microcomputer action — people like Commodore head Jack Tramiel, who announced that “business is war” and then wondered why all of his business partners and employees were so surprised when he lied to them and betrayed them; or like Steve Jobs, who even before co-founding Apple swindled his best friend out of a $5000 bonus he had earned doing his job for him, disingenuously prattling on about hippie togetherness and Eastern philosophy all the while. Perhaps the closest to moral in this lot was the management of Tandy, who were so unimaginative and so out of touch with their competitors that they couldn’t really be bothered to actively try to wrong them.

The big difference with Gates was that he was so damned good at being evil. While everyone else wound up to one degree or another hoisted from their own petards for their misdeeds, Gates just prospered. He wasn’t so much immoral as amoral. Unlike Tramiel, who seemed to positively revel in his evil, or Jobs, who desperately wanted to be seen as the good guy whatever dirty tricks he was pulling behind the scenes, Gates seemed utterly indifferent to his image and utterly disinterested in the niceties of right and wrong. On a personal level, he seems to have inspired something between ambivalence and out-and-out dislike in everyone who wasn’t directly depending on him for their salary (or, perhaps, the latter group just couldn’t speak up about it). It wasn’t just that his personal hygiene left as much to be desired as his interpersonal skills. Nor was it just that he displayed all the arrogance of both a brilliant programmer and the Harvard scion of a prosperous family; that was to be expected, considering that he was both of these things. No, it was the sheer magnitude of Gates’s need to win and to dominate those around him that made him downright disturbing to be around for so many people. If Gates couldn’t win at something fairly, one never doubted that he would cheat. Hell, if he could win at something fairly but it was just easier to cheat, he’d probably choose the latter course there as well. But, here’s the thing: Gates always cheated smart. If ethics didn’t mean much to him, he was very aware of legalities, and always careful to make sure that even at his shadiest he stayed on the right side of that line. (Of course, he became increasingly less good at that in the 1990s, but that’s a story for another time…) Remember the blinkered MIT nerds that Joseph Weizenbaum railed against in Computers and Human Reason? Well, the young Gates fit that stereotype perfectly, with an added heaping measure of cold-blooded ruthlessness. His wasn’t a personality likely to win a lot of friends. As an investment opportunity, however…

The story of Microsoft Adventure provides a good early illustration of both the very real technical and marketing acumen of Gates’s company and its genius for ignoring ethical considerations while still staying on the right side of the law. It provides an early example of what was already becoming the company’s modus operandi, one guaranteed to piss off idealistic hackers as much as it would delight its financial backers. And, not incidentally, it also represents a very important moment in the continuing evolution of adventure games.

In 1979, fully two years before Gates’s genius stroke in partnering with IBM on the original IBM PC, Microsoft was already a very big fish in the still relatively small pond that was the microcomputer industry of the era, having built a strong business upon the solid foundation of that initial Altair BASIC. In fact, Microsoft was simply the company to go to for a microcomputer BASIC implementation; it provided not only the TRS-80 Level 2 BASIC, but also the BASICs in the Commodore PET and the just-released Apple II Plus. It had also already expanded into other high-level programming languages, producing the first implementations of FORTRAN and COBOL to appear on microcomputers. Microsoft Adventure was part of a new initiative for 1979, the Microsoft Consumer Products Division, which aimed to market games and less esoteric applications to everyday consumers. The division as a whole was arguably somewhat ahead of its time, and would not be a rousing success in the long term. (Microsoft gave up on it within a few years to focus almost exclusively on technical and business products, and, the long-lived oddity Flight Simulator aside, would not begin marketing games and applications directly to home users once again until the 1990s.) For now, though, Consumer Products was big at Microsoft. With adventure games becoming so big on the TRS-80, when an employee named Gordon Letwin said he could port the original Crowther and Woods Adventure, something of a semi-legendary holy grail to microcomputer adventurers, onto the little machine, the go-ahead wasn’t long in coming.

Gordon Letwin is the bearded, black-haired fellow at the far right of the second row in the picture above. Born in 1952 and thus three years older than Bill Gates himself, his character and background is not too far removed from that of other hackers we’ve already met on this blog. A withdrawn, almost disturbingly nonverbal personality, Letwin read non-fiction books by the dozen throughout his childhood and teen years. Upon entering Purdue University as a physics major (the same major Will Crowther had chosen a decade earlier), Letwin found his real calling in the university’s computer center. After university, he got a job with Heath Company, who were well known among electronics hobbyists of the time for their “Heathkits,” do-it-yourself kits that let hobbyists build test equipment, amplifiers, radios, even televisions. In 1977 the line was expanded to include a computer, the H8, for which Letwin designed a simple operating system called H-DOS. He also designed a BASIC of his own, but a young and aggressive Gates, much to Letwin’s chagrin, dropped in on Heath while making the rounds of microcomputer manufacturers to try to convince them to buy Microsoft’s version. Letwin did something interesting, something that few others would ever do: he stood up to Gates. In Gates’s own words:

“There are different ways to do this stuff. His had some advantages which he was pointing out to me. We ended up in this argument between two technical guys. There were about 15 people in the room and no one else could follow along. We’re talking all in terms of data structure, single representations, double scan, stuff like that… Like if you typed a bad line, his would immediately check the syntax, and mine wouldn’t. Which is one of the negative points of our design. Anyway, he was being very sarcastic about that, telling me how dumb that was.”

Deciding perhaps that the adage that no one ever got fired for buying Microsoft was true even in 1977, Heath’s management elected to replace Letwin’s in-house design with Microsoft’s BASIC. This left them with one very angry Letwin. Gates, who whatever his other failings knew talent when he saw it, poached him for Microsoft about nine months later, not too terribly long before the above photograph was taken.

Although Letwin and his wife lived very modestly even years after Microsoft had made them wealthy, he more so than most hackers always knew the value of a buck, and always wanted to get what was coming to him. A 1988 Seattle Times profile alleges that he was a major impetus behind the decision of Gates and Paul Allen to transform Microsoft from a partnership to a corporation in 1981, and to grant him and other early employees like him the shares that would make them very rich indeed by the end of the decade. I mention this here because it may explain something odd about Microsoft Adventure: it was published by Microsoft, but allegedly developed by an entity called Softwin Associates, a company that apparently consisted of only Letwin himself. It seems that Letwin developed Adventure as something of a moonlighting project, then licensed it back to his employer. Why do it that way? Well, doing so gave Letwin the ability to collect royalties on sales as an outside contractor, above and beyond his regular employee salary. That the very finances-focused Gates let him get away with such a scheme probably says a lot about his perceived value to the company.

As Microsoft claimed in the instruction manual, “With Microsoft Adventure, you have the complete version of the original Adventure. Nothing has been left out of the original DEC version.” That stands as quite a neat trick; remember that Scott Adams, himself an experienced programmer, had not even tried to do a direct port but had instead developed Adventureland as its own, much smaller game. How did Letwin manage it?

He first of all took advantage of Radio Shack’s expansion interface, which allowed the user both to expand memory beyond 16 K and to replace cassette-based storage with floppy disks. This was a bold choice in its way, dramatically limiting the potential buyers of Adventure; in its September, 1979, issue, SoftSide reported that “only a few” of its readers had yet bought Radio Shack’s $500 disk drive. Yet Adventure would have been impossible without it.

The benefits of expanded memory were obvious in allowing longer and more complex programs, but those of the floppy disk were both obvious and more subtle. On the obvious level, the floppy was superior to the cassette in every way, allowing users to store much more data on a single piece of media and to save and retrieve it many times faster and with many times the reliability. But another attribute of the floppy would be key to the implementation of major games like Adventure given the still tiny amount of memory 32 K actually is. Unlike the cassette, the floppy was a random-access storage device, meaning the TRS-80 could be programmed to load into memory chunks of data from all over the disk as a program ran. By comparison, reading from the cassette required that the user manually position the tape in the correct position using the player’s counter, then press play… and then, of course, wait, for up to 20 minutes just to load one of Scott Adams’s simple adventures. With a disk drive, then, Letwin could leave all of that text that was stored in an external file even in Crowther and Woods’s original on the disk, loading in only the bit and pieces that he needed as they were needed. He needed only pack the core code of the game itself into his 32 K — not that that was a trivial task in itself, requiring as it did that Letwin port the original FORTRAN code into Z80 assembly language while optimizing everywhere for speed and size. Letwin’s pioneering use of the disk drive as a sort of auxilliary memory would soon enough be everywhere, refined to something of an art by companies like Infocom. Countless classic games would have been simply impossible without it.

The arrival of disk drives also brought with them another, less welcome innovation: copy protection. Every computer has a standard format in which it arranges data on its disks. To simplify rather extremely, locations on the disk are broken down into track and sector numbers, with a master directory stored in some standard location that records all of the files stored on the disk and their location by track and sector; this allows the computer to locate and retrieve files as they are requested. Most early disk copying programs assumed that the disk being copied would be laid out in this standard format, and would simply attempt to copy each file they found in the master directory over to the new disk one by one. It was, however, relatively easy for a program like Adventure to replace the standard disk format with one of its own devising — one that it knew how to read, but which would completely flummox another program expecting a standard format. By later standards, Adventure‘s copy protection was relatively simple, just rearranging the numbering scheme used to identify the different sectors on the disk. It was also relatively kind in allowing at least those with two disk drives to make a single backup copy by entering a special command within the program itself. Later protection schemes would get much more sophisticated, and much less kind.

Microsoft Adventure also points toward the future in its packaging. It shipped in a real box with real, professionally produced artwork and a multi-page, glossy manual written by Dottie Hall. Contrast this with the packaging of the early Scott Adams games, constructed from a plastic sandwich bag, a business card, and a baby formula liner. In 1979, Microsoft was one of the few software companies with the resources to give its products a professional presentation. As the games industry grew more professional and profitable, however, packaging would become a huge part of the whole experience of adventuring, reaching glorious (some might say absurd) heights of lurid artwork, lengthy manuals, included novellas or even novels, elaborate maps (sometimes from cloth or parchment), and evocative physical props (“feelies”).

Microsoft Adventure also started another, related trend that became almost as prevalent: its artwork has almost nothing to do with the actual game it represents.

I certainly never imagined the jokey response to “KILL DRAGON” (“CONGRATULATIONS! YOU HAVE JUST VANQUISHED A DRAGON WITH YOUR BARE HANDS!”) playing out quite like that. Although, I guess with sufficient imagination…

Having dwelt on the original DEC versions at length, there’s not really that much to say about the actual playing experience of the version of Adventure that Letwin developed. It is exactly what Microsoft claimed it to be, a slavishly faithful port of the original, minus only such PDP-centric niceties as “cave hours.” I suspect that most of the in-game text is literally the same as that on the PDP original, being the original’s external data file simply copied over to a TRS-80 floppy. Interestingly, Letwin does make an effort to ease some of the original’s more nonsensical puzzles. In the original, for instance, one could earn the “last lousy point” only by dropping the Spelunker Today magazine at Witt’s End, a completely unmotivated action; in Letwin’s version, reading the magazine yields the vital clue that “ITS ADDRESSED TO WITTS END!” Even better, the richly described but previously useless “Breath-Taking View” now has a purpose of sorts, for Letwin adds a single line that helps out with another notorious puzzle: “WORDS OF FIRE, APPARENTLY HANGING IN AIR, SAY ‘PLOVER.'” What a guy!

Nudges like that aside, Letwin makes just one addition, the “Software Den.”





Messing with any of the computers results in:








Talk about your delusions of grandeur…

But now we come to the elephant in the room: the question of credit. At no place in the Microsoft Adventure program or its accompanying documentation do the names of Crowther and Woods appear. We are told only that “Adventure was originally written in FORTRAN for the DEC PDP-10 computer,” as if it were the result of a sort of software immaculate conception. Needless to say, Crowther and Woods were never contacted by Microsoft at all, and received no royalties whatsoever for a program that by all indications turned into quite a nice seller for the company; it was later ported to the Apple II, and was one of the programs IBM wanted available at day one for the launch of its new PC in 1981. Because Crowther and Woods, immersed in old-school hacker culture as they were, never even considered trying to assert ownership over their creation, Microsoft violated no laws in doing this. However, the ethics of cloning someone else’s game design and lifting all of their text literally verbatim, and then copy protecting it (the irony!) and selling it… well, I don’t think that calling it “ethically dubious” is going too far out on a limb. In his famous “Open Letter to Hobbyists” of 1976, Gates asserted the moral right of the creators of software to have control over their creations. How to reconcile that stance with Microsoft Adventure? Incidents of commercial co-option of free software like this one are what eventually led to the creation of licenses like the GPL, designed to make sure that free software stays free. If you’ve ever wondered why so many in the open-source communities are so obsessed with the vagaries of licenses, maybe stories like this one will give an idea.

Be that as it may, Gates now seems as dedicated to doing good in the world and giving away his money as he once was to crushing his business competition and amassing it, to which I give a big hooray. I’d say that saving a single child makes up for the dubious aspects of Microsoft Adventure many times over. Gordon Letwin, meanwhile, also stayed with Microsoft for many years, going on to head the ill-fated OS/2 project before retiring on all that stock in 1993. He now also devotes himself to charity, specifically to environmental causes. A second hooray there.

Ironically, Microsoft Adventure is such a perfect clone of the original that it is now the ideal choice of anyone who wants to experience said original in as authentic a form as possible without building a whole virtual PDP-10 of their own. I’ve made a TRS-80 disk image of it available here, which will stay up as long as Microsoft’s lawyers don’t come after me for pirating their stolen 32-year old software and talking bad about their “non-executive chairman,” but for an easier time of things you might want to hunt down the IBM PC version on an abandonware site. If you do go with the TRS-80, you’ll have to play it using the SDLTRS emulator rather than the MESS version, as, due to the on-disk copy protection mentioned earlier, the disk image has to be stored in the “DMK” format — a format that MESS unfortunately cannot read. Really sorry about that!

I’ll be looking at text adventures in 1980 — a very exciting year — soon. But next I want to make a little detour into some theory and then into another genre of story-oriented game.


Tags: , ,