Next Monday, December 10th, I will be at the Computer History museum to hear a panel discussing the 25th anniversary of the C64. It includes Jack Tramiel, founder and CEO of Commodore, Adam Chowaniec (manager of the Amiga), and some other guy.
There’s a lot that’s been written about retrocomputing, most recently this CNN article. I myself started with a VIC-20 and a 300 baud modem around 1983. I still have a few pages of old homework where I wrote an assembly joystick decoding routine in the margin. I later got a C64c in 1986. My Commodore era ended when I upgrade to a 486DX-33 in 1991. The 486 was my desktop for years, running DOS, Linux, and finally FreeBSD. It then served up root.org until I replaced it in 1999.
The most fascinating things about the C64 were games, demos, and copy protection. Games and demos made me ask “how do they do that?” It was easy to run a disassembler and see surprising techniques like self-modifying code and tricky raster interrupt timing. Copy protection was also a big eye-opener since it seemed to violate the principle that if bits can be read, they can also be written. (Of course, this principle is still generally true, but the skill of the protection author can greatly affect the difficulty.)
I don’t like to admit defeat, and there were some copy protection schemes I was never able to figure out. Now with the power of emulators and ways to physically connect a floppy drive to my PC, I can dust off those old disks and figure out how they worked. Most crackers didn’t need to understand the media layout or protection scheme in detail since they could often “freeze” and capture the game code from memory and then piece together a loader for it. In the race to get the first release of the latest game out, a lot of interesting details about how the protection worked would be overlooked. I think the protection code is as interesting as the game.
There is something refreshing about using a computer where every signal is 5 volts, instructions are a single byte, the clock is 1 microsecond, and ROM gives you reset times of a couple seconds. You just can’t make a mistake and lose all the time spent reinstalling software as you can with today’s hard drive-based systems. Hopefully, the advent of virtualization and good network backup software is going to return us to some of that carefree attitude.
As a hobby, I continue to help with the C64 Preservation Project. My next planned project is creating a USB interface to the parallel cable so that I can use nibtools with my computers that no longer have a printer port. Also, I find that loading an image of a protected floppy into an emulator on my laptop and disassembling it makes for a nice travel diversion during the holidays.
I hope you will enjoy the holidays in your own way and have a great 2008!
[Edit: the official video of the event has now been posted here and here]
rdist 
The Apple II had a similar history in the copy protection space. Apple II disks were self-booting, and it was long thought that the boot sector was a weak point in the protection. However, since the ROM disk I/O routine had to fit into 256 bytes, it could not follow the disk specification completely, so some checks were missing. That allowed the creation of games with custom disk formats that also protected the boot sector. Choplifter and Operation Apocalypse, both from Broderbund, are good examples. The guys at Broderbund used many interesting copy protection mechanisms, including quarter-tracks, spiral tracking, and more.
Great info, Peter. After hearing all the accounts how Woz’s Apple II disk controller design was so awesome, I looked up the schematic. It has no CPU but instead uses a ROM as a state machine with some 74xx logic to step through the states and control the drive head. All the decoding routines, soft sector framing, etc. are done by the host computer in software. The host does autoload a boot sector on reset.
The 1541 floppy has its own 6502 CPU and ROM/RAM so it is a full featured computer, implements high level access (database-like), and can run custom routines without the host being able to peek at its memory. For instance, an obfuscated loader can be dumped into RAM and replace interrupt hooks and then decrypt and load additional chunks that are hidden with physical media tricks. The host has no idea what was loaded after the boot sector and can’t get access to the drive without reseting it. This forced copier companies to sell drive hardware (the first modchips!) that added 8K of RAM or direct access to the board via a cable.
Because it came out earlier (1977 vs. 1982), the Apple II tended to be the leader in disk protection for quite a while. Then they diverged a bit as developers became more familiar with the 1541.
The event was quite interesting. I sat near the front next to the CNET reporter writing this article. The part I found most fascinating was the spin Steve Wozniak and Jack Tramiel both gave their company history.
Yes, the Apple II had expansion slots and the C64 didn’t, but there was nothing closed about the standards for the user/cartridge ports as Woz implied. There was even a separate Z80 CPU cartridge for the C64 to run CP/M. Yes, the Apple II was more expensive for less performance, but it was popular with ordinary people and user groups, not just the “classes” as Jack insinuated.
From my perspective, the Apple II did start slow out of the gate. It wasn’t an instant hit. However, it began taking off versus the cheaper PET when Commodore delayed getting a cheap floppy out while Apple did. The Atari also came out before the C64 and was better in graphics/sound than the Apple II. The TRS/80 hit the market slightly before the PET and Apple II and was the earliest leader. But the C64 was a big breakthrough in memory, graphics, and sound at a low price and key point in history. Even Woz will grudgingly admit it far outsold the Apple II.
So far, Apple’s revisionist history has been the predominate view but hopefully the facts will speak for themselves. It will be interesting to see the video once it’s posted.
@ Nate:
“Yes, the Apple II had expansion slots and the C64 didn’t, but there was nothing closed about the standards for the user/cartridge ports as Woz implied.”
I’m pretty certain Woz was talking about the PET, not the C64, with respect to those comments. The PET was rather closed compared to the Apple II.
I definitely agree on the PET 2001 not having a lot of expandability with internal slots. In some sense, it was kind of like the original Mac. :)
Since the event was about the C64 anniversary, I assumed all the speakers’ comments were about the C64 and the then current Apple II models (+ and e). But it makes sense they were talking about their entire product lines of the 70’s and early 80’s.