A little over a year ago, I wrote about some formative experiences I had with computers early in my life. That article focused on the Timex Sinclair 1000, but sitting off in the wings are two other computers - the Commodore 64 and the Apple II. A few weeks ago, there was some dialog between John Gruber, Drew Saur, and Jason Snell that's brought those two machines back to mind. It's all very worth reading if you have any interest in the early history of personal computing.
It's hard for me to admit that it's early history, but these machines are five years further in the past to us today than the ENIAC would've been to somebody opening up a brand new Apple II. Time flies.
Like you might expect, there are partisans for each machine. Drew Saur likes the Commodore and the other two prefer the Apple machines. Having spent some time using and thinking about both, I have my preferences also, but I've also come to a different conclusion. While the Apple and the Commodore competed in a similar place in the early 1980's market, it's equally true that they are products of different times, different design philsophies, and of companies with different goals. For me, it's hard to reduce it to a single "favorite" machine, and it's hard to boil it down to specifications and case design. There's more to the story.
My exposure to the Commodore 64 and Apple II series was entirely in the context of grade school education. My school had two computer labs opposite from each other across the same hall. Turn left and you step into a lab full of Commodores, turn right and you step into the Apple II lab. While the majority of the school's educational use of the computers centered around the Apple products, it was the Commodore 64 that made the first big impression.
I entered third grade in 1983. This was three years after Seymour Papert first published a book entitled Mindstorms). If you're not familar with the book, and have any interest in computer literacy education, I highly suggest you read it. In his book, Papert talks about the Logo) programming language, and how he viewed it as central to a Constructivst) approach to education. The idea is that children could learn by building things, and exploring the properties of what they had built. The Logo language itself was designed to support this. Children could start with a particularly accessible form of graphics programming - turtle grahics - and move on to the sorts of list and symbolic processing normally associated with Lisp. (This is no accident - Papert spent most of his career at MIT.)
For whatever reason, my school was piloting a program to test some of Papert's ideas in the classroom setting. Practically speaking, this meant we had that lab full of Commodore 64's running Logo, and some time each week to teach virtual turtles how to draw shapes on screen. If you haven't seen Logo or turtle graphics before, this shows how you might define a procedure to draw a square:
to square
forward 10
right 90
forward 10
right 90
forward 10
right 90
forward 10
right 90
end
This works by instructing a 'turtle' animated on the screen to move forward 10 pixels, turn right 90 degrees, and repeat the process. The turtle carried a virtual pen that caused it to draw a square on the screen.
By design it was an accessible way to program, even to a third grader. Papert had realized it was easy for children to envision themselves as the turtle, and by imagining themselves as the turtle, they could more easily think through how their instructions to the computer would be understood. That made it easier to make direct connections between what they wanted to happen and the instructions they needed to give the computer. It eliminated the need for cartesian coordinates to put a picture on the screen.
The next step in drawing a square might be to notice that the same pair of steps is repeated 4 times. Logo has a easily understandable looping construct for repetitive operations:
to square
repeat 4 [
forward 10
right 90
]
end
From there, you might decide you want to make squares of differing sizes, and add a parameter:
to square :side
repeat 4 [
forward :side
right 90
]
end
Or maybe even vary the number of sides in what is now a polygon, rather than just a square:
to square :nsides :side
repeat :nsides [
forward :side
right 360 / :nsides
]
end
For me, it was utterly seductive, and very compelling. Adding fuel to the fire was the fact that my mom was one of the other third grade teachers at the school. She was also the teacher responsible for managing the Logo lab. I'd come to her classroom after my school day ended, and if I was lucky, I could spend some time in the Logo lab while waiting to head home. Inservice days were even better. We'd spend hours at school, and I'd often have the chance to spend hours in the Logo lab. There were even a few times I was responsible for setting the lab up - wiring the hardware together.
Initially, I used my extra time in the lab to elaborate on ideas I'd developed in class. Later on, I started exploring the Logo system's manual and a second diskette that shipped with example programs. I was reading Lisp-style AI programs (the Animal guessing game game, mainly) in late grade school. I didn't understand what I was seeing, but the idea that a program could be interactively taught how to guess animals from yes or no questions was heady stuff for a ten year old.
In retrospect, while this time in my life was only a few years, I credit it with my choice of profession. I also belive my early exposure to Logo played a profound role in the way I think about writing software. The C64 Logo implementation had an excellent manual, covering not only how to use the Logo interpreter, but also how to program in general. It talked about subjects like functional decomposition and recursion effectively enough that I was exploring the ideas myself in my spare time in the computer lab. In no time, I was writing functions that would do things like draw n-sided figues on screen. I'd call those with other functions that recursively called themselves to draw even more complex composite shapes. To this day, I am convinced it shaped the way I think about decomposing a problem into component modules. With all that in mind, I hope it goes without saying that I have a fond place in my heart for the Commodore 64.
Unfortunately, if you look a little deeper into what it was like to use a Commodore 64, you can see where it went off the rails in comparison to the Apple. In addition to Logo, my extra time in the lab allowed me to explore other aspects of how the machines worked. I had a couple games and other programs on a floppy disk I'd picked up at a local school computer fair. A later upgrade to the lab brought a row of Commodore 64C's along with GEOS. None of this was used in the curriculum, but I had time to play around and experiment a bit.
While I can say the sprites and sounds were fun, I'd boot the machine into BASIC and be frustrated by the fact that the interpreter didn't have commnands for graphics. An Apple II booted into a BASIC interpreter that had commands for both low and high resolution graphics. Three commands were all it took to switch to graphics mode and plot a colored line on the screen. The same task on a Commodore, required direct access to memory mapped hardware with PEEK and POKE.
Similarly, while I didn't understood why it happened, I noticed that when I wanted to load Logo from disk, it took an awfully long time. While the hardware capabilities for video and audio were nice, there were other aspects of the machine that just weren't right. This strange mix of tradeoffs in comparison to the Apple hardware were related in many ways to the different origin stories of the two machines.
The Apple was hardware Steve Wozniak built as a passion project that Steve Jobs turned into a viable product. The Commodore came a few years later, from a much more mercenary company, albeit a company with its own semiconductor fab. It says it all that Wozniak picked the 6502 chip because he could afford it, and Commodore picked the 6502 because they owned the fab that made it. That manufacturing capability (and some talented engineering) gave Commodore the ability to do things like design the custom semiconductors for video and audio that gave the Commodore so much of its power.
The flip side of the C64 story is that it was also built to a price point. Commodore had bought that semiconductor fab as a way to stay competitive in the calculator market and moved into computers as a way to hedge against the fact that market was shrinking. While Wozniak was able to develop much of the Apple II hardware in isolation, the Commodore 64 was very much a product of a wider corporate engineering effort. They could do things like build their own chips, but they didn't have the focus of Wozniak's stated goal of building a computer that could implement Breakout in BASIC. (Apple's later failures with the Apple /// and Lisa should show that Commodore is not the only company of the era with the ability to lose its focus.)
The net effect of this is that while the Commodore had some nice hardware, it also suffered due to cost cutting. The lack of investment into a BASIC interpreter that supported the hardware is one such example, but the situation was even worse with respect to Commodore 64 Disk I/O. If you're not familar with how disks worked on a Commodore 64, they were the diametric opposite in design when compared to the Apple Disk II. Steve Wozniak famously designed the Apple disk controller using the machine's host CPU and a handful of chips on an expansion board about the size of a deck of cards.
In contrast, Commodore 64 disk drives were standalone computers with their own CPUs. There was the disk hardware, but there was also another 6502 chip, RAM, and ROM firmware. In a sense, a Commodore 64 was what we might view today as a network server. It ran most of the disk operating system itself and served files to the host Commodore 64 via a serial link. This added costs to the disk hardware, but carried a few advantages. First, it was simpler to package and install than the Apple II's plug in expansion card. (Atari did something similar with its 8-bit disk drives for what I presume are similar reasons.) The other advantage was that this networked approach made it possible to multiplex a single Commodore 64 disk drive (and printer) across several Commodore 64's. My school's Logo lab did this to share disk and printer pairs across groups of four C64's. They had to buy multiplexing hardware to do this, but I suspect the cost per seat was much lower than it would have been with the either the more expensive Apple hardware or a dedicated Commodore disk drive per machine.
Besides higher drive cost, the other downside of this approach to disk storage was that it relied on the performance of a serial communications link between the Commodore 64 and the disk drive. For a range of reasons related to hardware compatibility with the earlier VIC-20, the higher memory bandwidth requirements of Commodore 64 graphics, and a rush to market, the performance of this serial link was severely compromised on the Commodore 64. Not only was Commodore 64 disk I/O slower than on a VIC-20 with the same disk drive, it was less than 10% the speed of an Apple II disk. Benchmarks put the transfer rate of the disk drive (with the stock link protocol) at significantly less than 1K/sec. Loading that Logo interpreter could take a minute or more, which was made even worse by the way the lab shared a single disk across four C64's. While it was possible to fix the serial link performance issues with a fast load cartridge, that consumed the closest thing the Commodore had to an expansion port solely to correct an issue that should not have shipped in the first place. I argue that this sort of failure (and a general lack of expandability) have a lot to do with the limited shelf life of a Commodore 64.
So, while the video and audio capabilities of the Apple II weren't in the same league as the Commodore, it had some strong compensation in the form of performant disk I/O and expandable hardware. My middle school library used an Apple II with a Corvus hard disk to maintain its book inventory. A few years later (early 1990's), my high school physics teachers had built a fully integrated test generation and grading system around a heavily upgraded Apple //e. They would generate custom tests (with graphics) for each student and grade them in real time as students were taking the test. If we missed a problem while taking the exam, we could try again during the same class period for half credit and again after that for quarter credit. I suppose it would have been possible to do these sorts of things with a Commodore, but there were more gaps in the machine's capabilities that would need to be filled and fewer ways to expand the machine to fill those gaps.
Technical issues aside, what I'd like to leave you with is the notion of coherence of vision. Wozinak designed the Apple II in the context of a company that was already selling hardware (the Apple 1), but he did it with a very clear and personal vision of what the machine should be. In part, he envisioned the Apple II as a machine that could take the Atari Breakout game and re-implement it in software. This vision guided the features he built into the machine and turned it into a product with a purpose. He knew what he was designing, who he was designing it for, and when it was complete. He also had the humility and foresight to recognize that the Apple II itself was the beginning of the story and would need to be expanded and potentially carried forward into subsequent models. While I don't think we should disminish the role of Steve Jobs' marketing vision, I do think there's a lot to be said for starting a design with specific requirements and a specific audience. This may not be as sexy or as fun as hardware specifications, but it is a better core vision for a product with staying power. That's a lesson as true now as it was then.