Jim Drew was an early figure in the history of hardware designed to
circumvent copy protection. He is currently CEO of Microcode Solutions,
an electronics design firm. We asked him some questions via email about
his history with C64 copy protection.
This interview was conducted by Nate
Lawson and included questions submitted by Pete Rittwage and
Q: Where have you lived, general age,
interests, university/degree, and any other info you'd like to
A: I was born and raised in Oregon, moved to Arizona
15 years ago. Attended school in Klamath Falls, Oregon. EE/CE/CS.
Q: What about Honolulu/Hawai in 1984 as with the article in Amiga
Update? Was this a springbreak trip only, after finishing school?
A: I moved to Hawaii after graduating from high school with the
idea of living there. I had family there, so I tried it out. Hawaii
is nice to visit, but not nice to live there year round.
Q: How did you get into computers and electronics? What computers
or hardware/electronics did you use and learn before you began
working with Commodore computers?
A: I got into electronics
courtesy of radio shack experimenter kits when I was about 8 years
old. My dad brought home a beta Commodore PET 2001, so I started
with Commodore products in 1976.
Q: Wow. When you say "beta", does this mean that your
dad worked for Commodore?
A: Actually, my Dad was involved
with a lot of interesting "things". He was a museum
directo/currator and got Commodore to send a sample to be used for
inventory for the 1 million+ items... lol! 8K of RAM and a cassette
tape storage device.
Q: What software/hardware did you create (free or commercial)
before you focused on copy protection?
A: I wrote numerous
games (asteroid, space invaders, etc.) for the PET series, and a
sprite making program for the VIC20. I got into disk copying when
the 1540 was released, which is really when copy protection started
with the Commodore stuff.
Q: I don't know of any copy protection from the 1540 era. Can
you give more examples of this earliest protection? Was this for
the VIC-20? Or were the first Commodore protections for the 64?
A: The VIC-20 had oodles of cassette tape protection. Commodore
stored the data twice (each byte twice) for redundancy. Some of
the early tape protections had their own loaders that used all of
the data space, which gave them this incredible ability to load
twice as fast as normal programs! LOL!
I don't remember all of the early disk protections for the 1540,
but the CBM8080 disk drives had a common protection used with the
PETs to have a paper punched hole in the media in the upper tracks.
CBM Protection Methods
Q: How did you get started analyzing protection methods?
A: By cracking the software!
Q: Who do you think were the innovators in designing protection
A: There were a lot of people doing it. Kevin
Pickell stands out the most.
Q: I wasn't familiar with him.
I found this info at MobyGames.com. I was hoping maybe he was linked
to Rapidlok, since he did some Accolade titles. However, all the
games Kevin were involved in were the ones *not* Rapidlok protected.
Which protections did he invent and what company did he work for?
A: Kevin Pickell worked on the Test Drive series as a programmer
and did the copy protection for it and some of the EA games.
Q: Did you communicate with them at all? Who were the friends
you talked with about protection methods, drive hardware, needs and
wishes for a "perfect" disk backup tool?
enough, Mike J. Henry (Fast Hack'em fame) lived in Portland, Oregon
(where I lived) and came to my office (Commodore headquarters for
educational support) on several occasions and we use to crack
software. There were really only a handful of people that could
crack everything, so chatting with a little limited. :)
Q: Ah, so you were close competitors in more ways than one. :)
To someone a little unfamiliar with your products, what was the
unique selling point regarding the technical features of your
protection busters, if we don't count the hardware based copiers?
A: More bells and whistles - lots of user controls.
Q: What was your involvement with Central Point or possibly data
rescue companies like Ontrack?
A: I wrote the 2nd generation
of Copy ][ 64/128. The first version had code "borrowed"
from Mike J. Henry and Mike got a settlement, and I got the job of
writing the new version.
Q: Interesting. Who wrote that first version of Copy ][? No
one I know even saw a pirated copy of Copy ][, version 1. The lowest
version I've seen for the C64 is 3.0. Are you
talking about the Apple version?
A: Dave (something-n-rather)
wrote the first version. I can't recall his last name. He was older
— in his 40's at the time. v3.0 with the blue screen and white
text is the version that I wrote. I think Dave's version was v2.0.
Q: What did you learn from your competitors? Where do you think
your competitors were better than you and how did you catch up to
their performance and/or knowledge?
A: Mike was probably the
best at writing transfer routines (high speed), although the code
that we came up with at Central Point software written by myself
and Mike Brown (owner of Central Point Software) was nearly 20%
faster. I really didn't understand the serial port too well, and
my attempts at fast loaders were not up to par with others.
My expertise was with the GCR data read/write and decoding, especially
with varying density rates.
Q: How do you think CBM DOS knowledge was obtained by people
like Richard Immers (Datamost) and other hobbyists?
A: From Commodore directly. All developers could get the information,
including an assembly listing of the 1541 drive code. This made
it quite easy to understand how the job queue and such worked.
Q: Was this during the Commodore dealer/downtown Portland time?
What else were the connections to Commodore, via your father?
A: I chatted with Commodore directly while I was in Portland.
I was the education support rep for the State of Oregon for
Q: Besides in-house development, how did authors of protection
methods sell their approach to multiple vendors? For instance,
RapidLok was used by Accolade, Mindscape, Avantage, Avalon Hill,
A: No clue. I didn't deal with any of that.
Q: In your mind, what is the timeline of major advances in
Commodore (and other) floppy-based protections? For example,
Access's move from simple error checking (Beach Head, 1983) to
non-CBM track patterns (Raid Over Moscow, 1984) is my idea of one
A: I don't recall the time line, but when
everyone moved from standard error checking that caused the head
to rattle, to job queue events (which don't), that marked an era
of complexity for determining the protection scheme. It was natural
progression to see the same types of disk protection being used on
the Apple ][+ software being used on the C64 software. The Apple
][+ was quite aways ahead of C64 in terms of disk protection and
Q: Does this mean that protection schemes as well as copier
methods could be derived from the Apple ][+ and ported over to the
C64/1541? Does this mean that such coding techniques were actually
used on at least some methods (protection and/or busting them)?
I'm interested in hearing more about the relationship between the
The facts I know are:
- Encoding was GCR
- There was no problem with a shift register and '000' bits.
- The sync circuit was not hardware, it was software. (Ed. The Apple hardware actually syncs to every '1' bit, so all data is stored with the MSB set. It uses 0011111111 as the sync signal)
- The stepper motor could move to 1/4 tracks.
Interesting side note: 6502 designer Chuck Peddle said in an interview
(quoted in the book
"On The Edge
that he had patented GCR. I wonder if Apple licensed that from Commodore?
A: The Apple disk
protection and C64 disk protections were nearly identical to many
cases. Only with the advent of things like RapidLock did protection
really take a turn with the C64 stuff. Apple's GCR was 3/4 and the
CBM GCR was 4/5. You could get more data with the CBM GCR encoding
that Apple's, but the penality was that you cold not do realtime
decoding like you could with the Apple GCR. The 6502 was invented
by MOS technologies, which Commodore bought. I doubt there was a
problem. (Ed: I guess Jim's point is that Apple's GCR was different
enough from Commodore's to not require a license.)
Q: What kind of equipment did you develop for analyzing protection?
What did you keep private versus selling to users?
A: I had a 8K RAM that was mapped to the zero page and with a flip of the
switch, it was remapped to high memory. This allowed me to simply
load a program, flip the switch, reset the computer and drive, and
then go look at the drive's ram contents. Disassembling this code
made it very easy to determine how the protection scheme worked.
I kept this to myself, although I am sure others had the same
Q: Nice idea. Did this ever make it into a product of yours,
even if it had to be jumpered or something?
A: Nope. This was mine.
Q: What was your typical work environment for testing and using
your own products? Which computers did you use for this, peripherals,
cartridges, OS extensions, floppy speeders, freezers, etc.? Did
you analyze data directly from the 1541 head (i.e. with an oscilloscope
or other analog tools)?
A: I used a C64 initially, and then
I managed to get Dave Haynie's personal C128 (which I still have
with the sticker "Property of Commodore Business Machines"
on the bottom of it.) :) I used a few cartridges, but for the
most part all of my work with in the disk drive... which had the
extra ram, digital track display w/density indicator, drive select
switch, reset, etc. I used an oscilloscope once. My partner, Steve
Berns, and I made a dual drive duplication system that was never
released. Now I wish I would have released it. At the time, I
didn't know enough about how tracks were laid out and such, and I
kick myself now for not making it after I learned! The device was
a write circuit. The read head signal was sent via a two wire cable
to a write circuit in the other drive. Whatever the first drive
read, the second drive wrote. The data had to be inverted, and I
had to look at this data with a scope. It was really cool. Just
by loading a program, it would write that program to the other disk.
The problem was that when the head was stepped or the write was
turned off at some arbitrary time, the data written was corrupted.
If I had made a simple program to wait for the track gap before
turning off the write, we could have duplicated EVERYTHING several
years before the Epyx long track stuff was ever released. The
reason behind not releasing this device was that it required two
disk drives and NOBODY could afford two disk drives, so the market
was really small... of course several years later, things changed
and we already SuperCard+ and needed to support it. Besides, this
device was SIMPLE... 3 transistors and a few resistors... it would
have been more common than the 21 second backup cable! LOL!
Q: Very nice!
A: Incidentally, Dave Haynie are actually
in the same market sort of competing against each other. We chatted
a few times recently. He works for Nomadio, a company that develops
R/C radio systems. I also own a company that develops R/C radio
systems (Xtreme Power Systems).
Q: Can you explain more how this was possible? How did you
handle synchronization, for example? What about RPM differences
and jitter? Also, how could you reliably detect the tail gap? For
instance, I thought bad GCR might fool pattern-based tail gap
A: We never released the product. It didn't work
as it was because it needed some type of method for determining the
track gap. This was LONG before I even knew what a track gap was!
LOL! RPM differences really would not matter. Considering that
manufacturers had to load their software on drives that are clearly
out of alignment from day one, they could not resort to things like
RPM variations for protection. I think too much concern is placed
on bad GCR. There are ways to truely find the write splice(s)
reliably and locate the track gap. The way that I ended up doing
it was by reading the track at varying densities and doing a compare
on the shifting pattern.
Q: I have some related questions about your other partners.
Maybe you could give some quick thoughts on the following people:
- Reggie Warren, Megasoft (1987 news message in comp.sys.amiga)
A: Reggie Warren was the sole owner of Megasoft.
Kind of a snake really. Took a lot of money on promises of product
not even in beta tested yet.
- Jack Cornelius (1992 news message by you in comp.sys.amiga.emulations
and 2001 news post from Stingray in comp.sys.cbm)
A: Ah..Jack, this is the Shadow creator.
- Jack Radigan, designer of The Shadow
(1997 news message by you in comp.sys.amiga.emulations)
A: No clue who Jack Radigan was, but he was not associated
with the Shadow.
Q: Can you tell me more about them? Were any of these people
related to other hardware/electronics manufacturing companies?
A: I knew nothing about Jack and met him only once. Reggie
contracted me for many products, including fixing the Shadow.
Q: What was your typical approach to keeping up with new protection
methods or variants? Did you buy games to analyze them? How did
you streamline the process of figuring them out?
A: The local
software rental store gave us everything that came in and we made
backup copies for them. It was just a matter of trying out our
copier and if it didn't work, then dump the ram and figure out what
the protection scheme was. It was pretty rare that I even needed
to look at the disk data (GCR) to figure out what was going on.
Q: What were the most difficult protections you analyzed?
A: Rapidlock, and 1/2 tracks (Bounty Bob Strikes Back).
Q: Are there any other halftrack protected title from the company
that produced Bounty Bob? Other companies?
A: Other than a
few of the programs that deliberately stepped into the 1/2 tracks
to freak you out, I found nothing else that actually relied on
Q: It doesn't seem to copy Bounty Bob for me. A friend tried
it with a 1541, but hasn't tried it with a 1571 yet. The copy
procedure completes, but the copy doesn't load. It also doesn't
copy DiskMaker Plus, but he was able to copy this with MNIB on a
1571 with a 60000 us track skew manually specified. Ideas?
A: Maybe RPM? I know that Bounty Bob (original) would not load
on 1/2 of my drives. It is really touchy (like RapidLock). I don't
remember anything special about DiskMaker Plus.
Q: What were the strangest (not necessarily difficult) schemes?
A: I don't recall any "strange" stuff.
Q: Did you ever construct your own protection method? If so, who
used it? What was it called and how did it work? Was it broken?
A: We protected our first copy programs with things like using
track 36/37. Those were easy to duplicate later on, but provided a
little bit of time.
Q: Did any software publisher ever contact or threaten you about
writing copiers to duplicate their software? Did you ever create
protection for commercial software?
A: YES! Trip Hawkins
from Electronic Arts stated publicly stated that the world would
be better off without people like Jim Drew and Mike J. Henry! I
never made any protection for commercial software. That would not
work well since we could duplicate everything with SuperCard+.
Q: What do you think of Burst Nibbler and other SuperCard
A: They worked well for what they were designed for.
Q: Did you keep in touch with cracking groups? How did their
approach parallel or differ from yours?
A: I did not associate with any cracking groups.
Q: Were there any protections that cannot be duplicated with a
1541 sufficently to boot and run? For example, bad GCR or (0x00
bytes) require special attention to detect and duplicate their
behavior. Using extra RAM or a parallel cable, is there any
protection you found that can't be duplicated?
A: No, I found nothing that we could not duplicate.
Q: Regarding the Supercard-Plus board, there are some people
mentioned at the end of the ROM as well as in a hidden area of it
(not decoded to 1541 address space):
THIS CODE IS COPYRIGHT
(C) 1988, 1989 BY JIM DREW. UNAUTHORIZED USE OF THIS CODE WILL BE
CONSIDERED A VIOLATION OF COPYRIGHT. ALL ROUTINES ARE DESIGNED TO
WORK WITH THE SUPER-CARD+ HARDWARE. 'SUPER-CARD+' IS A REGISTERED
TRADEMARK. PATENT FOR SUPER-CARD + IS STILL PENDING. THIS SOFTWARE
IS DEDICATED TO MY GOOD FRIENDS ON Q-LINK: WES, RAB, PECKSTER,
SIRROM, SLATES, WRL, HACKER, CROM, MAC, & NAUGHTYGRL! ;) THANKS
GUYS! JIM DREW
Who were these people? Were they partners to
your company or just friends? Any stories about them?
A: There people were on Q-link. Just people I got to know and chatted
online with. Q-Link was the first online chat for the C64.
Q: Regarding the history of The Shadow board: who developed it?
Who came up with the feature list, who designed the hardware, who
made the firmware, who was contracted to write the software for it?
What were the main reasons why this device did not work or was not
successful in the market?
A: A guy named "Jack"
developed it. I don't recall his last name. It was his product
completely. I had no involvement with it until I turned it into
an expensive ram board. :) This device COULD have worked had this
guy been a software engineer. He was a hardware guru, and when
that thing worked, it worked perfectly! The problem was it only
worked on a few disk drives! The Shadow was a data read/write
mechanism. It stored the bit time sequence of data. This means it
read the magnetic flux and recorded the amount of time between high
and low magnetic flux transitions. The write sequence duplicated
the read sequence. I don't think there was enough ram on the board.
It needed something like 18K of ram to hold an entire track, and
Jack was trying to piece together a track, which ended up causing
write splices that corrupted data. The timing was critical, and
not all 1541 disk drives had accurate clocks, which is where the
compatibility issues came in. After taking about $30,000 from
Megasoft, Jack skipped town and was later found, arrested, and sent
to jail for this.
Q: I've heard that some engineer(s) were hired to design the
hardware based on your ideas and you would write the software for
it. Supposedly they also wrote parts of the firmware with low-level
access routines to the hardware. Maybe this is redundant with the
question I asked above but who else was involved here? Any
A: The Shadow was developed outside of me. I didn't
even know about it. I was not working with Megasoft at the time.
I had Final Source Software then. Nobody ever consulted me on
ideas, and I would not have provided them anyways as I was in
Q: I'm also wondering if Supercard+'s ROM was derived from The
Shadow. I was told that even The Shadow got the fast GCR decoding
routines from RapidDOS-Pro. It's interesting to see the co-evolution
of the different hardware boards.
A: The SuperCard's ROM was
my own. It consisted of all of the utility routines that I always
loaded up in high memory of my special RAM. I just made them
available at $2000 instead of RAM based. The Shadow had NO GCR
decoding routines. It didn't decode anything. The Shadow
was very clever in that it simply
copied the time for each transition of data (high to low and low
to high). It was a true bit copier. The problem was really that
it needed WAY more RAM to do it.
Q: What made The Shadow different from other boards? How was
it supposedly able to beat all existing protections from only
watching how a protected title accesses the disk?
A: By duplicating the disk truly at the bit level.
Q: Very interesting. Maybe this is the reason my The Shadow
failed to copy unprotected disks? There are a lot of bad GCR areas
in the normal and track tail GAPs resulting from changing the R/W
heads mode from read to write or vice versa.
A: The Shadow was a fiasco. :)
Q: How did the Amiga and PC floppy protections evolve and improve
from the C64 and Apple II schemes?
A: They were completely
different. MFM is radically different from GCR, so all of the
tricks were different.
Q: What other interesting CBM, Amiga, or PC floppy techniques
(i.e. fast loaders) do you think are noteworthy?
was easy to duplicate (exact copy), so manufacturers switched to
manual based protection schemes and then eventually CD based.
Q: What do you think of mnib? What features should we add to
A: I have no idea what it is. (Ed: we later sent him a
Q: Do you use an emulator or CBM hardware any more? If so, for
A: I use a LOT of emulators! C64, PET, Amiga, PC,
Mac, etc.. etc. Some work and some play.
Q: What do you do nowadays? What about the years after 1996
(last interview re: Amiga) to now?
A: I design electronics
for military applications, paintball, radio control industry, etc.
Basically, if someone has a problem they come to me to get it
Q: Here's an old article from PC Week, 1985. Trigger any more fun memories?
The 2nd Annual Awards (1985)
Special Award: Mike Brown
Mike Brown has a consistent vision: users should get
the full value of the software they pay for. Unfortunately, as most
readers know, Brown's vision runs counter to the sincerely, but
mistakenly, proclaimed interests of the many software publishers
who use copy protection as a bludgeon to protect market share. While
Brown has been threatened with everything but physical violence as
a result of his stand, it has yet to be shown that any company has
actually been hurt by copying.
Mike Brown has not only held
his own in the fierce battle of technologies that ensued, but
actually gained ground as a number of major software publishers saw
the light and dropped copy protection. His company, Central Point
Software, produces a line of disk-copying software and hardware
that permits proper backup and the unlocking of applications programs.
Brown's program, Copy2PC (see "Working Around Copy Protection,"
PC News, Volume 5 Number 10, page 47), facilitates the copying of
protected programs or their easy transferal to a hard disk —
both legitimate needs of most business users of applications
In Atlanta, PC Magazine saluted Mike Brown with a special award
for serving a user-aware conscience for our industry. We agree fully
with his position that satisfied customers don't betray software
publishers. Indeed, as senior editor Bill Howard has commented,
"Locks tend to keep only the honest people out." And we
acknowledge his technical achievement: devising and publishing
updates to diskette copying software as frequently as required,
which, up until very recently, has been every few weeks.
A: Mike Brown was ahead of his time, that is for sure. He wrote
the original Copy ][+ so I had a lot of respect for him. He was a
CEO and a programmer (much like I am now).
Q: You mentioned some retail software rental chain that you made
backup copies for. Was the company Final Source Software? In the
AU article, you mentioned that FSS changed into such a retail
A: Yep, that is what happened.
Q: Supposedly MegaSoft as well as Utilities Unlimited were sued
several times. Any idea what for?
A: Mike Henry actually
sued Megasoft and me for copyright infringement. We went to court
and I showed the court where Mike and I had both gotten many routines
from and just modifed them to suit our needs (the 1541 ROMs). The
difference was that we had permission to do that and Mike didn't.
The case was thrown out. That was the only suit I was aware of.
I became part of of Utilities Unlimited and that evolved into Amiga
software and hardware, where I developed the world's first color
Macintosh emulation as well as the first Pentium emulation. Sadly,
with the death of Commodore came the death of many great companies
and UU, Inc. closed its door on August 26th, 1996.
Jim, thanks for your time!