RSS

Tag Archives: trs-80

A Pirate’s Life for Me, Part 3: Case Studies in Copy Protection

Copy-protection schemes, whether effected through software, a combination of software and hardware, or hardware alone, can and do provide a modicum of software protection. But such schemes alone are no better forms of security than locks. One with the appropriate tools can pick any lock. Locks only project the illusion of protection, to both the owner and the prospective thief.

Our focus on copy protection is the primary reason why our industry’s software-protection effort has come under skeptical scrutiny and intense attack. Many users now consider the copy-protection scheme to be just an obstacle to be overcome en route to their Congressionally- and self-granted right to the backup copy.

Dale A. Hillman
President, XOR Software
1985

An impregnable copy-protection scheme is a fantasy. With sufficient time and effort, any form of copy protection can be broken. If game publishers didn’t understand this reality at the dawn of their industry, they were given plenty of proof of its veracity almost as soon as they began applying copy protection to their products and legions of mostly teenage crackers began to build their lives around breaking it.

Given the unattainability of the dream of absolute protection, the next best thing must be protection that is so tough that the end result of a cracked, copyable disk simply isn’t worth the tremendous effort required to get there. When even this level of security proved difficult if not impossible to achieve, some publishers — arguably the wisest — scaled back their expectations yet further, settling for fairly rudimentary schemes that would be sufficient to deter casual would-be pirates but that would hardly be noticed by the real pros. Their games, so the reasoning went, were bound to get cracked anyway, so why compound the loss by pouring money into ever more elaborate protection schemes? Couldn’t that money be better used to make the game themselves better?

Others, however, doubled down on the quixotic dream of the game that would never be cracked, escalating a war between the copy-protection designers who developed ever more devious schemes and the intrepid crackers of the scene, the elite of the elite who staked their reputations on their ability to crack any game ever made. In the long term, the crackers won every single battle of this war, as even many of the publishers who waged it realized was all but inevitable. The best the publishers could point to was a handful of successful delaying actions that bought their games a few weeks or months before they were spread all over the world for free. And even those relative successes, it must be emphasized, were extremely rare. Few schemes stood up much more than a day or two under the onslaught of the scene’s brigade of talented and highly motivated crackers.

Just as so many crackers found the copy-protection wars to be the greatest game of all, far more intriguing and addictive than the actual contents of the disks being cracked, the art of copy protection — or, as it’s more euphemistically called today, digital-rights management or DRM — remains an almost endlessly fascinating study for those of a certain turn of mind. Back in the day, as now, cracking was a black art. Both sides in the war had strong motivations to keep it so: the publishers because information on how their schemes worked meant the power to crack them, and the crackers because their individual reputations hinged on being the first and preferably the only to crack and spread that latest hot game. Thus information in print on copy protection, while not entirely unheard of, was often hard to find. It’s only long since that wild and woolly first decade of the games industry that much detailed information on how the most elaborate schemes worked has been widely available, thanks to initiatives like The Floppy Disk Preservation Project.

This article will offer just a glimpse of how copy protection began and how it evolved over its first decade, as seen through the schemes that were applied to four historically significant games that we’ve already met in other articles: Microsoft Adventure for the TRS-80, Ultima III for the Apple II, Pirates! for the Commodore 64, and Dungeon Master for the Atari ST. Sit back, then, and join me on a little tour through the dawn of DRM.

Microsoft Adventure box art

The release of Microsoft Adventure in late 1979 for the Radio Shack TRS-80 marks quite a number of interrelated firsts for the games industry. It was the first faithful port of Will Crowther and Don Wood’s perennial Adventure, itself one of the most important computer games ever written, to a home computer. It accomplished this feat by taking advantage of the capabilities of the floppy disk, becoming in the process the first major game to be released on disk only, as opposed to the cassettes that still dominated the industry. And to keep those disks from being copied, normally a trivially easy thing to do in comparison to copying a cassette, Microsoft applied one of the earliest notable instances of physical copy protection to the disk, a development novel enough to attract considerable attention in its own right in the trade press. Byte magazine, for instance, declared the game “a gold mine for the enthusiast and a nightmare for the software pirate.”

Floppy Disk

The core of a 5¼-inch floppy disk, the type used by the TRS-80 and most other early microcomputers, is a platter made of a flexible material such as Mylar — thus the “floppy” — with a magnetic coating made of ferric oxide or a similar material, capable of recording the long sequences of ones and zeroes (or ons and offs) that are used to store all computer code and data. The platter is housed within a plastic casing that exposes just enough of it to give the read/write head of the disk drive access as the platter is spun.

The floppy disk is what’s known as a random-access storage medium. Unlike a cassette drive, a floppy drive can access any of its contents at any time at a simple request from the computer to which it’s attached. To allow this random access, there needs to be an organizing scheme to the disk, a way for the drive to know what lies where and, conversely, what spaces are still free for writing new files. A program known as a “formatter,” which must be run on every new disk before it can be used, writes an initially empty framework to the disk to keep track of what it contains and where it all lives on the disk’s surface.

In the case of the TRS-80, said surface is divided into 35 concentric rings, known as “tracks,” numbered from 0 to 34, with track 0 lying at the outer margin of the disk and track 34 closet to the inner ring. Each track is subdivided along its length into 10 equal-sized sectors, each capable of storing 256 bytes of data. Thus the theoretical maximum capacity of an entire disk is about ((256 * 10 * 35) / 1024) 87 K.

Figure 1

Figure 1 (click to expand)

Figure 1 shows the general organization of the tracks on a TRS-80 disk. Much of this is specific to the TRS-80’s operating system and thus further down in the weeds than we really need to go, but a couple of details are very relevant to our purposes. Notice track 18, the “system directory.” It’s just what its name would imply. The entire track is reserved to be the disk’s directory service, a list of all the files it contains along with the track and sector numbers where each begins. The directory is placed in the middle of the disk for efficiency’s sake. Because it must be read from every time a file is requested, having it here minimizes the distance the head must travel both to read from the directory and, later, to access the file in question. For the same reason, most floppy-disk systems try to fill disks outward from the directory track, using the farthest-flung regions only if the disk is otherwise full.

The one exception to this rule in the case of the TRS-80 as well as many other computers is the “boot sector”: track 0, sector 0. It contains code, stored outside the filesystem described in the directory, which the computer will always try to access and execute on boot-up. This “bootstrap” code tells the computer how to get started loading the operating system and generally getting on with things. There isn’t much space here — only a single sector’s worth, 256 bytes — but it’s enough to set the larger process in motion.

Figure 2

Figure 2

Figure 2 shows the layout an individual disk sector. This diagram presumes a newly formatted disk, so the “dummy data” represents the sector’s 256 bytes of available storage, waiting to be filled. Note the considerable amount of organizing and housekeeping information surrounding the actual data, used to keep the drive on track and aware at all times of just where it is. Again, there’s much more here than we need to dig into today. Relevant for our purposes are the track and sector numbers stored near the beginning of each sector. These amount to the sector’s home address, its index in the directory listing.

Microsoft Adventure introduces a seeming corruption into the disk’s scheme. Beginning with track 1 — track 0 must be left alone so the system can find the boot sector and get started — the tracks are numbered not from 1 to 34 but from 127 to 61, in downward increments of 2. The game’s bootstrap inserts a patch into the normal disk-access routines that tells them how to deal with these weirdly numbered tracks. But, absent the patch, the normal TRS-80 operating system has no idea what to make of it. Even a so-called “deep” copier, which tries to copy a disk sector by sector rather than file by file to create a truly exact mirror image of the original, fails because it can’t figure out where the sectors begin and end.

If one wants to make a copy of a protected program, whether for the legal purpose of backing it up or the illegal one of software piracy, one can take either of two approaches. The first is to find a way to exactly duplicate the disk, copy protection and all, so that there’s no way for the program it contains to know it isn’t running on an original. The other is to crack it, to strip out or ignore the protection and modify the program itself to run correctly without it.

One of the first if not the first to find a way to duplicate Microsoft Adventure and then to crack it to boot was an Australian teenager named Nick Andrew (right from the beginning, before the scene even existed, cracking already seemed an avocation for the young). After analyzing the disk to work out how it was “corrupted,” he rewrote the TRS-80’s usual disk formatter to format disks with the alternate track-numbering system. Then he rewrote the standard copier to read and write to the same system. After “about two days,” he had a working duplicate of the original disk.

But he wasn’t quite done yet. After going through all the work of duplicating the disk, the realization dawned that he could easily go one step further and crack it, turn it into just another everyday disk copyable with everyday tools. To do so, he wouldn’t need his modified disk formatter at all. He needed only make a modification to his customized copier, to read from a disk with the alternate track-numbering system but write to a normal one. Remove the custom bootstrap to make Adventure boot like any other disk, and he was done. This first “nightmare for the software pirate” was defanged.

Ultima III

Released in 1983, Ultima III was already the fourth commercial CRPG to be written by the 22-year-old Richard Garriott, but the first of them to be published by his own new company, Origin Systems. With the company’s future riding on its sales, he and his youthful colleagues put considerable effort into devising as tough a copy-protection scheme as possible. It provides a good illustration of the increasing sophistication of copy protection in general by this point, four years after Microsoft Adventure.

Apple II floppy-disk drives function much like their TRS-80 equivalents, with largely only practical variations brought on by specific engineering choices. The most obvious of the differences is the fact that the Apple II writes its data more densely to the disk, giving it 16 256-byte sectors on each of its 35 tracks rather than the 10 of the TRS-80. This change increases each disk’s capacity to ((256 * 16 * 35) / 1024) 140 K.

Ultima III shipped on two disks, one used to boot the game and the other to load in data and to save state as needed during play. The latter is a completely normal Apple II disk, allowing the player to make copies as she will in the name of being able to start a fresh game with a new character at any time. The former, however, is a different story.

The game’s first nasty trick is to make the boot disk less than half a disk. Only tracks 0 through 16 are formatted at all. Like the TRS-80, the Apple II expects the disk’s directory to reside in the middle of the disk, albeit on track 17 rather than 18. In this case, though, track 17 literally doesn’t exist.

But how, you might be wondering, can even a copy-protected disk function at all without a directory? Well, it really can’t, or at least it doesn’t in this case. Again like the TRS-80, the beginning of an Apple II disk is reserved for a boot block. The Ultima III bootstrap substitutes alternative code for a standard operating-system routine called the “Read Write Track Sector” routine, or, more commonly, the “RWTS.” It’s this routine that programs call when they need to access a disk file or to do just about any other operation to a disk. Ultima III provides an RWTS that knows to look for the directory listing not on track 17 but rather on track 7, right in the middle of its half-a-disk. Thus it knows how to find its files, but no one else does.

Ultima III‘s other trick is similar to the approach taken by Microsoft Adventure in theory, but far more gnarly in execution. To understand it, we need to have a look at the structure of an Apple II sector. As on the TRS-80, each sector is divided into an “address field,” whose purpose is to keep the drive on track and help it to locate what it’s looking for, and a “data field” containing the actual data written there. Figures 3 and 4 show the structure of each respectively.

Figure 3

Figure 3

Figure 4

Figure 4

Don’t worry too much about the fact that our supposed 256 bytes of data have suddenly grown to 342. This transformation is down to some nitty-gritty details of the hardware that mean that 256 logical bytes can’t actually be packed into 256 bytes of physical space, that the drive needs some extra breathing room. A special encoding process, known as Group Code Recording (GCR) on the Apple II, converts the 256 bytes into 342 that are easily manipulable by the drive and back again. If we were really serious about learning to create copy protection or how to crack it, we’d need to know a lot more about this. But it’s not necessary to understand if you’re just dipping your toes into that world, as we’re doing today.

Of more immediate interest are the “prologues” and “epilogues” that precede and trail both the address and data fields. On a normal disk these are fixed runs of numbers, which you see shown in hexadecimal notation in Figures 3 and 4. (If you don’t know what that means, again, don’t worry too much about it. Just trust me that they’re fixed numbers.) Like so much else here, they serve to keep the drive on track and to reassure it that everything is kosher.

Ultima III, however, chooses other numbers to place in these spaces. Further, it doesn’t just choose a new set of fixed numbers — that would be far too easy — but rather varies the expected numbers from track to track and even sector to sector according to a table only it has access to, housed in its custom RWTS. Thus what looks like random garbage to the computer normally suddenly becomes madness with a method behind it when the computer has been booted from the Ultima III disk. If any of these fields don’t match with what they should be — i.e., if someone is trying to use an imperfect copy —  the game loads no further.

It’s a tough scheme, particularly for its relatively early date, but far from an unbreakable one. There are a couple of significant points of vulnerability. The first is the fact that Ultima III doesn’t need to read and write only protected disks. There is, you’ll remember, also that second disk in a standard format. The modified RWTS needs to be able to fall back to the standard routine when using that second disk, which is no more readable by the modified routine than the protected disk is by the standard. It relies on the disk’s volume number to decide which routine to use: volume 1 is the first, protected disk; volume 2 the second, unprotected (if the volume number is anything else, it knows somebody must be up to some sort of funny business and just stops entirely). Thus if we can just get a copy of the first disk in an everyday disk format and set its volume number to 2, Ultima III will happily accept it and read from it.

But that “just” is, of course, a tricky proposition. We would seemingly need to write a program of our own to read from a disk — or rather from half of a disk — with all those ever-changing prologue and epilogue fields. That, anyway, is one approach. But, if we’re really clever, we won’t have to. Instead of working harder, we can work smarter, using Ultima III‘s own code to crack it.

One thing that legions of hackers and crackers came to love about the Apple II was its integrated machine-language monitor, which can be used to pause and break into a running program at almost any point. We can use it now to pause Ultima III during its own boot process and look up the address of its customized RWTS in memory; because all disk operations use the RWTS, it is easily locatable via a global system pointer. Once we know where the new RWTS lives, we can save that block of memory to disk for later use.

Next we need only boot back into the normal system, load up the customized RWTS we saved to disk, and redirect the system pointer to it rather than the standard RWTS. Remember that the custom RWTS is already written to assume that disks with a volume number of 1 are in the protected format, those with a volume number of 2 in the normal format. So, if we now use an everyday copy program to copy from the original, which has a volume number of 1, to a blank disk which we’ve formatted with a volume number of 2, Ultima III essentially cracks itself. The copy operation, like all disk operations, simply follows the modified system pointer to the new RWTS, and is never any the wiser that it’s been modified. Pretty neat, no? Elegant tricks like this warm any hacker’s heart, and are much of the reason that vintage cracking remains to this day such an intriguing hobby.

Pirates!

Ultima III‘s copy protection was clever enough in its day, but trivial compared to what would start to appear just a year or so later as the art reached a certain level of maturity. As the industry itself got more and more cutthroat, many of the protection schemes also got just plain nasty. The shadowy war between publisher and pirate was getting ever more personal.

A landmark moment in the piracy wars was the 1984 founding of the Software Publishers Association. It was the brainchild of a well-connected Washington, D.C., lawyer named Ken Wasch who decided that what the industry really needed was a D.C.-based advocacy group and that he, having no previous entanglements within it, was just the neutral party to start it. The SPA had a broad agenda, from gathering data on sales trends from and for its members to presenting awards for “software excellence,” but, from the perspective of the outsider at any rate, seemed to concern itself with the piracy problem above all else. Its rhetoric was often strident to the point of shrillness, while some of its proposed remedies smacked of using a hydrogen bomb to dig a posthole. For instance, the SPA at one point protested to Commodore that multitasking shouldn’t be a feature of the revolutionary new Amiga because it would make it too easy for crackers to break into programs. And Wasch lobbied Congress to abolish the user’s right to make backup copies of their software for personal archival purposes, a key part of the 1980 Software Copyright Act that he deemed a “legal loophole” because it permitted the existence of programs capable of copying many forms of copy-protected software — a small semi-underground corner of the software industry that the SPA was absolutely desperate to eliminate rather than advocate for. The SPA also did its best to convince the FBI and other legal authorities to investigate the bulletin-board systems of the cracking scene, with mixed success at best.

Meanwhile copy protection was becoming a business in its own right, the flip side to the business of making copying programs. In place of the home-grown protection schemes of our first two case studies, which amounted to whatever the developers themselves could devise in whatever time they had available, third-party turnkey protection systems, the products of an emerging cottage industry, became increasingly common as the 1980s wore on. The tiny companies that created the systems weren’t terribly far removed demographically from the crackers that tried to break them; they were typically made up of one to three young men with an encyclopedic knowledge of their chosen platforms and no small store of swagger of their own. Their systems, sporting names like RapidLok and PirateBusters, were multifaceted and complex, full of multiple failsafes, misdirections, encryptions, and honey pots. Copy-protection authors took to sneaking taunting messages into their code, evincing a braggadocio that wouldn’t have felt out of place in the scene: “Nine out of ten pirates go blind trying to copy our software. The other gets committed!”

Protection schemes of this later era are far too complex for me to describe in any real detail in an accessible article like this one, much less explain how people went about cracking them. I would, however, like to very briefly introduce RapidLok, the most popular of the turnkey systems on the Commodore 64. It was the product of a small company called the Dane Final Agency, and was used in its various versions by quite a number of prominent publishers from early 1986 on, including MicroProse. You’ll find it on that first bona fide Sid Meier classic, the ironically-titled-for-our-purposes Pirates!, along with all of their other later Commodore 64 games.

The protection schemes we’ve already seen have modified their platforms’ standard disk formats to confuse copy programs. RapidLok goes to the next level by implementing its own custom format from scratch. A standard Commodore 64 disk has 17 to 21 sectors per track, depending on where the track is located; a RapidLok disk has 11 or 12 much larger sectors, with the details of how those sectors organize their data likewise re-imagined. Rapidlok also adds a track to the standard 35, shoved off past the part of the disk that is normally read from or written to. This 36th track serves as an encrypted checksum store for all of the other tracks. If any track fails the checksum check — indicating it’s been modified from the original — the system immediately halts.

Like any protection scheme, RapidLok must provide a gate to its walled garden, an area of the disk formatted normally so that the computer can boot the game in the first place. Further, writing to RapidLok-formatted tracks isn’t practical. The computer would need to recalculate the checksum for the track as a whole, encrypt it, and rewrite that portion to the checksum store out past the normally accessible part of the disk — a far too demanding task for a little Commodore 64. For these reasons, Rapidlok disks are hybrids, partially formatted as standard disks and partially in the protected format. Figure 5 below shows the first disk of Pirates! viewed with a contemporary copying utility.

Figure 5

Figure 5

As the existence of such a tool will attest, techniques did exist to analyze and copy RapidLok disks in their heyday. Among the crackers, Mitch of Eagle Soft was known as the RapidLok master; it’s his vintage crack of Pirates! and many other RapidLok-protected games that you’ll find floating around the disk-image archives today. Yet even those cracks, masterful as they were, were forced to strip out a real advantage that RapidLok gave to the ordinary player, that was in fact the source of the first part of its name: its custom disk format was much faster to read from than the standard, by a factor of five or six. Pirates who chose to do their plundering via Mitch’s cracked version of Pirates! would have to be very patient criminals.

But balanced against the one great advantage of RapidLok for the legitimate user was at least one major disadvantage beyond even the obvious one of not being able to make a backup copy. In manipulating the Commodore 64 disk drive in ways its designers had never intended, RapidLok put a lot of stress on the hardware. Drives that were presumably just slightly out of adjustment, but that nevertheless did everything else with aplomb, proved unable to load RapidLok disks, or, almost worse, failed intermittently in the middle of game sessions (seemingly always just after you’d scored that big Silver Train robbery in the case of Pirates!, of course). And, still worse from the standpoint of MicroProse’s customer relations, a persistent if unproven belief arose that RapidLok was actually damaging disk drives, throwing them out of alignment through its radical operations. It certainly didn’t sound good in action, producing a chattering and general caterwauling and shaking the drive so badly one wondered if it was going to walk right off the desktop one day.

The belief, quite probably unfounded though it was, that MicroProse and other publishers were casually destroying their customers’ expensive hardware in the name of protecting their own interests only fueled the flames of mistrust between publisher and consumer that so much of the SPA’s rhetoric had done so much to ignite. RapidLok undoubtedly did its job in preventing a good number of people from copying MicroProse games. A fair number of them probably even went out and bought the games for themselves as an alternative. Whether those sales were worth the damage it did to MicroProse’s relations with their loyal customers is a question with a less certain answer.

Dungeon Master

No discussion of copy protection in the 1980s could be complete without mentioning Dungeon Master. Like everything else about FTL’s landmark real-time CRPG, its copy protection was innovative and technically masterful, so much so that it became a veritable legend in its time. FTL wasn’t the sort of company to be content with any turnkey copy-protection solution, no matter how comprehensive. What they came up with instead is easily as devious as any dungeon level in the game proper. As Atari ST and Amiga crackers spent much of 1988 learning, every time you think you have it beat it turns the tables on you again. Let’s have a closer look at the protection used on the very first release of Dungeon Master, the one that shipped for the ST on December 15, 1987.

3 1/2 inch floppy disk

With the ST and its 68000-based companions, we’ve moved into the era of the 3½-inch disk, a format that can pack more data onto a smaller disk and also do so more reliably; the fragile magnetic platter is now protected beneath a rigid plastic case and a metal shield that only pulls away to expose it when the disk is actually inserted into a drive. The principles of the 3½-inch disk’s operation are, however, the same as those of the 5¼-inch, so we need not belabor the subject here.

Although most 3½-inch drives wrote to both sides of the disk, early STs used just one, in a format that consisted of 80 tracks, each with 9 512-byte sectors, for a total of ((512 * 9 * 80) / 1024) 360 K of storage capacity. The ST uses a more flexible filesystem than was the norm on the 8-bit machines we’ve discussed so far, one known as FAT, for File Allocation Table. The FAT filesystem dates back to the late 1970s, was adopted by Microsoft for MS-DOS in 1981, and is still in common use today in a form known as FAT32; the ST uses FAT12. The numerical suffix refers to the number of bits allocated to each file’s home address on the disk, which in turn dictates the maximum possible capacity of the disk itself. FAT is designed to accommodate a wide range of floppy and hard disks, and thus allows the number of tracks and sectors to be specified at the beginning of the disk itself. Thanks to FAT’s flexibility, Dungeon Master can easily bump the number of sectors per track from 9 to 10, a number still well within the capabilities of the ST’s drive. That change increases the disk’s storage capacity to ((512 * 10 * 80) / 1024) 400 K. It was only this modification, more a response to a need for just a bit more disk space than an earnest attempt at copy protection, that allowed FTL to pack the entirety of Dungeon Master onto a single disk.

Dungeon Master‘s real protection is a very subtle affair, which is one of the keys to its success. At first glance one doesn’t realize that the disk is protected at all — a far cry from the radical filesystem overhaul of RapidLok. The disk’s contents can be listed like those of any other, its individual files even read in and examined. The disk really is a completely normal one — except for track 0, sectors 7 and 8.

Let’s recall again the two basic methods of overcoming copy protection: by duplicating the protection on the copy or by cracking the original, making it so that you don’t need to duplicate the protection. Even with a scheme as advanced as RapidLok, duplication often remained an option. Increasingly by the era of Dungeon Master, though, we see the advent of schemes that are physically impossible for the disk drives on the target machines to duplicate under any circumstances, that rely on capabilities unique to industrial-scale disk duplicators. Nate Lawson, a reader of this blog who was hugely helpful to me in preparing this article, describes good copy protection as taking advantage of “asymmetry”: “the difference between the environment where the code is executed versus where it was produced.” The ultimate form of asymmetry must be a machine on the production side that can write data in a format that the machine on the execution side physically cannot.

Because FTL duplicated their own disks in-house rather than using an outside service like most publishers, they had a great deal of control over the process used to create them. They used their in-house disk duplicator to write an invalid sector number to a single sector: track 0, sector 8 is labeled sector 247. At first blush, this hardly seems special; Microsoft Adventure, that granddaddy of copy-protected games, had after all used the same technique eight years earlier. But there’s something special about this sector 247: due to limitations of the ST’s drive hardware that we won’t get into here, the machine physically can’t write that particular sector number. Any disk with a sector labeled 247 has to have come from something other than an ST disk drive.

Track 0, sector 7, relies on the same idea of hardware asymmetry, but adds another huge wrinkle sufficient to warm the heart of any quantum physicist. Remember that the data stored on a disk boils down to a series of 1s and 0s, magnetized or demagnetized areas that are definitively in one state or the other. But what if it was possible to create a “fuzzy” bit, one that capriciously varies between states on each successive read? Well, it wasn’t possible to do anything like that on an ST disk drive or even most industrial disk duplicators. But FTL, technology-driven company that they were, modified their own disk duplicator to be able to do just that. By cramming a lot of “flux reversals,” or transitions between a magnetic and demagnetized state, into a space far smaller than the read resolution of the ST disk drive, they could create bits that lived in a perpetually in-between state — bits that the drive would randomly read sometimes as on and sometimes as off.

Dungeon Master has one of these fuzzy bits on track 0, sector 7. When the disk is copied, the copy will contain not a fuzzy bit but a normal bit, on or off according to the quantum vagaries of the read process that created it.

Figure 6

Figure 6

As illustrated in Figure 6, Dungeon Master‘s copy-protection routines read the ostensible fuzzy bit over and over, waiting for a discordant result. When that comes, it can assume that it’s running from an original disk and continue. If it tries many times, always getting the same result, it assumes it’s running from a copy and behaves accordingly.

FTL’s scheme was so original that they applied for and were granted a patent on it, one that’s been cited many times in subsequent filings. It represents a milestone in the emerging art and science of DRM. Ironically, the most influential aspect of Dungeon Master, a hugely influential game on its own terms, might just be its fuzzy-bit copy protection. Various forms of optical media continue to use the same approach to this day.

With duplication a complete non-starter in the case of both this sector numbered 247 and the fuzzy bit, the only way to pirate Dungeon Master must be to crack it. Doing so must entail diving into the game’s actual code, looking for the protection check and modifying it to always return a positive response. In itself, that wasn’t usually too horrible; crackers had long ago learned to root through code to disable look-up-a-word-in-the-manual and code-wheel-based “soft” protection schemes. But FTL, as usual, had a few tricks up their sleeves to make it much harder: they made the protection checks multitudinous and their results non-obvious.

Instead of checking the copy protection just once, Dungeon Master does it over and over, from half-a-dozen or so different places in its code, turning the cracker’s job into a game of whack-a-mole. Every time he thinks he’s got it at last, up pops another check. The most devious of all the checks is the one that’s hidden inside a file called “graphics.dat,” the game’s graphics store. Who would think to look for executable code there?

Compounding the problem of finding the checks is the fact that even on failure they don’t obviously do anything. The game simply continues, only to become unstable and start spitting out error messages minutes later. For this reason, it’s extremely hard to know when and whether the game is finally fully cracked. It was the perfect trap for the young crackers of the scene, who weren’t exactly known for their patience. The pirate boards were flooded with crack after crack of Dungeon Master, all of which turned out to be broken after one had actually played a while. In a perverse way, it amounted to a masterful feat of advertising. Many an habitual pirate got so frustrated with not being able properly play this paradigm-shattering game that he made Dungeon Master the only original disk in his collection. Publishers had for years already been embedding their protection checks some distance into their games, both to make life harder for crackers and to turn the copies themselves into a sort of demo version that unwitting would-be pirates distributed for them for free. But Dungeon Master used the technique to unprecedented success in terms of pirated copies that turned into sold originals.

Dungeon Master still stands as one of copy protection’s — or, if you like, DRM’s — relatively few absolutely clear, unblemished success stories. It took crackers more than a year, an extraordinary amount of time by their usual standards, to wrap their heads around the idea of a fuzzy bit and to find all of the checks scattered willy-nilly through the code (and, in the case of “graphics.dat,” out of it). After that amount of time the sales window for any computer game, even one as extraordinary as Dungeon Master, must be closing anyway. Writing about the copy protection twenty years later, Doug Bell of FTL couldn’t resist a bit of crowing.

Dungeon Master exposed the fallacy in the claims of both the pirates and the crackers. The pirates who would never have paid for the game if they could steal it did pay for it. Despite a steadily growing bounty of fame and notoriety for cracking the game, the protection lasted more than a year. And the paying customer was rewarded with not just a minimally invasive copy-protection scheme, but, just as importantly, with the satisfaction of not feeling like a schmuck for paying for something that most people were stealing.

As the developer of both Dungeon Master and the software portion of its copy protection, I knew that eventually the copy protection would be broken, but that the longer it held out the less damage we would suffer when it was broken.

Dungeon Master had a greater than 50-percent market penetration on the Atari ST—that is, more than one copy of Dungeon Master was sold for each two Atari ST computers sold. That’s easily ten times the penetration of any other game of the time on any other platform.

So what’s the lesson? That piracy does take significant money out of the pocket of the developer and that secure anti-piracy schemes are viable.

Whether we do indeed choose to view Dungeon Master as proof of the potential effectiveness of well-crafted DRM as a whole or, as I tend to, as something of an historical aberration produced by a unique combination of personalities and circumstances, it does remain a legend among old sceners, respected as perhaps the worthiest of all the wily opponents they encountered over the years — not just technically brilliant but conceptually and even psychologically so. By its very nature, the long war between the publishers and the crackers could only be a series of delaying actions on the part of the former. For once, the delay created by Dungeon Master‘s copy protection was more than long enough.

And on that note we’ll have to conclude this modest little peek behind the curtain of 1980s copy protection. Like so many seemingly narrow and esoteric topics, it only expands and flowers the deeper you go into it. People continue to crack vintage games and other software to this day, and often document their findings in far more detail than I can here. Apple II fans may want to have a look at the work of one “a2_4am” on Twitter, while those of you who want to know more about RapidLok may want to look into the C64 Preservation Project‘s detailed RapidLok Handbook, which is several times the length of this article. And if all that’s far, far more information than you want — and no, I really don’t blame you — I hope this article, cursory as it’s been, has instilled some respect for the minds on both sides of the grand software-piracy wars of the 1980s.

(Sources: Beneath Apple DOS by Don Worth and Pieter Lechner; The Anatomy of the 1541 Disk Drive by Lothar Englisch and Norbert Szczepanowski; Inside Commodore DOS by Richard Immers and Gerald G. Newfeld; The Kracker Jax Revealed Trilogy; Commodore Power Play of August/September 1985; Kilobaud of July 1982; New Zealand Bits and Bytes of May 1984; Games Machine of June 1988; Transactor 5.3; 80 Microcomputing of November 1980; Byte of December 1980; Hardcore Computist #9 and #11; Midnite Software Gazette of April 1986. Online sources include Nick Andrew’s home page, the aforementioned C64 Preservation Project, and The Dungeon Master Encyclopedia. See also Jean Louis-Guérin’s paper “Atari Floppy Disk Copy Protection.” Information on the SPA’s activities comes from the archive of SPA-related material donated to the Strong Museum of Play by Doug Carlston, first fruit of my research here in Rochester.

My huge thanks to Nate Lawson for doing something of a peer review of this article prior to publication!)

 
 

Tags: , , , , , , , , , , , ,

Send in the Clones

In computer parlance, a clone is Company B’s copycat version of Company A’s computer that strains to be as software and hardware compatible with its inspiration as possible. For a platform to make an attractive target for cloning, it needs to meet a few criteria. The inspiration needs to be simple and/or well-documented enough that it’s practical for another company — and generally a smaller company at that, with far fewer resources at its disposal — to create a compatible knock-off in the first place. Then the inspiration needs to be successful enough that it’s spawned an attractive ecosystem that lots of people want to be a part of. And finally, there needs to be something preventing said people from joining said ecosystem by, you know, simply buying the machine that’s about to be cloned. Perhaps Company A, believing it has a lock on the market, keeps the price above what many otherwise interested people are willing or able to pay; perhaps Company A has simply neglected to do business in a certain part of the world filled with eager would-be buyers.

Clones have been with us almost from the moment that the trinity of 1977 kicked off the PC revolution in earnest. The TRS-80 was the big early winner of the trio thanks to its relatively low price and wide distribution through thousands of Radio Shack stores, outselling the Apple II in its first months by margins of at least twenty to one (as for the Commodore PET, it was the Bigfoot of the three, occasionally glimpsed in its natural habitat of trade-show booths but never available in a form you could actually put your hands on until well into 1978). The first vibrant, non-business-focused commercial software market in history sprung up around the little Trash 80. Cobbled together on an extreme budget out of generic parts that were literally just lying around at Radio Shack — the “monitor,” for instance, was just a cheap Radio Shack television re-purposed for the role — the TRS-80 was eminently cloneable. Doing so didn’t make a whole lot of sense in North America, where Radio Shack’s volume manufacturing and distribution system would be hard advantages to overcome. But Radio Shack had virtually no presence outside of North America, where there were nevertheless plenty of enthusiasts eager to join the revolution.

EACA shindig in Hong Kong

A shindig for EACA distributors in Hong Kong. Shortly after this photo was taken, Eric Chung, third from right in front, would abscond with $10 million and that would be that for EACA.

The most prominent of the number of TRS-80 cloners that had sprung up by 1980 was a rather shady Hong Kong-based company called EACA, who made cheap clones for any region of the world with distributors willing to buy them. Their knock-offs popped up in Europe under the name “The Video Genie”; in Australasia as the “Dick Smith System 80,” distributed under the auspices of Dick Smith Electronics, the region’s closest equivalent to Radio Shack; even in North America as the “Personal Micro Computers PMC-80.” EACA ended in dramatic fashion in 1983 when founder Eric Chuang absconded to Taiwan with all of his company’s assets that he could liquify, $10 million worth, stuffed into his briefcase. He or his descendents are presumably still living the high life there today.

By the time of those events, the TRS-80’s heyday was already well past, its position as the most active and exciting PC platform long since having been assumed by the Apple II, which had begun a surge to the fore in the wake of the II Plus model of 1979. The Apple II was if anything an even more tempting target for cloners than the TRS-80. While Steve Wozniak’s hardware design is justly still remembered as a marvel of compact elegance, it was also built entirely from readily available parts, lacking the complex and difficult-to-duplicate custom chips of competitors like Atari and Commodore. Wozniak had also insisted that every last diode on the Apple II’s circuit board be meticulously documented for the benefit of hackers just like him. And Apple, then as now, maintained some of the highest profit margins in the industry, creating a huge opportunity for a lean-and-mean cloner to undercut them.

The Franklin Ace 1000

A Franklin Ace 1000 mixed and matched with a genuine Apple floppy drive.

Assorted poorly distributed Far Eastern knock-offs aside, the first really viable Apple II clone arrived in mid-1982 in the form of the Franklin Ace line. The most popular model, the Ace 1000, offered for about 25 percent less than a II Plus complete hardware and software compatibility while also having more memory as well as luxuries like a numeric keypad and upper- and lowercase letter input. The Ace terrified Apple. With the Apple III having turned into a disaster, Apple remained a one-platform company, completely dependent on continuing Apple II sales — and continuing high Apple II profit margins — to fund not one but two hugely ambitious, hugely innovative, and hugely expensive new platform initiatives, Lisa and Macintosh. A viable market in Apple II workalikes which cut seriously into sales, or that forced price cuts, could bring everything down around their ears. Already six months before the Ace actually hit the market, as soon as they got word of Franklin’s plans, Apple’s lawyers were therefore looking for a way to challenge Franklin in court and drive their machine from the market.

As it turned out, the basis for a legal challenge wasn’t hard to find. Yes, the Apple II’s unexceptional hardware would seem to be fair game — but the machine’s systems software was not. Apple quickly confirmed that, like most of the TRS-80 cloners, Franklin had simply copied the contents of the II’s ROM chips; even bugs and the secret messages Apple’s programmers had hidden inside them were still there in Franklin’s versions. A triumphant Apple rushed to federal court to seek a preliminary injunction to keep the Ace off the market until the matter was decided through a trial. Much to their shocked dismay, the District Court for the Eastern District of Pennsylvania found the defense offered by Franklin’s legal team compelling enough to deny the injuction. The Ace came out right on schedule that summer of 1982, to good reviews and excellent sales.

Franklin’s defense sounds almost unbelievable today. They readily admitted that they had simply copied the contents of the ROM chips. They insisted, however, that the binary code contained on the chips, being a machine-generated sequence of 1s and 0s that existed only inside the chips and that couldn’t be reasonably read by a human, was not a form of creative expression and thus not eligible for copyright protection in the first place. In Franklin’s formulation, only the human-readable source code used to create the binary code stored on the ROM chips, which Franklin had no access to and no need for given that they had the binary code, was copyrightable. It was an audacious defense to say the least, one which if accepted would tear down the legal basis for the entire software industry. After all, how long would it take someone to leap to the conclusion that some hot new game, stored only in non-human-readable form on a floppy disk, was also ineligible for copyright protection? Astonishingly, when the case got back to the District Court for a proper trial the judge again sided with Franklin, stating that “there is some doubt as to the copyrightability of the programs described in this litigation,” in spite of an earlier case, Williams Electronics, Inc. v. Arctic International, Inc., which quite clearly had established binary code as copyrightable. Only in August of 1983 was the lower court’s ruling overturned by the Federal Court of Appeals in Philadelphia. A truculent Franklin threatened to appeal to the Supreme Court, but finally agreed to a settlement that January that demanded they start using their own ROMs if they wanted to keep cloning Apple IIs.

Apple Computer, Inc., v. Franklin Computer Corp. still stands today as a landmark in technology jurisprudence. It firmly and finally established the copyrightable status of software regardless of its form of distribution. And it of course also had an immediate impact on would-be cloners, making their lives much more difficult than before. With everyone now perfectly clear on what was and wasn’t legal, attorney David Grais clarified the process cloners would need to follow to avoid lawsuits in an episode of Computer Chronicles:

You have to have one person prepare a specification of what the program [the systems software] is supposed to do, and have another person who’s never seen the [original] program write a program to do it. If you can persuade a judge that the second fellow didn’t copy from the [original] code, then I think you’ll be pretty safe.

After going through this process, Apple II cloners needed to end up with systems software that behaved absolutely identically to the original. Every system call needed to take the exact same amount of time that it did on a real Apple II; each of the original software’s various little quirks and bugs needed to be meticulously duplicated. Anything less would bring with it incompatibility, because there was absolutely nothing in those ROMs that some enterprising hacker hadn’t used in some crazy, undocumented, unexpected way. This was a tall hurdle indeed, one which neither Franklin nor any other Apple II cloner was ever able to completely clear. New Franklins duly debuted with the new, legal ROMs, and duly proved to be much less compatible and thus much less desirable than the older models. Franklin left the Apple-cloning business within a few years in favor of hand-held dictionaries and thesauri.

There is, however, still another platform to consider, one on which the cloners would be markedly more successful: the IBM PC. The open or (better said) modular architecture of the IBM PC was not, as so many popular histories have claimed, a sign of a panicked or slapdash design process. It was rather simply the way that IBM did business. Back in the 1960s the company had revolutionized the world of mainframe computing with the IBM System/360, not a single computer model but a whole extended family of hardware and software designed to plug and play together in whatever combination best suited a customer’s needs. It was this product line, the most successful in IBM’s history, that propelled them to the position of absolute dominance of big corporate computing that they still enjoyed in the 1980s, and that reduced formerly proud competitors to playing within the house IBM had built by becoming humble “Plug-Compatible Manufacturers” selling peripherals that IBM hadn’t deigned to provide — or, just as frequently, selling clones of IBM’s products for lower prices. Still, the combined profits of all the cloners remained always far less than those of IBM itself; it seemed that lots of businesses wanted the security that IBM’s stellar reputation guaranteed, and were willing to pay a bit extra for it. IBM may have thought the PC market would play out the same way. If so, they were in for a rude surprise.

The IBM PC was also envisioned as not so much a computer as the cornerstone of an ever-evolving, interoperable computing family that could live for years or decades. Within three years of the original machine’s launch, you could already choose from two CPUs, the original Intel 8088 or the new 80286; could install as little as 16 K of memory or as much as 640 K; could choose among four different display cards, from the text-only Monochrome Display Adapter to the complicated and expensive CAD-oriented Professional Graphics Controller; could choose from a huge variety of other peripherals: floppy and hard disks, tape backup units, modems, printer interfaces, etc. The unifying common denominator amongst all this was a common operating system, MS-DOS, which had quickly established itself as the only one of the four operating paradigms supported by the original IBM PC that anyone actually used. Here we do see a key difference between the System/360 and the IBM PC, one destined to cause IBM much chagrin: whereas the former ran an in-house-developed IBM operating system, the operating system of the latter belonged to Microsoft.

The IBM architecture was different from that of the Apple II in that its operating system resided on disk, to be booted into memory at system startup, rather than being housed in ROM. Still, every computer needs to have some code in ROM. On an IBM PC, this code was known as the “Basic Input/Output System,” or BIOS, a nomenclature borrowed from the CP/M-based machines that preceded it. The BIOS was responsible on startup for doing some self-checks and configuration and booting the operating system from disk. It also contained a set of very basic, very low-level routines to do things like read from and write to the disks, detect keyboard input, or display text on the screen; these would be called constantly by MS-DOS and, very commonly, by applications as well while the machine was in operation. The BIOS was the one piece of software for the IBM PC that IBM themselves had written and owned, and for obvious reasons they weren’t inclined to share it with anyone else. Two small companies, Corona Labs and Eagle Computer, would simply copy IBM’s BIOS a la Franklin. It took the larger company all of one day to file suit and force complete capitulation and market withdrawal when those machines came to their attention in early 1984.

Long before those events, other wiser would-be cloners recognized that creating a workalike, “clean-room” version of IBM’s BIOS would be the key to executing a legal IBM clone. The IBM PC’s emphasis on modularity and future expansion meant that it was a bit more forgiving in this area than the likes of the more tightly integrated Apple II. Yet an IBM-compatible BIOS would still be a tricky business, fraught with technical and financial risk.

As the IBM PC was beginning to ship, a trio of Texas Instruments executives named Rod Canion, James Harris, and William Murto were kicking around ideas for getting out from under what they saw as a growing culture of non-innovation inside TI. Eager to start a business of their own, they considered everything from a Mexican restaurant to household gadgets like a beeper for finding lost keys. Eventually they started to ask what the people around them at TI wanted but weren’t getting in their professional lives. They soon had their answer: a usable portable computer that executives and engineers could cart around with them on the road, and that was cheap enough that their purchasing managers wouldn’t balk. Other companies had explored this realm before, most notably the brief-lived Osborne Computer with the Osborne 1, but those products had fallen down badly in the usability sweepstakes; the Osborne 1, for example, had a 5-inch display screen the mere thought of which could prompt severe eye strain in those with any experience with the machine, disk drives that could store all of 91 K, and just 64 K of memory. Importantly, all of those older portables ran CP/M, until now the standard for business computing. Canion, Harris, and Murto guessed, correctly, that CP/M’s days were numbered in the wake of IBM’s adoption of MS-DOS. Not wanting to be tied to a dying operating system, they first considered making their own. Yet when they polled the big software publishers about their interest in developing for yet another new, incompatible machine the results were not encouraging. There was only one thing for it: they must find a way to make their portable compatible with the IBM PC. If they could bring out such a machine before IBM did, the spoils could be enormous. Prominent tech venture capitalist Ben Rosen agreed, investing $2.5 million to help found Compaq Computer Corporation in February of 1982. What with solid funding and their own connections within the industry, Canion, Harris, and Murto thought they could easily design a hardware-compatible portable that was better than anything else available at the time. That just left the software side.

Given Bill Gates’s reputation as the Machiavelli of the computer industry, we perhaps shouldn’t be surprised that some journalists have credited him with anticipating the rise of PC clones from well before the release of the first IBM PC. That, however, is not the case. All indications are that Gates negotiated a deal that let Microsoft lease MS-DOS to IBM rather than sell it to them simply in the expectation that the IBM PC would be a big success, enough so that an ongoing licensing fee would amount to far more than a lump-sum payout in the long run. Thus he was as surprised as anyone when Compaq and a few other early would-be cloners contacted him to negotiate MS-DOS license deals for their own machines. Of course, Gates being Gates, it took him all of about ten minutes to grasp the implications of what was being requested, and to start making deals that, not incidentally, actually paid considerably better than the one he’d already made with IBM.

The BIOS would be a tougher nut to crack, the beachhead on which this invasion of Big Blue’s turf would succeed or fail. Having quickly concluded that simply copying IBM’s ROMs wasn’t a wise option, Compaq hired a staff of fifteen programmers who would dedicate the months to come to creating a slavish imitation. Programmers with any familiarity at all with the IBM BIOS were known as “dirty,” and barred from working on the project. Instead of relying on IBM’s published BIOS specifications (which might very well be incorrect due to oversight or skulduggery), the team took the thirty biggest applications on the market and worked through them one at a time, analyzing each BIOS call each program made and figuring out through trial and error what response it needed to receive. The two trickiest programs, which would go on to become a sort of stress test for clone compatibility both inside and outside of Compaq, proved to be Lotus 1-2-3 and Microsoft Flight Simulator.

Before the end of the year, Compaq was previewing their new portable to press and public and working hard to set up a strong dealer network. For the latter task they indulged in a bit of headhunting: they hired away from IBM H. L. ”Sparky” Sparks, the man who had set up the IBM PC dealer network. Knowing all too well how dealers thought and what was most important to them, Sparks instituted a standard expected dealer markup of 36 percent, versus the 33 percent offered by IBM, thus giving them every reason to look hard at whether a Compaq might meet a customer’s needs just as well or better than a machine from Big Blue.

The Compaq Portable

Compaq’s first computer, the Portable

Savvy business realpolitik like that became a hallmark of Compaq. Previously clones had been the purview of small upstarts, often with a distinct air of the fly-by-night about them. The suburban-Houston-based Compaq, though, was different, not only from other cloners but also from the established companies of Silicon Valley. Compaq was older, more conservative, interested in changing the world only to the extent that that meant more Compaq computers on desks and in airplane luggage racks. ”I don’t think you could get a 20-year-old to not try to satisfy his ego by ‘improving’ on IBM,” said J. Steven Flannigan, the man who led the BIOS reverse-engineering effort. “When you’re fat, balding, and 40, and have a lot of patents already, you don’t have to try.” That attitude was something corporate purchasing managers could understand. Indeed, Compaq bore with it quite a lot of the same sense of comforting stolidity as did IBM itself. Not quite the first to hit the market with an IBM clone with a “clean” BIOS (that honor likely belongs to Columbia Data Products, a much scruffier sort of operation that would be out of business by 1985), Compaq nevertheless legitimized the notion in the eyes of corporate America.

The Compaq Portable goes flying

The worst possible 1980s airplane seatmate: a business traveler lugging along a Compaq Portable.

Yet the Compaq Portable that started shipping very early in 1983 also succeeded because it was an excellent and — Flannigan’s sentiments aside — innovative product. By coming out with their portable before IBM itself, Compaq showed that clones need not be mere slavish imitations of their inspirations distinguished only by a lower price. “Portable” in 1983 did not, mind you, mean what it does today. The Compaq Portable was bigger and heavier  — a full 28 pounds — than most desktop machines of today, something you manhandled around like a suitcase rather than slipping into a pocket or backpack. There wasn’t even a battery in the thing, meaning the businessperson on the go would likely be doing her “portable” computing only in her hotel room. Still, it was very thoughtfully designed within the technical constraints of its era; you could for instance attach it to a real monitor at your desk to enjoy color graphics in lieu of the little 9-inch monochrome screen that came built-in, a first step on the road to the ubiquitous laptop docking stations of today.

Launching fortuitously just as some manufacturing snafus and unexpected demand for the new PC/XT were making IBM’s own computers hard to secure in some places, the Compaq Portable took off like a rocket. Compaq sold 53,000 of them for $111 million in sales that first year, a record for a technology startup. IBM, suddenly in the unaccustomed position of playing catch-up, released their own portable the following year with fewer features but — and this was truly shocking — a lower price than the Compaq Portable; by forcing high-and-mighty IBM to compete on price, Compaq seemed to have somehow turned the world on its head. The IBM Portable PC was a notable commercial failure, first sign of IBM’s loosening grip on the monster they had birthed. Meanwhile Compaq launched their own head-to-head challenge that same year with the DeskPro line of desktop machines, to much greater success. Apple may have been attacking IBM in melodramatic propaganda films and declaring themselves and IBM to be locked in a battle of Good versus Evil, but IBM hardly seemed to notice the would-be Apple freedom fighters. The only company that really mattered to IBM, the only company that scared them, wasn’t sexy Apple but buttoned-down, square-jawed Compaq.

But Compaq was actually far from IBM’s only problem. Cloning just kept getting easier, for everyone. In the spring of 1984 two little companies called Award Software and Phoenix Technologies announced identical products almost simultaneously: a reverse-engineered, completely legal IBM-compatible BIOS which they would license to anyone who felt like using it to make a clone. Plenty of companies did, catapulting Award and Phoenix to the top of what was soon a booming niche industry (they would eventually resolve their rivalry the way that civilized businesspeople do it, by merging). With the one significant difficulty of cloning thus removed, making a new clone became almost a triviality, a matter of ordering up a handful of components along with MS-DOS and an off-the-shelf BIOS, slapping it all together, and shoving it out the door; the ambitious hobbyist could even do it in her home if she liked. By 1986, considerably more clones were being sold than IBMs, whose own sales were stagnant or even decreasing.

That year Intel started producing the 80386, the third generation of the line of CPUs that powered the IBM PC and its clones. IBM elected to wait a bit before making use of it, judging that the second-generation 80286, which they had incorporated into the very successful PC/AT in 1984, was still plenty powerful  for the time being. It was a bad decision, predicated on a degree dominance which IBM no longer enjoyed. Smelling opportunity, Compaq made their own 80386-based machine, the DeskPro 386, the first to sport the hot new chip. Prior to this machine, the cloners had always been content to let IBM pave the way of such fundamental advances. The DeskPro 386 marks Compaq’s — and the clone industry’s — coming of age. No longer just floating along in the wake of IBM, tinkering with form factors, prices, and feature sets, now they were driving events. Already in November of 1985, Bill Machrone of PC Magazine had seen where this was leading: “Now that it [IBM] has created the market, the market doesn’t necessarily need IBM for the machines.” We see here business computing going through its second fundamental shift (the first being the transition from CP/M to MS-DOS). What was an ecosystem of IBM and IBM clones now became a set of sometimes less-than-ideal, sometimes accidental, but nevertheless agreed-upon standards that were bigger than IBM or anyone else. IBM, Machrone wrote, “had better conform” to the standards or face the consequences just like anyone else. Tellingly, it’s at about this time that we see the phrase “IBM clone” begin to fade, to be replaced by “MS-DOS machine” or “Intel-based machine.”

The emerging Microsoft/Intel juggernaut (note the lack of an “IBM” in there) would eventually conquer the home as well. Already by the mid-1980s certain specimens of the breed were beginning to manifest features that could make them attractive for the home user. Let’s rewind just slightly to look at the most important of them, which I’ve mentioned in a couple of earlier articles but have never really given its full due.

When the folks at Radio Shack, trying to figure out what to do with their aging, fading TRS-80 line, saw the ill-fated IBM PCjr, they saw things well worth salvaging in its 16-color graphics chip and its three-voice sound synthesizer, both far superior to the versions found in its big brothers. Why not clone those pieces, package them into an otherwise fairly conventional PC clone, and sell the end result as the perfect all-around computer, one which could run all the critical business applications but could also play games in the style to which kids with Commodore 64s were accustomed? Thanks to the hype that had accompanied the PCjr’s launch, there were plenty of publishers out there with huge inventories of games and other software that supported the PCjr’s audiovisuals, inventories they’d be only too eager to unload on Radio Shack cheap. With those titles to prime the pump, who knew where things might go…

Launched in late 1984, the Tandy 1000 was the first IBM clone to be clearly pitched not so much at business as at the ordinary consumer. In addition to the audiovisual enhancements and very aggressive pricing, it included DeskMate, a sort of proto-GUI operating environment designed to insulate the user from the cryptic MS-DOS command prompt while giving access to six typical home applications that came built right in. A brilliant little idea all the way around, the Tandy 1000 rescued Radio Shack from the brink of computing irrelevance. It also proved a godsend for many software publishers who’d bet big on the PCjr; John Williams credits it with literally saving Sierra by providing a market for King’s Quest, a game Sierra had developed for the PCjr at horrendous expense and to underwhelming sales given that platform’s commercial failure. Indeed, the Tandy 1000 became so popular that it prompted lots of game publishers to have a second look at the heretofore dull beige world of the clones. As they jumped aboard the MS-DOS gravy train, many made sure to take advantage of the Tandy 1000’s audiovisual enhancements. Thousands of titles would eventually blurb what became known as “Tandy graphics support” on their boxes and advertisements. Having secured the business market, the Intel/Microsoft architecture’s longer, more twisting road to hegemony over home computing began in earnest with the Tandy 1000. And meanwhile poor IBM couldn’t even get proper credit for the graphics standard they’d actually invented. Sometimes you just can’t win for losing.

Another sign of the nascent but inexorably growing power of Intel/Microsoft in the home would come soon after the Tandy 1000, with the arrival of the first game to make many Apple, Atari, and Commodore owners wish that they had a Tandy 1000 or, indeed, even one of its less colorful relatives. We’ll get to that soon — no, really! — but first we have just one more detour to take.

(I was spoiled for choice on sources this time. A quick rundown of periodicals: Creative Computing of January 1983; Byte of January 1983, November 1984, and August 1985; PC Magazine of January 1987; New York Times of November 5 1982, October 26 1983, January 5 1984, February 1 1984, and February 22 1984; Fortune of February 18 1985. Computer Wars by Charles H. Ferguson and Charles R. Morris is a pretty book book-length study of IBM’s trials and tribulations during this period. More information on the EACA clones can be found at Terry Stewart’s site. More on Compaq’s roots in Houston can be found at the Texas Historical Association. A few more invaluable links are included in the article proper.)

 
 

Tags: , , , , ,

The Quill

The Quill

Let’s begin today by stepping back in time to the dawn of the PC era (and the early days of this blog): 1978. The debut of Scott Adams’s Adventureland that year also marked the debut of the world’s first reuseable adventure-gaming engine, in which a single interpreter program runs a variety of different games by being fed different databases. And reuse the system Adams did, to the tune of six titles released in 1979 alone, while the rest of the computing world set to work figuring out how the system was put together. Two TRS-80 hackers, Allan Moluf and Bruce Hanson, were particularly dedicated. By January of 1980 they were distributing to select buddies a text file which described Adams’s database format in careful detail along with a set of utilities for examining existing games. By 1981 they had written the Adventure Executor, a new interpreter capable of playing any of Adams’s games; just provide it with the database file. And their efforts culminated in early 1982 in The Adventure System, a complete authoring package that let you create new games in the Scott Adams database format as well as dissect existing ones to your heart’s content for the low, low price of $40.

The Adventure System as advertised in the March 1982 80 Microcomputing

The Adventure System as advertised in the March 1982 80 Microcomputing

For various reasons, starting with the TRS-80 platform on which it ran being rather isolated from the rest of the computing world and ending with the small print that demanded a $200 license fee to use The Adventure System to create commercial adventures, it never caught on. Moluf and Hanson, however, were not alone in their inquisitiveness. Others across the pond were also looking hard at the Scott Adams games. Their efforts would have much more lasting repercussions.

During the earliest days of personal computing in Britain, when practitioners consisted of just a few tens of thousands of soldering-iron-wielding dreamers, one Ken Reed managed to get hold of an imported TRS-80 along with some of the Scott Adams games. Like Moluf and Hanson, Reed was as interested in figuring out how they worked as he was in playing them. He doggedly pulled the system apart, and published his findings in the August 1980 Practical Computing magazine, the nearest equivalent British hobbyists had to the American hackers’ favorite Byte. Reed’s article wasn’t so obviously practical as the work of Moluf and Hanson. It didn’t provide exact specifications of the Scott Adams database format, nor tools for hacking on the games, nor even a complete original game or a complete interpreter for running a game. No, it provided something that in the long run would prove to be much more empowering: a detailed proposal for making an engine similar to Adams’s for yourself, complete with pseudo-code listings that could be applied to virtually any platform you had handy and knew how to program.

The impact the article had on British gaming over the following decade can hardly be overstated. Richard Turner and Chris Thornton, two university students, formed Artic Computing and used the article as the basis for their own line of Adams-like adventures that began with Planet of Death, likely the first commercial text adventure written in Britain, in June of 1981. Many variations on the article’s approach were soon appearing in other games. But its most important descendent was not a standalone game at all but a complete adventure-writing system similar in spirit to The Adventure System. This system, however, got several things right that the older system had gotten so wrong. It was called The Quill, and it was the brainchild of a Welshman in his late twenties named Graeme Yeandle.

When Yeandle analyzed those early Artic games and found them to be put together in a way suspiciously similar to Reed’s system, his first reaction was to think that he could do that just as well as Turner and Thornton. He went so far as to write to Artic to offer his services, but never got a reply to his letter. Whilst messing about with adventure-game databases and interpreters on his new Spectrum, he noticed an advertisement for a local publisher called Gilsoft, located just twelve miles from his Cardiff home — in fact, in the town where he had been born, Barry. He decided to pay their office a visit. On doing so, he learned that “they” were a single teenager named Tim Gilberts, and the “office” was Gilberts’s bedroom in the family home. Still, Gilberts was bright and ambitious, and the two hit it off. (Gilberts thought Yeandle “looked just like Clive Sinclair.”) When Yeandle told him about his adventure-game experiments, Gilberts encouraged him to make a real game for him to market. He ended up writing two, Time-Line and Magic Castle, which Gilberts sold through modest classified ads in the magazines for £5 each (the former, the smaller and simpler of the pair, as the companion to another game on the same tape).

About this time Yeandle realized, like many a programmer before him, that he could save a great deal of time in the long run if he spent some time now improving his development tools. While he was using a variation of the design scheme from Reed’s article, he was still constructing the database files laboriously by hand. He discussed with Gilberts his idea for a menu-driven data-entry system to automate the process. If it worked out it could become a sort of house adventure-authoring system which Gilberts could share with other prospective authors. Gilberts enthusiastically agreed, and Yeandle spent most of his nights and weekends during 1983 — this was still very much a sideline; he was employed full-time as a systems analyst — working on what would become The Quill. As the program grew more refined, Gilberts made a new proposal: instead of just using it in-house to make more adventures, why not sell it as a product in its own right, and open adventure authorship to anyone with a Speccy? And so was the adventure-game scene in Britain changed forever.

The Quill was greeted rapturously when it debuted just in time for the 1983 Christmas season. Micro-Adventurer magazine, which appropriately enough debuted at almost the same instant, called it a “revolution” in their very first issue: “Once in a while, a product comes along to revolutionize the whole microcomputer scene. The Quill is one such, and will change the face of the microcomputer adventure.” The Quill sold for just £15, and — and this is absolutely key to everything that followed — Gilsoft asked for no cash royalty for commercial works created with it, only that you insert a little “Made with The Quill!” blurb somewhere in the final work. Most other commercial systems for creating adventure and CRPG games, both before and after The Quill, didn’t offer such convenient terms, sharply limiting their appeal.

Sales were so brisk that Gilsoft soon gave up bothering to sell much of anything else; Gilberts was more than content to run the house that The Quill had built. Within weeks of its release so-called “Quilled adventures” were everywhere. By a year or so after that at least half of the adventures on the British market were Quilled — and that’s not even considering all of the less ambitious creators who just toyed around making games for family and friends, or released their games for free into public-domain channels.

About a year after The Quill, Gilsoft released The Illustrator, which let users add graphics to their games. It ended up selling almost as well as The Quill itself, and soon the requisite illustrated Quilled games were flooding the market. Gilsoft also funded ports of the system to most of the other viable British platforms, although sadly there was no easy way of moving an adventure database created on, say, a Spectrum to the BBC Micro or Commodore 64 short of reentering the whole by hand. As the system spread across Europe, now catching onto the PC revolution at last, countless souls used it to create games in their native languages.

Quilled games in Swedish, Italian, Spanish, and Czech

Quilled games in Swedish, Italian, Spanish, and Czech

Many of the earliest adventures in German, French, Dutch, Spanish, Italian, and the Scandinavian and Eastern European languages were Quilled. An attempt was also made to market The Quill in North America as The Adventure Writer, but without much success. It was entrusted there to a tiny company called Codewriter who lacked the resources to make it known and widely distributed in that more intimidating and elitist marketplace. And so, like so much else in the bifurcated computing culture of the 1980s, The Quill remained an exclusively European phenomenon.

The Quill's menu system, where thousands of adventure authors spent thousands of hours

The Quill’s menu system, where thousands of adventure authors spent thousands of hours

Given the sorts of tools available to adventure writers today, The Quill is bound to seem underwhelming when we load it up on our Speccy emulator. One doesn’t really program a game at all using The Quill; one simply enters its data, menu by menu, filling in its rooms, its objects, its text. The logic available to the author is hard-coded into the interpreter, and not very complex at that. Nor is the process of creation a very intuitive one. It’s very difficult to get any sense of the big picture from all of these granular menu views. One is best served by planning one’s game out entirely on paper, using The Quill itself very much as the simple data-entry front-end it was originally conceived as. Even on those terms many trivial tasks are painfully tedious. The parser doesn’t really parse at all. There’s just a simple pattern matcher, which the author must micro-manage to the finest detail. One cannot simply define an object as takeable, for example, but must hand-enter the command that will allow it to be taken and dropped — and must do this separately for every single takeable object in the game. (Much of this tedium was removed in later versions of The Quill. See John Elliott’s comment below.)

Amidst all of the excitement following the system’s debut, some did voice a concern that it would lead to a rash of games that were not only primitive but all primitive in the same idiosyncratic way. Such fears were by no means entirely baseless. To some extent this is problem with any authoring system; I wouldn’t be the first to note that Graham Nelson’s droll English diction has become the voice of contemporary interactive fiction thanks to the default messages of Inform, the mostly widely used development system today. The Quill’s limitations and lack of flexibility merely make it even more immediately obvious to any experienced adventurer that she is playing a Quilled game. That said, The Quill’s relatively long life gave plenty of people plenty of time to dig deep, to learn to push it and to learn to hack it. Much better, more complex works could be created with it than you might expect after a few minutes of fiddling around in its menus. Given the limitations of the 48 K Spectrum on which it runs, The Quill is put together in a very smart way. The average Quilled game is not only easier to create but more pleasant to play than (at the least) the average BASIC game. Tellingly, no one managed to come up with a system notably better for the Spectrum and equivalent machines despite the obvious commercial potential of such a beast.

Until Yeandle himself, that is: in late 1986 GilSoft released his second-generation system, the Professional Adventure Writer (PAW). Arriving fairly late in the day for text adventures as a mainstream gaming staple, at least in Britain, it didn’t become quite the phenomenon that The Quill had been, but did power many more games throughout Europe well into the 1990s.

Indeed, it’s for that legacy of empowerment that PAW and (especially) The Quill deserve to be remembered today. It’s not that established software houses didn’t use The Quill; they did, to a surprising degree. Even Artic Computing, who had ignored Yeandle earlier, started using the Quill to create some of their new adventures. So did no less a light than Melbourne House of The Hobbit fame. But it’s mostly for all the little guys that The Quill seemed a minor miracle. North America had nothing comparable, and, presumably in consequence, far fewer independent voices making and selling text adventures. Europe, by contrast, was blessed in having not only The Quill but a marketplace willing to accept and buy works by the inspired amateurs who used it. Gilberts himself was well aware of the democratizing effect of The Quill:

Anyone who wants to write can produce a novel without technical knowledge. You may not create great art but there’s nothing to stop you trying. The Quill has opened up the same kind of opportunity to those who enjoy adventuring. We’ve tried to provide the computer equivalent of pen and paper.

No, most Quilled adventures are not great art or even great games, and they’re not likely to get as much attention on this blog as they may deserve given that I have so many other titles that qualify at least as the latter to sort through. Yet many are personal, idiosyncratic works of the sort gaming could always use more of. The best of them have a real writerly personality, another thing always in short supply in gaming fictions. Some of the most fun, and arguably the most culturally useful, Quilled adventures are the ones that satirize the solemn pretensions (especially of the high-fantasy stripe) of mainstream gaming culture then and now — titles like Bored of the Rings, The Boggit, Loads of Midnight, The Big Sleaze, or the immortal Dildo and the Dark Lord (did I mention that Quilled adventures were also more liable to traffic in sex than the titles from bigger publishers?).

The person with the most amazing Quill story of all might just be John Wilson, the founder of Zenobi Software. After publishing a few of his own Quilled games on the label in the mid-1980s and seeing them do fairly well, Wilson began soliciting games from outside authors. Even as the bigger publishers gradually got out of text adventures, Wilson built a successful if modest business out of selling the games via mail order, communicating with customers via a newsletter and whatever magazine advertising he could afford that month. Zenobi alone published almost 250 games, the vast majority of them created with The Quill or PAW, before hanging it up at last in the shockingly late year of 1997, by which time Gilsoft and the rest of the gaming milieu that had birthed Zenobi were long gone. All of which is enough to qualify Zenobi as the most prolific of commercial text-adventure publishers, the most long-lived, and the last to give it up, and all by a wide margin.

As you’ve probably gathered by now, The Quill and PAW were easily the most widely used adventure-creation systems of the 1980s. In the whole of computing history they’re rivaled only by Graham Nelson’s various Inform incarnations, which may have powered a comparable number of games by now but have taken some twenty years to do it. The architect of this creative explosion, Graeme Yaendle, never gave up his day job and never made as much money from it as you might expect. He recalls that in the wake of The Quill’s first gush of popularity in 1984 his royalty checks from Gilsoft actually amounted to more than his regular pay check — but “that didn’t last long.” The Quill was, even more so than most software, widely pirated. It’s safe to say that many of those Quilled games being sold in magazine adverts were themselves made with pirated copies; GilSoft didn’t have any practical way to keep tabs on who had bought and who hadn’t. Even their modest request that users include a mention of The Quill in their Quilled games also went unenforced and widely ignored. And consumers will always outnumber creators in any time and place, meaning that even an insanely popular engine of creation like The Quill will never sell more than a fraction of the copies of a hit game. Gilsoft and Yeandle could probably have made considerably more money from The Quill by pricing it higher and being more aggressive about asserting their rights in various areas. But Gilsoft wasn’t Microsoft and young Gilberts was no Bill Gates; he was happy if the business just paid for “my beer and a car.” Anyway, The Quill was so successful precisely because it was so cheap and easy; changes to Gilsoft’s business model could likely only have diminished its impact.

As a consolation prize for fame and fortune, Yeandle and Gilberts got to see their creation getting used all around them, the most satisfying validation any programmer or engineer (or artist?) can enjoy. And they got to know that their work was allowing people to be creative in a medium that would otherwise have been inaccessible to them. At least in retrospect, that seems like more than enough.

(Much of this article was sourced from an old interview with Yaendle from The Solution Archive. Yeandle’s now-defunct home page was also invaluable. And see also the Gilsoft features in Sinclair User #28 and #37. I discovered much of Moluf and Hanson’s work while digging through old TRS-80 file archives, an often productive if exhausting way of researching.)

 

Tags: , , ,

Brøderbund

I’ve already introduced some hackers on this blog who defied pop-culture stereotypes of blinkered nerddom with a remarkable range of interests and activities outside of computers. Marc Blank, for example, managed to finish medical school while moonlighting with MIT’s Dynamic Modeling Group, where he learned enough to become the most important technical architect behind Infocom’s technology. Andrew Greenberg of Wizardry fame went on to become a lawyer, and now “hacks the law with glee.” In its essence the attraction of hacking is the joy of coming to understand a complex, dynamic, semi-autonomous system, and then bending it to your will. Plenty else in the modern world beyond computers offers some of the same experience, medicine and law perhaps not least among them. Not to mention, to choose an obvious parallel for this blog, games.

The fellow I want to introduce you to today, Doug Carlston, had a background at least as eclectic as anyone I’ve mentioned earlier. Born in 1947 as the son of a Harvard-educated theologian, Doug by the time he was 30 already had a dizzying resume to his name: a Bachelor’s in social psychology from Harvard, studies in international economics at Johns Hopkins, and a law degree from Harvard Law School. In addition to his studies, he had also run a business designing and building houses; spent a year teaching in Botswana; written an introductory textbook on Swahili; written other language guides for American Express. But by 1977 Doug, two years out of law school, was bored, stuck with an uninteresting job with a huge law firm on the 82nd floor of Chicago’s Sears Tower. As a junior lawyer, he got “the kind of work nobody else wants to do,” like conducting client surveys and doing wills and trusts. Feeling “fat and slow” in addition to bored, he packed up and moved to a small town in Maine with a view to getting back to nature. There he set up an independent law practice serving the locals. That proved to chiefly mean defending clients who ran afoul of the stiff local hunting ordinances. Trouble was, virtually all of his clients were clearly guilty, and many never bothered to pay him for his services, making the practice both uninteresting and not terribly lucrative. To help with the latter problem, Doug began to dabble once again in housebuilding in addition to the law. Helping with the former was the TRS-80 he’d bought, ostensibly to help with bookkeeping at the office. Now, however, he just couldn’t stop playing with it.

The TRS-80 was far from Doug’s first exposure to computing. In fact, computing was yet another of those myriad of interests and activities that had marked his life to that point. He had been introduced to computers as early as 1964, when he attended a sort of summer camp for gifted teenagers who might be interested in becoming engineers. There he first dabbled in FORTRAN programming, finding it fascinating. When he went off to Harvard, he found a job there as a “programming assistant,” basically a tutor to help other students bend the machines to their will. When the time came to lock up the computer lab for the day, Doug and his buddies would stuff chewing gum into the locks so that they could sneak back in in the middle of the night and hack. Still, by the time he bought his TRS-80 in 1978 those days were many years in the past.

The TRS-80 served to reignite the old passion. Doug did use it to code programs useful to his practice, but he also embarked on an ambitious game, which he called Galactic Empire. It’s a work of considerable historical importance in its own right, quite apart from its place in Doug’s career. It was, you see, the first recognizable example of a “4X” (“explore, expand, exploit, exterminate”) grand strategy game to appear on a PC, the ancestor of such seminal later titles as Civilization and Master of Orion. The player begins Galactic Empire with a single medium-sized planet and a fleet of 200 ships. From this starting point she is expected to conquer the 19 other worlds of the game’s galaxy. Along the way she must manage each conquered planet’s economy, juggling taxes and population, in order to build more ships for her fleet. As you would expect of a game written in BASIC on a 16 K TRS-80, Galactic Empire is absurdly stripped down and primitive in comparison to its successors. Yet the core attributes — and the vision — are there.

What happened next will be familiar to anyone who read my earlier articles about other pioneers of the early software industry. Doug came up with some packaging and began selling his game directly to local computer stores, as well as through outlets for semi-professional software like SoftSide magazine’s TRS-80 Software Exchange and a similar organ run by Creative Computing. When Scott Adams started Adventure International, he signed up there as well. (Occupying a weird ground somewhere between software publisher and catalog merchant, AI did not demand an exclusive license to the software they “published.”) Meanwhile he made a second game, Galactic Trader, which replaced military with economic conquest. By the end of 1979, the two games together were bringing in about $1000 per month.

That $1000 was very welcome, because otherwise the bottom was falling out for Doug financially. The second oil crisis precipitated by the Iranian Revolution had seriously damaged the economy, and Doug could no longer sell his houses. Meanwhile it was becoming increasingly clear that his country law practice was not sustainable on its own, at least not in this economy. Barely two years after coming to Maine, he decided to cut his losses and move on, yet again, to something else. With no clear plan as yet what that something would be, he piled into his old Chevy Impala along with his 220-pound mastiff (in the front seat) and his computer (in the back) to visit his little brother in Eugene, Oregon. The car started to die in eastern Oregon. Doug:

Something went out with the transmission. It started throwing out smoke. Fortunately, by the time I got into western Oregon it was mostly downhill to Eugene because I had the windows rolled down so we could breathe because the smoke was coming up through the transmission. I couldn’t go more than 15 miles an hour and the windshield wipers wouldn’t work and it was a blizzard outside. I was out there kind of working the wipers by hand going downhill. Finally, we got down into Pendleton, which was just a lot lower than Walla Walla, and we could see again. We made it to about five miles from Eugene when the car finally gave up and my brother came and got me.

Said brother, Gary Carlston, had also made an interesting life of it so far. Like Doug, Gary had gone to Harvard, where he had planned, largely on a whim, to major in Celtic Studies. However, that program was full. On the same floor were the offices for Scandinavian Studies. He knew that the Carlston family had originally come to the United States from Sweden, and like his brother he was fascinated by languages, so what the hell… six years later, he had a Master’s in Scandinavian Languages and Literature. In the midst of that, Gary decided to spend one summer holiday in, appropriately enough, Sweden. An accomplished basketball player and coach, he got into a pick-up game with some locals there. One thing led to another, and Gary found himself returning the following year for a gig that was, in Steven Levy’s words, “so desirable that grown men gasped when he mentioned it”: coaching a Swedish women’s basketball team. Gary himself would later say, “Most girls in Sweden don’t look like the tall model type you’d expect.” Pause… wait for it. “This team did, though.” Whatever its perks, he proved to be good at the fundamentals of his job, leading the team to three championships and two runners-up in five years.

With Harvard and basketball behind him, Gary was faced with making a living in the real world. He briefly taught Swedish in a summer program, but the language was hardly in huge demand in the United States. He worked for a year as a director of the March of Dimes charity in Eugene, but he hated it, and finally quit. That was in the summer of 1979. When brother Doug arrived for his visit, Gary had already spent six months fruitlessly looking for another permanent job while trying to bring in a little something selling reflectors to the parents of schoolchildren.

So, the two brothers, both completely broke, compared and contrasted their misfortune and wondered what the hell to do next. Then Doug, remembering the one thing that had been going pretty well for him lately, suggested that they start a real software publisher to sell his games instead of relying on the semi-professional distribution networks. The very non-computer-literate Gary allegedly replied, “What’s software?” He took some convincing, but, with no other prospects on the horizon, finally agreed. Brøderbund Software was officially founded on February 25, 1980, with $7000 the brothers were able to scrounge from their last savings and their family. As Doug later told Forbes magazine, the company was born at that place and moment only “because I was stuck without a car and didn’t have the money to buy a new one.”

The name “Brøderbund” itself is of course an odd one that would never pass muster with a corporate public-relations department today. It actually first appears in Doug’s very first game, Galactic Empire, where it’s the name of one of the warring factions. “Brøderbund” is a compound noun that is vaguely recognizable to speakers of a number of languages, but isn’t quite correct in any of them. In Danish and Norwegian, the word “brødre” is the plural of “bror,” which means “brother.” (The “ø” is a special vowel found only in Danish and Norwegian; it’s pronounced like the German “ö,” and, also like “ö,” is often used in plural forms of nouns.) It’s probably acceptable to change it to “brøder” in a compound word, to make pronunciation easier. However, the second part of the name, “bund,” is in no sense correct. The intended meaning is obviously the German “Bund,” meaning a bond or union. Yet in Danish or Norwegian the correct word would be “forbund”; “bund” alone means a ground or base, obviously not the intended meaning. So, what we have here is a mash-up of Danish and German — or an example of a sort of pidgin Danish, if you prefer.

Which is not to say that the Carlston brothers didn’t know exactly what they were doing in creating the name. Both were fascinated by languages, and enjoyed this sort of linguistic play. They chose to use the Danish and Norwegian word for “brother” in place of Gary’s more familiar Swedish because Swedish uses German-style umlauts; thus the word would have become “bröder.” The problem with “bröder” was that the “ö” would be impossible to represent on computer screens of the time. The “ø,” however, could be represented by simply typing a zero; then as (sometimes) now, computer displays used the slash to easily distinguish “0” from “o.” This also made the name a clever play on computer technology itself. Even in their professional copy, where the proper character would presumably have been available, the company would often write “Brøderbund” as “Br0derbund” to reinforce the computer connection. As for pronunciation… let’s not even get into that. Suffice to say that everyone just said the name as “Broderbund,” although that’s not correct if we insist on reading it as a Scandinavian word.

Linguistic issues aside, Brøderbund was not a stunning success in its early months. They did have three games to sell, in the form of Doug’s Galactic trilogy. (He had recently completed a third and final game in the series.) Yet, with Softsel yet to be founded, software distribution to retail was in a confused and uncertain state, and neither brother was naturally suited to cold-calling stores to try to sell them on their products. May of 1980 was the low point; it seems incredible, but Doug claims that sales for that entire month were exactly $0.00. Then two things happened that would begin to turn the company around.

At the very first trade show at which they exhibited, the West Coast Computer Faire of March 1980, the Carlstons had made the acquantence of the Japanese software company Starcraft. In June, they got a call from them. As I mentioned in a recent post, Starcraft would later make a big name for itself within Japan by porting and translating Western games for the domestic market. At this point, however, they were reaching out to the West with a view to moving software in the other direction. They had coded several solid action games for the Apple II. Now they were looking for an American partner to sell them for them. This was a huge break, not only because the flashier Starcraft titles diversified Brøderbund’s portfolio greatly when contrasted with Doug’s more cerebral text-oriented strategy games, but also because these games ran on the Apple II, already a much more vibrant and healthy software platform than the Radio Shack-strangled TRS-80. From this point forward, Brøderbund would also switch their emphasis to the Apple II, porting the Galactic trilogy over and developing most of their new software for that platform first.

Shortly after the Starcraft deal was made, Gary got a call from his beloved old basketball colleagues from Sweden, saying they were coming to San Francisco and wanted to meet him there. When he told them that he didn’t have the money to come, they said they could pay for half of the trip — for a one-way ticket from Eugene to San Francisco. The brothers hatched a plan: Gary would fill his suitcase with software, then visit every computer store he could find in the Bay area, attempting to sell the stuff to them personally and hopefully earn enough to get home again. It worked beautifully; he sold almost $2000 worth of software. In the absence of a proper distribution network, the way forward was now clear: they must visit stores personally to sell the owners on their games. At the end of July, Doug took off on a zigzagging road trip to Boston and back, and sold some $15,000 worth of games on the way.

Still, it was a fairly time-consuming and expensive way of moving product, and times remained tight. Doug:

We were going weeks where we only ate on three days; things were that tight. We had used up all my savings from being an attorney and were maxed out on my credit card. My parents didn’t have any money. [In] October my mother lent us $2000 that she had inherited and her sister also lent us $2000.

Then, near the end of the year, Starcraft gave them a goldmine in the form of Apple Galaxian, a perfect clone of a new hit arcade game from another Japanese company, Namco. Soon enough people would be getting sued over far less blatant copying, but it was, ironically given the company’s later reputation for integrity and innovation, this unabashed arcade ripoff that really established Brøderbund as a major player in the software industry. Doug claims today to have not even been aware at first that it was a facsimile of someone else’s game, as the game had just recently been introduced to North American arcades.

Critically, it was at just this point that Softsel, the first proper software distributor, arrived on the scene, making it much easier for Brøderbund and other companies to get their products into stores around the country without the necessity for personal meet-and-greets. Bob Leff of Softsel played a key, and very personal, role in Apple Galaxian‘s success. Doug:

When I sent him a copy of this new game, he said, “We love it, and I want 5000 copies right away.” And I told him, “I’d love to do it, but I don’t have 5000 disks, and I don’t have enough money to buy 5000 disks.” He said, “I’ll tell you what, I’ll lend you the money. You buy the disks and I’ll lend you the money as long as you send them all to me.” I said okay. And he sold everything within a month.

Brøderbund’s sales went from $10,000 in November of 1980 to $55,000 in December, all on the strength of Apple Galaxian. In fact, their sales for December amounted to more than those for the entire rest of the year. Apple Galaxian topped the Softalk magazine chart as the bestselling Apple II program in the country for three months. (Yes, it even outsold VisiCalc during that period.) With both Namco and, oddly, Apple themselves beginning to make legal rumbles, Brøderbund changed the name to Alien Rain in the spring of 1981, and it continued a bestseller for quite some months under its new moniker.

On the back of Apple Galaxian/Alien Rain, the Carlstons could begin to hire some employees and make bigger, more ambitious deals with a growing stable of outside developers. They brought in their younger sister Cathy, who had been unhappy in her job as a retail buyer for Lord and Taylor, to take the role of office manager. And they branched out into productivity software, for which they would soon become more famous than they were for their games. Bank Street Writer, an innovative word processor, was a particular hit, as was the first really complete payroll package to be released for PCs. In the summer of 1981, they left Eugene, which they felt was just too isolated and small to be conducive to their business and which had a horrible problem with fog that sometimes shut down the airport for a week or more at a time, for San Rafael, California, a town in the vicinity of San Francisco that was most famous for being the home of George Lucas and his production company Lucasfilm. In typically unpretentious fashion, they effected the move by renting three U-Haul trucks, packing everything up, and driving the lot down themselves.

You’ll have a hard time finding anyone who knew or worked with the Carlstons with much bad to say about them. For years the siblings each took a regular shift on Brøderbund’s production line, by all indications not as a gimmick but out of a real, heartfelt desire to demonstrate “the dignity in all of the work” at the company, and to have a chance to bond and really talk with their employees. Indeed, they found themselves caring more for their employees than any business guide would recommend, sometimes giving them a second chance even after they were caught stealing. Doug: “It turns out that Gary was the only person who could fire people — which is a valuable skill. He didn’t like it but he was able to do it.” Doug also demonstrated what would seem a hopelessly naive attitude toward his direct competitors. He called them all the “brotherhood,” and even wrote a book in 1985 (the long out-of-print Software People) to sing their praises. Somehow he and his siblings got rich in the cutthroat world of capitalism in the most subversive way imaginable: by just being really nice and fair to everyone, and never losing their idealism about the software they produced. Or anyway, that was most of it. As a story I’m about to retell will illustrate, there was a certain competitive edge to be found under their more cuddly qualities.

Everyone liked the Carlstons, but Brøderbund forged a special bond with On-Line Systems. Although the religious Carlston clan did not share the Williams’ taste for partying, the two companies were otherwise remarkably similar. Both were founded at almost the same time; both focused their early efforts on the Apple II; both enjoyed a relaxed internal culture unconcerned with rank or title; both published a diverse array of software, mostly from outside programmers, rather than specializing like, say, Infocom; both were headed by erstwhile hackers who found less and less time to write code as their businesses grew; both shared the conviction that they were doing something that really mattered for the future; both would ultimately prove to be long-term survivors and winners in a brutal industry, outliving virtually all of their other peers. Especially after making the move to San Rafael, the Williams and the Carlstons saw quite a lot of one another, and shared more trade secrets than any MBA would recommend.

The Carlstons were naturally all invited on that On-Line-sponsered, era-defining whitewater-rafting trip in the summer of 1981. One evening on that trip Doug and Ken Williams seriously discussed merging their two companies, but ultimately decided that it wouldn’t make sense. Normally a company merges with another to get something it lacks, but their two companies were so similar that it was hard to see what that something could be, in the case of either — not to mention the stress of sorting out locations, products lines, management structures, etc. Most of all, it became pretty clear that neither Ken nor Doug was very interested in giving up any control of the company he had founded. Instead they would continue as unusually friendly competitors for more than 15 years.

Another incident from the trip shows why that may have been for the best. While drifting down the river, the group came to a spot where “the water was deep and smooth, and cliffs rose up above the river banks.” Ken shouted to stop the boats, so he and whoever else wanted to could climb up to the cliffs and dive off. Quite a large number, including Roberta and Doug and his sister Cathy, who had swum competitively, decided to join him. At the top, however, Ken got cold feet, even as others were taking the plunge. He begged Doug to go back down with him and Roberta, so they wouldn’t have to be the only chickens in the group. Doug said no, and, to encourage him, suggested that they all four hold hands and jump off together. Ken agreed, they joined hands and ran toward the edge — but Ken balked again. In the end he and Roberta climbed back down in shame, while Doug and Cathy made the leap. “I pushed myself a little further than I was ready to handle,” Ken said. They were all friends, Doug layer wrote, “but we all like to win, and if the other falters, we aren’t likely to wait too long for him to catch up.” In his own quiet way Doug was as driven to win as the blustery Ken — or, as demonstrated by that moment on the top of the cliff, perhaps more so.

Brøderbund may have been having more and more success with their productivity software, but they were hardly ready to abandon games. Indeed, their action games were amongst the most popular and highly regarded on the Apple II. We’ll look at a particularly important title in their stable, released just about a year after the rafting adventure, next time.

(The early history of Brøderbund has been very well documented. The most useful sources for this article were: Steven Levy’s Hackers; Doug Carlston’s own Software People (out of print); the lengthy interview Doug Carlston conducted with The Computer History Museum in 2004; and a profile of the company in the September 1984 Creative Computing.)

 
 

Tags: , ,

Selling Zork

When we left off, it was late summer, 1979, and seven of the nine partners involved with Infocom were living in Boston, working various day jobs, and discussing as time allowed just what the newly minted company should actually do. Meanwhile, the other two partners, Marc Blank and Joel Berez, were living in Pittsburgh and doing something more practical about the question, designing — entirely on paper at this stage — a system for getting Zork (or at least half of it) from the PDP-10 to the microcomputer. As Blank and Berez continued their work that fall, they became more and more convinced that, yes, this could actually work, and so began lobbying the others back in Boston to make Zork Infocom’s first project. Their case was compelling enough that even a reluctant Al Vezza finally agreed.

As it happened, Berez had been accepted for a graduate business program at MIT’s Sloan School of Management. He moved back to Boston that November for that — and to take the title of President of the still largely theoretical Infocom. Faced with being trapped in Pittsburgh all by himself while his friends implemented his designs, Blank made the rather personally momentous decision to drop out of his medical residency and come to Boston as well. Thus, as 1980 dawned the proverbial gang was all back together again, and work on a new Zork was proceeding apace.

With their connections at MIT and DEC, PDP-10 computer time was not hard to come by even for those at Infocom who had officially left MIT. Indeed, for all that their ultimate goal was to sell Zork on the micros, Infocom continued at this stage to do their work entirely on the PDP-10; perhaps the old motto of “We hate micros!” was still not entirely dead. Blank and Lebling wrote on the PDP-10 the complete ZIL development system, including the compiler and, for testing purposes, the first working Z-Machine virtual machine. Remarkably, the conceptual design that Blank and Berez had sketched out on napkins and scrap paper turned out perfectly workable in reality. As I noted in my last post, the reimplementation in ZIL even gave them the opportunity to improve on the original Zork in some ways.

Even when the time came to leave the PDP-10, Infocom’s biases showed through; the second Z-Machine implementation was not for a Radio Shack or an Apple, but for a DEC PDP-11. While the PDP-10 was DEC’s flagship model, big and powerful enough that it probably deserves to be labeled a mainframe rather than a minicomputer, the PDP-11 was the company’s smaller, cheaper bread-and-butter model. DEC is estimated to have sold over 170,000 of them during the 1970s alone. Relatively portable (if being able to move a computer with only a single van can count as “portable”) and requiring no raised floor or other data-center machinations, PDP-11s were everywhere: in factories, in laboratories, in air-traffic control centers — and in Joel Berez’s bedroom(!). The PDP-11 already had a Zork in a sense, having been the first target platform of that FORTRAN port of Dungeon, but that didn’t stop Infocom from making PDP-11 Zork their first commercial product. Relatively ubiquitous as the PDP-11 was, the market was not exactly a commercial gaming stronghold; Zork reportedly sold less than 100 copies there. (One of which recently surfaced on eBay; see Jason Scott’s Get Lamp site for a scan of the surprisingly thorough — albeit typewritten and mimeographed — manual.) Clearly, Infocom needed to get Zork onto the microcomputers.

In that spirit, Infocom purchased a TRS-80 system, and Scott Cutler, one of the few partners with any real microcomputer experience, set to work with Blank’s help to build a Z-Machine for it. The moment of truth came at last:

Scott and Marc demonstrated that Zork I was alive in it by starting the game and actually collecting points with the incantation “N.E.OPEN.IN.” (It’s certainly no less inspiring than “Come here, Mr. Watson; I want you!”)

It’s always a fraught moment when a programming project finally comes to life and does something. I remember my excitement when my own Z-Machine interpreter, Filfre, first printed out the opening text to the first game I elected to test it with, Infidel. I can only imagine Blank and Cutler’s excitement, when all of this was so new and the stakes were so much higher. Anyway, the Z-Machine concept worked. Once the game was completely playable, Infocom, heirs to an institutional computing tradition of doing things the right way, did something virtually unprecedented for a microcomputer game: they put their new game through rigorous, repeated testing. Their star tester was an MIT student named Mike Dornbrook, who fell in love with the game and obsessed over it endlessly, crafting lovingly detailed maps of its geography and working to iron out not just technical problems but dodgy puzzles and parser difficulties. (If only On-Line Systems, Scott Adams, and other developers had a similar patience and commitment to quality in these early days…)

Ongoing testing aside, Infocom had a real, marketable product. Now they just needed to decide how to sell it. One option was to do what Ken Williams was deciding to do at about this time, to go it alone. With little experience or knowledge of the young microcomputer industry, however, that seemed risky, and no one was excited about trying to devise packaging and duplicating thousands (hopefully!) of disks. They therefore began shopping Zork to publishers. An approach to Microsoft was rebuffed by the marketing department; they already had their own text adventure, Adventure itself, and apparently felt one was enough for any publisher. Later Bill Gates, who was a fan of the PDP-10 Zork, heard about the offer and tried to reopen the subject, but by then Infocom was already in talks with Dan Fylstra of Personal Software, leaving a Microsoft Zork to history as a fascinating might-have-been.

Personal Software has largely been forgotten today, but at the time it was the brightest star of the young software industry, easily eclipsing Microsoft. Founded by Peter R. Jennings and Fylstra, a founding editor of the seminal Byte magazine, PS hit a goldmine in 1979 when it reached an agreement with Dan Bricklin and Bob Frankston to publish VisiCalc for the Apple II. Aided by some smart PS advertising that properly emphasized the revolutionary nature of this truly revolutionary product, VisiCalc was by the time Infocom came calling the talk of the business world and the software hit of the young microcomputer industry, eventually selling in the hundreds of thousands. VisiCalc not only made PS the biggest software publisher on the planet and the subject of profiles by the likes of Time magazine, but also gave them huge power within the industry. This power extended even to Apple itself; countless customers were putting the cart before the horse, buying Apple IIs just to have a computer to run their new copy of VisiCalc on. It was the first “killer app” of the PC era, and sold all of the Apple IIs that that label would imply. With money and power like that, PS certainly seemed not a bad way for Infocom to get their new game out there. Fylstra had attended business school at MIT, and was acquainted from there with both Vezza and the PDP-10 version of his product. It didn’t take Berez and Vezza much time to get a deal done which even included a sorely needed advance on future royalty payments, what with Infocom having pretty much spent their initial $11,500 on hardware, testers, and PDP-10 time.

In between their other tasks, the other partners wrote a couple of magazine articles to help drum up anticipation. “How to Fit a Large Program into a Small Machine,” a cagey explanation of the concepts of the virtual machine and virtual memory, appeared in Creative Computing that July; “Zork and the Future of Computerized Fantasy Simulations,” a more theoretical article on the burgeoning art of the text adventure, appeared in Byte‘s big “adventure” issue in December. Having not yet come up with the elegant name of “interactive fiction,” Lebling saddled Zork and its peers with the rather unwieldy “computerized fantasy simulations” (“CFS”) label in the latter. As it appeared the TRS-80 version of Zork was just coming onto the market under the PS imprint.

Initial sales were not overwhelming; the TRS-80 version sold about 1500 copies in its first nine months. This figure can perhaps be partly attributed to the unimaginative and halfhearted marketing of PS, who in the wake of the VisiCalc juggernaut were increasingly uncertain whether they wanted to be involved with games at all. It’s also true, however, that the TRS-80 software market never really thrived in the way that sales of TRS-80 hardware might make you expect. A big culprit was Radio Shack’s own policies. They insisted on selling in their stores only software published under their own imprint. Yet they offered developers a very paltry royalty compared to the rest of the industry, and refused to even properly credit them on the software itself, preferring the image of an all-benevolent Tandy Corporation that apparently dropped immaculate software creations out of its rear end. Owners of other computer stores, meanwhile, such as the ComputerLand outlets that were exploding across the country, left Radio Shack to sell and service its own machines, instead concentrating on other platforms. It’s likely that the TRS-80 Zork fell at least partially into this distributional black hole that was already in danger of making the TRS-80 an also-ran in contrast to the young microcomputer industry’s newly anointed darling, the Apple II. In fact, that very December Apple went public, making its founders and about 300 others instant millionaires — the first big tech IPO, and a sign that soon the “microcomputer industry” would just be the “computer industry.”

Speaking of which: Bruce Daniels, the only member of the original Zork team who hadn’t joined Infocom, had accepted a job with Apple and moved to California after graduation. He agreed to create a Z-Machine for the Apple II under contract. Apple II Zork was released in February of 1981, and it did much better than the TRS-80 version, selling a steady 1000 copies per month. Infocom now had a steady stream of revenue at last, along with the basic technological infrastructure — ZIL and the Z-Machine — that would define the company for the rest of its life. Things were starting to look pretty good — but twists and turns were just ahead.

We’ll talk about them soon enough, but next time I want to leave the historical reality behind for a while in favor of virtual reality. Yes, we’re going to take a little tour of Zork‘s Great Underground Empire.

 
9 Comments

Posted by on January 11, 2012 in Digital Antiquaria, Interactive Fiction

 

Tags: , , ,