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

15 Jan

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

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 Woods’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 closest 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 of 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.


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 to 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 Mastodon, 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: , , , , , , , , , , , ,

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

  1. Carl

    January 15, 2016 at 4:42 pm

    This is one of your most fascinating articles yet, largely because I am so ignorant of the subject.

    I’m not sure what the technological basis is of it, but Propellerhead’s Reason music composition and audio software has proven famously impervious to cracks. While their market share is low, rumor has it their profit share is quite high, largely due to the lack of cracked copies.

    Also, a tiny philosophical comment. You state that FLT’s scheme was so original they applied for and were granted a patent for it. Sadly, receiving a patent for something is in no way evidence that said thing was original. Such is the sad state of our patent system.

    • Jimmy Maher

      January 15, 2016 at 6:31 pm

      Point taken, but patents like this one involving both software and hardware tend to be more defensible than many of the pure software patents out there. It wasn’t even accepted that a software process alone *could* be patented until the 1980s. Sometimes I wish that software had remained excluded from patent protection…

      • Nathanael

        March 6, 2021 at 12:48 pm

        Consensus is still that pure software patents are invalid. Because it’s math and you can’t patent math. The Supreme Court rulings actually still say this, but the Federal Circuit has made a lot of incorrect rulings. Eventually the courts will catch up; SCOTUS has slapped the Federal Circuit a few times in the last decade.

        The game among the crooked companies is to try to present a piece of pure math in a way which doesn’t look like pure math to math-ignorant judges.

    • Ian Schmidt

      January 16, 2016 at 6:59 pm

      Yeah, weak bits were definitely in use on at least the Apple II before FTL’s patent (@a2_4am has encountered several cases), but of course at that time nobody was going to step forward and claim prior art.

  2. Steven Weyhrich

    January 15, 2016 at 7:57 pm

    Well written, and a fascinating introduction into the murky world of copy protection (and copy breaking). Bravo!

  3. Wade

    January 16, 2016 at 4:26 am

    I suspected this would be a thorny one to write, given how detailed cracking techniques are. But I haven’t seen any angry crackers telling you off yet ;)

    For anyone who’d like to experience some more cracking, Antoine Vignau has a Youtube video series showing some real-time Apple II software cracks, plus general techniques such as analysing the sounds the drive is making for clues. Here’s the playlist:


  4. Wade

    January 16, 2016 at 4:33 am

    PS – Sorry, I should qualify, the series starts with a full crack (22 minutes) then the other videos (about 30 seconds each) demonstrate the disk sound and drive head movements corresponding to different Apple II copy protection schemes.

    Cracking remains important for all these computers because often the only version of a game available is one that was cracked in the day. And sometimes crackers missed features or bugs in their haste, or replaced game elements with their crack messages.

    There’s a renewed interest on the part of people who are into these computers, as part of long term software preservation, to collect – or dig up from their vaults – original copies of the commercial floppies, and to produce ‘clean’ cracks, which remove the protection while preserving the game content verbatim.


    • Pedro Timóteo

      January 16, 2016 at 7:30 pm

      and to produce ‘clean’ cracks, which remove the protection while preserving the game content verbatim.

      Even if all the content is there, a problem I remember from back in the day (on the ZX Spectrum), and which I still see today (on emulators of several systems) is when the cracked versions (because, I assume, the crackers don’t really play the games, and/or assume everyone has the same machine they have) drop support for enhanced systems.

      For instance, many Spectrum games would have enhancements when ran on a Spectrum 128k (or +2, or +3, or +2A/B). Not huge enhancements (usually just better sound, and/or loading the entire game in one go instead of loading separate levels on demand from tape), but they were there. But… many cracked versions (which, for most of the Speccy’s lifetime, were the only way one could get any games in Portugal — originals sold in stores only came much later here) dropped all that, and ran as if under a basic 48k system.

      Other games had a 48k version on side A of the tape, and a 128k version on side B. Guess which side the pirates typically copied, and which one they didn’t.

      And while I’m certain that, as Jimmy said, some games are preserved these days only because cracked versions exist, one could also make the argument that it’s possible that, at least in some cases, no original versions still exist because people thought the cracked versions were good enough…

  5. Peter Ferrie

    January 16, 2016 at 5:04 am

    Excellent article! Yes, some of us from the old days are still around, and are still finding titles 30 years later to preserve for the first time. Also, for an in-depth description of copy-protection techniques on the Apple II, look for POC||GTFO #10 soon!

  6. Bruno

    January 16, 2016 at 12:43 pm

    What do you think of recent trends in software distribution making some pirates announce the end of piracy?Like in this RPS article, on how Just Cause 3’s DRM has still not been cracked? Does online change all this?

    • Jimmy Maher

      January 16, 2016 at 1:53 pm

      I did see a similar article on Ars Technica, but I can’t speak to whether it really does represent a sea change or just a hiccup in the status quo. We’ll probably have a better idea in a year or two. I must say that I don’t envy Digital Antiquarians of the future who want to look at recent games in their original forms. DRM aside, the online components are going to make preservation a nightmare.

      • Peter Ferrie

        January 16, 2016 at 4:32 pm

        It’s more a case of the zero-week release is going away, because the DRM is becoming harder to break in that timeframe. That was always expected. Cracking itself is never going away, for as long as people want to try something without (ever) paying for it.

  7. John Girvin

    January 16, 2016 at 2:17 pm

    Nice article. Such memories. I was a Teen/20s cracker (Amstrad CPC, Amiga) and probably got more enjoyment out of cracking games than playing them. I had the spare time and the obsessive personality (I still have one of those). There was a shop where I lived that let you rent 2-3 games for a week and the challenge was to crack them all before they had to be returned. Good times.

    In the 2000’s I got back into it as part of the WHDLoad project to recrack and fix Amiga games to run from hard drive and on expanded machines, and I’ve also dumped GCR/MFM perfect clones of some rare games I had to preserve them for the Software Preservation Society.

    I wasn’t aware Dungeon Master was the first to use weak bit protection, but then I was never an ST man.

    RNC Copylock, an off the shelf Amiga weak-bit based protection system, appeared not long after Dungeon Master and remained in use, with various revisions, throughout the Amiga’s life. I’d hazard a guess it was the most popular Amiga disk protection used. While it could never be copied using the Amiga’s disk hardware, after a while parallel port dongles became available (Cyclone, Synchro Express) that allowed finer control of an attached floppy drive and enabled copying even these heavily protected disks.

    The Amstrad, late in its life, had a disk protection that relied on the fact that its disk hardware could read but not write a certain size of disk sector, so the disks could never be copied using a standard Amstrad floppy drive. I think you could copy them using an Amiga though.

    Exile on the Amiga was another example of a game that used repeated checks and fail-soft techniques to thwart crackers. If a protection check failed later areas of the map became subtly impassible and you could never complete the game. It was only finally 100% cracked in 2009, 21 years after it was released.

    • Jimmy Maher

      January 16, 2016 at 9:52 pm

      Good to know, as Exile is on my list of games to look at for future articles. I believe the (definitive) Amiga version came out a little later than the BBC original, though, circa 1991. So not *quite* 21 years. :)

      • John Girvin

        January 16, 2016 at 11:21 pm

        1991, you’re right. 18 years is still well outside the sales window though:)

      • Slator

        January 26, 2016 at 3:42 pm

        The C64 version of Exile had the same nasty ingame protection that does several checks during play and then alters the gamecode to not to be able to get any further.

        It was completely deprotected in 2009 by the Australian Cracker named “Ksubi”, so it took 18 years till a complete crack on C64, too

    • Bojan

      January 17, 2016 at 5:55 pm

      Amstrad had 3″ disks. Are you sure that Amiga’s 3.5″ drive would be helpful with that?

      • Pedro Timóteo

        January 18, 2016 at 11:16 pm

        Maybe he meant an Amstrad PC compatible?

      • John Girvin

        January 20, 2016 at 6:49 pm

        Yes, you could connect the Amstrad 3″ drive unit to an Amiga and get better control of it than with the standard Amstrad FDC.

      • Iván Díaz

        January 20, 2016 at 9:41 pm You can connect a 3″ with a special circuit. The floppy controller of an Amstrad is the same as that of a PC, in fact you can connect a 3.5″ to the amstrad. The floppy controller of an Amiga is much more flexible and programmable, so it can read/write more formats.

  8. MalcolmM

    January 17, 2016 at 1:21 am

    An excellent article as always. It brings back many fond memories of my days as an Atari 8 bit computer owner and sometimes pirate.

    The popular and expensive option for copying Atari 8 bit disks was an add on board from Happy Computers. I seem to recall it cost around $300 Canadian in the early 80’s, around $600 with inflation.

    I didn’t have a Happy add on so I mostly bought my games. The only very minor hacking I remember doing was adjusting the speed of my disk drive. If I recall correctly, the game companies would sometimes write bad sectors to the game disk which prevent simple backup programs from copying the disk. By opening up the disk drive and lowering the disk speed you could copy the disk.

    Penguin Software was famous for not copy protecting their software. They also priced their software quite aggressively. Sadly it didn’t help them survive very long.

    Some popular titles such as the Miner 2049 series were (to my knowledge) only released in cartridge format on the Atari 8 bit computers. I think one motivation for this was to at least slow down how quickly the game was pirated.

  9. Andy Toone

    January 17, 2016 at 4:27 pm

    A great article, and very interesting from the perspective of a Brit who grew up with tape-based systems. Disks arrived relatively late on the scene here. Prior to that the arms race between developers and pirates focussed on the huge flexibility tape storage offered to the programs reading them. Whilst direct duplication was always possible in theory, the reduction in quality over successive generations meant that cracking the recording scheme was necessary to create an exact copy of the original bits. Thus we had ever more complex recording systems (often with the side effect of massively reducing loading times), and every more sophisticated software to analyse and reproduce the data.

    Then someone realised you could create hardware to physically dump the state of your computer to disk or tape (or in the case of the Sega, to a blank cartridge) and the war moved on..

  10. Yeechang Lee

    January 18, 2016 at 7:37 pm

    Jimmy, if you plan to write more on copy protection, exploring the Atari 8-bit market specifically would be interesting. The Happy Computers product MalcolmM mentioned was so influential and widespread that publishers specifically cited it as a reson for not releasing new games for the platform!

    • LAK

      January 19, 2016 at 4:09 pm

      I was no pirate, but I did crack Fort Apocalypse on the Atari 800. I had bought the game, and didn’t give it to anyone else.

      I remember that it was pretty easy. I don’t remember too many of the details, but at some point in the boot process, it loaded the contents of one of 4 sectors, randomly selected, and tried to execute the contents(?). I think it turned out that one of those sectors was a bad sector. The crack wound up being to just NOP out the instructions that did the weird random sector load logic.

  11. Norman Rafferty

    January 20, 2016 at 1:15 pm

    Great article, as always! This couldn’t have been easy to write, to strike that balance between technical-talk and accessibility.

    Tangentially related to this article, does anyone know where I can find audio (or video with audio) of those horrible noises that Commodore 64 drives used to make? And not just from the DRM methods used, but also from Epyx’s Fast Load or the like. Thanks in advance.

  12. Carl

    January 20, 2016 at 6:32 pm

    I was no pirate either, but I had a go at “cracking” Spy Hunter on the C64 using a Nibbler. I had received the original disk for a birthday present. It seemed to go OK until the title screen came on and a banner went across the bottom saying “We Prosecute Pirates”… that terrified my brother and me! We turned off the lights and closed the curtains, certain that the FBI was on the way.

  13. Sniffnoy

    January 23, 2016 at 8:04 am

    What I don’t understand is, why was it so hard to get the computer to read the disk at, like, whatever the most basic level was — that of particular bits (or groups of bits) at particular locations — and copy it truly raw, without even the structure of sector-by-sector? Like yes OK sector-by-sector is “deeper” than file-by-file but it’s still not totally raw, given that other games had the computer use alternate sector structures. And if it was possible for them to do that, it must be possible for the computer to get at the disk at a more primitive level than the sector level; if it weren’t, the games couldn’t do it either. Maybe not all the way down to an-individual-bit-in-an-individual-location, but whatever the most primitive level the games could access, copying at that level should suffice.

    Obviously this would stil have been useless against Dungeon Master’s crazy hardware-level trick. But it would seem like that would be the only thing.

    I would assume that the generally not doing this implies that there was a good technical reason, but nobody’s stated here what it might be and I’m pretty baffled.

    • Jimmy Maher

      January 23, 2016 at 10:03 am

      Tracks are not difficult to track (ha!) using strictly mechanical means, as they’re just steps of the disk drive’s stepper motor. The contents of a track, however, are more complicated.

      The first thing to understand is that a disk drive can’t read an entire track in one spin. It rather picks up a little at a time. To do that it needs to know *where* on the track the portion currently under the read/write head is located, even if it’s just in relation to some arbitrary, random starting point. That’s one of the purposes sectors serve. If the drive doesn’t understand the organizing scheme to the data on the track, it has no way of knowing where it is on the track, no way of knowing where it should pick up reading again after it digests the first little bit of data. The same problem applies to trying to write the data to a new disk.

      It’s not possible to judge from timing alone because tolerances on 1980s floppy drives weren’t all that exact. Rotation speeds could vary by 5 percent from drive to drive on some systems, and might not even be consistent in the same drive from track to track and hour to hour. And of course the slightest error would mean an imperfect — i.e., useless — copy.

      In the earliest days, many disk drives used physical start-of-track markers, little notches cut in the disk itself. It’s conceivable that the method you describe might be made work on such a system with sufficiently clever programming. However, these went out of technical fashion by the time that floppy drives became popular on PCs in favor of a software-only approach.

      There are methods using non-standard hardware to do what you describe, and disk-image formats have been developed to store the resulting copies. They aren’t, however, all that commonly used in the emulation/retro-gaming community, largely I think because the various projects that collect images in these formats are trying to be good citizens when it comes to copyright, and thus don’t make the images available for distribution. I’m a little dubious on their logic here — I’m more of the “put it up publicly, and take it down again if someone actually cares enough to complain” persuasion — but, hey, I’m sure they’re doing what seems best to them.

      • Sniffnoy

        January 23, 2016 at 8:27 pm

        Interesting, thanks! So basically then what you’re saying is that there isn’t some nice random-access abstraction which serves as a common primitive layer to all these unusual disk setups, but that in fact the various routines the games would use to read their unusual disk setups involved using their foreknowledge of their particular format to make sense of the messy placements of the bits themselves.

        I guess a simple analogy would be if you had, say… did floppy disks use RLL coding? If you had two floppy disks that used different RLL codes (or something similar — a way of encoding virtual bits as physical bits in a situation where without some structure you can’t really get at individual physical bits). Either could be read with the proper software, but there’s no common layer that can read the underlying bits for both, because if there were, you wouldn’t need to use RLL coding in the first place. (Hm, is that something RapidLok or other such systems actually did?)

        • Jimmy Maher

          January 23, 2016 at 8:47 pm

          Both GCR and MFM, the two most common floppy-encoding schemes, did do RLL.

          But, yeah, I think you’ve got it. On the Apple II, each sector begins with D5AA96. If you don’t know that, it’s impossible to know where a new sector begins and thus impossible to figure out where you’re reading from the disk. All you can do is take random swipes at the tracks and try to puzzle it out. (Which presumably is, of course, what some crackers were doing.)

          • Peter Ferrie

            January 25, 2016 at 12:49 am

            On the Apple II, _using DOS and standard sectors_, each sector begins with D5AA96. A light protection method was to simply change one of those values and customize DOS to recognize it. The bigger problem is that the values are not discreet. Rather, it’s one enormous stream of bits, and the read head must be “synchronized” to the stream in order to know where even one value starts. That’s the purpose of the timing bits which I described in my article in PoC.

  14. Joseph

    May 26, 2016 at 6:24 am

    This brings back some memories. I was a C=64 owner when I was a teenager, and my high school’s computer room was all C=64 units. A sort of informal pirate ring formed there, and some students seem to be able to get the cracked games from somewhere – I never knew where. There was no internet as such back then, so I assume someone much have had access to one of the crude online bulletin boards. I remember having a pirated copy of Fast Hack ‘Em – one of the later versions with the Parameters, each designed specifically for a certain game.

  15. David

    May 7, 2017 at 7:14 pm

    Your definition of what RAM storage is is wrong. RAM means the storage can be both READ and WRITTEN, in contrast to ROM – Read-only memory. It has nothing to do with the fact that you can quickly access any part of the storage.

  16. ST

    February 6, 2021 at 7:59 pm

    Hello, I have discovered this amazing site a couple weeks ago, and now its my regular evening reading, following the chronological Table of Contents. Despite having no personal experience in the subject matter (with this article we have not quite yet reached my Birthyear, and I was never a big gamer anyway), but its both very informative and just written in a very nice way, so thanks for that!

    I don’t know if such nitpickery is wished for here, but in this article you write “with track 0 lying at the outer margin of the disk and track 34 closet to the inner ring.”. I suppose you meant closest instead of closet.

    Ach, und schöne Grüße aus Deutschland.

    • Lisa H.

      February 6, 2021 at 9:28 pm

      I don’t know if such nitpickery is wished for here

      Keep reading comment threads, and I think you’ll soon find your answer ;) The wonder is that it seems no matter how big the army of amateur editors grows, there are always more nits to pick…

    • Jimmy Maher

      February 8, 2021 at 9:54 am

      Vielen Dank!

  17. JT

    February 24, 2021 at 7:12 pm

    This is a great article. Most of the time, I also got more out of disabling the copy protection than playing most games. In fact, the only game I encountered that I never could crack was the PC version of Microprose’s original Gunship. This one let you save a working copy to your hard drive, and hid some sort of key-file there. I don’t suppose anyone reading this remembers the ins-and-outs of it.


  18. Jonathan O

    May 2, 2022 at 10:05 pm

    Another late typo: “Many an habitual pirate got so frustrated with not being able properly play this paradigm-shattering game…” has a missing “to” – which can go before or after “properly”, depending how concerned you are about split infinitives.

    • Jimmy Maher

      May 3, 2022 at 1:41 pm


  19. ChristopheF

    July 28, 2022 at 9:24 pm

    The paragraph that starts with “Track 0, sector 7, relies on” describes how fuzzy bits are created in Dungeon Master in a wrong way:
    – 0s and 1s are *not* stored as magnetized/demagnetized areas (on any floppy disk). They are stored as magnetic flux transitions (1s) or their absence (0s) over a short period of time. A flux transition occurs between two magnetized areas of opposite polarities
    – There are no demagnetized areas in the copy protected sector 7 of DM. Although some copy protections did rely on demagnetized areas (or on too long magnetized area with no flux transitions) to produce fuzzy bits, Dungeon Master has its own unique way of creating them, and that’s why it was patented.
    – Fuzzy bits in DM are produced because of the usage of non-standard timings between some magnetic flux transitions in sector 7, and the effect this has on the floppy disk controller when decoding data.
    – Everything in the following sentence is inaccurate and wrong about the actual way the protection works: “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”

    If you want to understand how fuzzy bits are actually created in DM, fasten your seatbelts (as this is quite technical) and read the “Fuzzy bits” section on this page:

  20. Steve Pitts

    August 5, 2022 at 4:29 pm

    When I landed on this page there was a big red warning box at the top of the page, that I assume was generated by WordPress, with the legend “WARNING: unbalanced footnote start tag short code found”.

    • Jimmy Maher

      August 5, 2022 at 4:44 pm

      Now that’s why I call a warning message. “Danger, Will Robinson!” ;)

      Fixed. Thanks!

  21. Ben

    April 28, 2023 at 11:03 pm

    Don Wood’s -> Don Woods’s

    the layout an -> the layout of an

    • Jimmy Maher

      June 3, 2023 at 3:54 pm


  22. Alice Hunter

    July 8, 2023 at 12:37 am

    I know it’s been a long time but do you have the source for the quote at the beginning by Dale A. Hillman. I tried but couldn’t find it anywhere.

    • Jimmy Maher

      July 11, 2023 at 2:26 pm

      It’s from a presentation given by Hillman at the Software Publisher Association’s First Annual Conference on September 13, 1985. I’m afraid the transcript is probably only available at the Strong Museum of Play, as part of the Doug Carlston/Brøderbund archive.


Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.