This interview was conducted by Nate Lawson and included questions submitted by Pete Rittwage and Wolfgang Moser.

General

Q: Where have you lived, general age, interests, university/degree, and any other info you'd like to share?

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 schemes?

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?

A: Oddly 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 Commodore.

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, and others.

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 such advance.

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 duplication.

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 two.

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.

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 thing.

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 detection.

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 them.

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 competitors?

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.

Supercard-Plus

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.

The Shadow

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 stories?

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 competition really.

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. :)

Later schemes

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?

A: Everything was easy to duplicate (exact copy), so manufacturers switched to manual based protection schemes and then eventually CD based.

Today

Q: What do you think of mnib? What features should we add to it?

A: I have no idea what it is. (Ed: we later sent him a link to it.)

Q: Do you use an emulator or CBM hardware any more? If so, for what?

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 solved.

Miscellaneous

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 software.

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 chain.

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!