I was just a little kid then, and the C64 was a neat micro, but today I can see some questionable things about their comparison matrix in the ad.
Obviously, they are comparing to only the high-end competitors (e.g., Atari 800 but not the 400, and no TI 99/4A which also used their own chips like Commodore touted as a selling point, nor the TRS-80 Color Computer that was intended for home use unlike the Model III business computer). Buyers who knew the real set of alternatives, at and below the C64's price point, might question why they need 64KB RAM, when the popular lower-priced competitors not shown in the table also did fine games and Basic programming (the main uses of home computers) while costing less money.
Then there's structuring "TV Output" as a feature of the C64, which they say the TRS-80 Model III doesn't have. But that's because the TRS-80 has an integrated display monitor, while the C64 includes no display in that price comparison.
I don't know what "'Smart' Peripherals" are. But that IBM PC defined industry standard peripheral interfaces for years.
The competitors also had obvious strengths not shown. Want your word processor to be in crisp 80-column text? A real spreadsheet program? Math coprocessor? Better graphics? Option to upgrade to a hard disk drive?
There was a specific reason with the TI: Tramiel was still smarting over how they screwed him with calculator chips. Meanwhile, their home computer unit was suffering millions of dollars in losses due to greedy mismanagement and the VIC-20 was driving the 99/4A into the ground as a practical loss leader. As far as Tramiel was concerned, even acknowledging the 99/4A's existence was too good for them.
Yep, and in 1986 I had just interned at a NASA lab where they were investigating multiprocessors, which at the time was a wild and crazy idea. I had the epiphany that I could bit-bang a driver between a C64 and one or more 1541s and make my own little multiprocessor, so I did. I made it all the way to the International Science Fair and ended up getting a college scholarship. I've written a lot of code but I'm probably the proudest of that couple of hundred lines of 6502 assembly I wrote when I was 17.
I mean breakthroughs like ChatGPT, etc. that were not possible back then computationally w.r.t. mass adoption and upending real industries. Are we entering a new age of ubiquitous AI computing?
The disk drive uses a serial protocol and it actually has 8k of RAM and a 6502 CPU.
There's no drive controller in the C64, you send serial commands to the drive and it answers.
Due to a hardware bug on the CIA on the 64, the protocol is much slower than it should, which was corrected in later computers, but they messed up with the graphics and a bunch of stuff.
One of Woz's major accomplishments with the Apple II was driving a floppy drive entirely in software from the host computer's CPU, which made the floppy drive and its controller much cheaper.
... and much faster. Like *30 times* faster. Even had the hardware bug juancn and classichasclass discuss not existed with the C64, the Disk II is still much faster.
It's flabbergasting how good Woz's designs were. Almost on a whim, he with the Disk II did something no one anywhere in Silicon Valley—anywhere in the world—was doing. Forget about IBM, HP, Shugart, Tandon. Just within Commodore and Tandy, Apple's direct 1977 competitors, there were abundant human and engineering resources to come up with a fast, inexpensive, and reliable floppy drive and controller; Chuck Peddle at Commodore was certainly no average engineer. And yet, Commodore was still unable to do this in 1984.
Whether one believes in the reality of the existence of the "10X developer", it's hard not to see what Woz did between 1976 and 1978—Integer BASIC, Apple II color graphics, and Disk II—as proof that such a being can exist, even if (as I have written elsewhere) that brilliance straddled the line between optimized and overoptimized. <https://news.ycombinator.com/item?id=41685888>
With just a little attention to sector interleave, in fact, the Apple Disk II was capable of streaming from the floppy into memory at the full rotation speed of the disk. It wasn't actually possible to be faster at all, without a hardware modification to the drive motor.
And it was all done with a "controller" card build out of like eight chips you could get at Radio Shack. The Disk II really is probably the cleverest single piece of hardware shipped in the microcomputer era.
Need to give credit to the Apple's cassette port interface, too, which not only ran as fast as the 1541 disk drive, but could be pressed into service as a rudimentary half-duplex 1200bps modem with the addition of a few inexpensive off-the-shelf parts to interface with the phone line.
I've always been surprised that nobody else seems to have experimented with that. 1200 bps modems were nothing to be sneezed at in 1980.
I am not dismissing Wozniak's designs here, but it is important to not a couple of major differences between the Disk II and it's competitors:
- Many of the design constraints that other companies faced were removed. Apple designed their own drive electronics and drive interface card. Yes, it takes a talented engineer to handle both the analog and digital side of things. On the other hand, there were compromises. The Apple II was stuck doing a lot of the heavy work. Apple also ended up designing a more complex drive controller to go beyond single sided, double density drives.
- On the flip side, Commodore had more design constraints than most. The 1541 was based upon drives from the PET era. The drives also interfaced to the computer in a fundamentally different way. On the surface level, Commodore drives interfaced to the computer over a generic bus (a bit like USB is a generic bus). The drives also handled high level commands over that bus, to the point where they could operate autonomously. I recall a colleague demoing a drive-to-drive copy between two 1541 drives that occurred without the drives being connected to a computer (after the initial setup was done). The commands were also very high level, dealing with file system access rather than block level access.
While it would be easy to claim that Commodore drives were over-engineered, one must also consider that the original designs came from a time when personal computers had 4 kB of RAM, with nearly 1 kB of that being used by a 40x25 text display (many early computers shared memory between the CPU and video). Software like a disk operating system also required at least some RAM and, in the case of the Apple II, was entirely loaded into RAM. In other words, Commodore was offloading some of the work and memory requirements from the computer.
Wozniak was a genius at designing simple hardware, but those designs usually pushed things into hardware. The Disk II is one example. The other classic example is the non-linear addressing of video on the Apple II. It simplified hardware, but more work had to be done in software.
As for Commodore, well, they were geniuses at botching sophisticated hardware designs. But that's another story.
> I recall a colleague demoing a drive-to-drive copy between two 1541 drives
This is simply because the 1541 was not just a drive, it was a full computer with a 6502 CPU, 2kB RAM and 16kB ROM. You could load software into the RAM through the serial interface, and replace the firmware with any program that you could fit in the 2kB.
>Due to a hardware bug on the CIA on the 64, the protocol is much slower than it should
If that were true then carts like Fastload wouldn't work using the same hardware and same cabling, to load programs many times faster than the stock C64 code.
The C64 ROM code worked, but slowly. This was also true for the built-in serial routines. When I got a 2400bps modem for my C64, the computer couldn't keep up, there was garbage coming through,I couldn't upload or download, and it was caused by the slow ROM serial code. I hacked my favorite terminal program with my own assembly language bit-banged serial driver, and then the 2400bps modem worked flawlessly. The same is true for the slow disk drive serial code. To my knowledge, that wasn't caused by any flaw in the hardware, it was just slow driver code.
Everyone I knew had a Fastload cartridge, but I was in "the scene", so maybe not the average user back then.
Did fastload speed up the protocol, or did it compress the data? I remember using other software for speeding up reading and writing from cassettes, but if I remember correctly this was achieved using compression.
Actually, the hardware bug was in the VIC-20's 6522 VIA; the CIA 6526 shift register fixes the bug. The (chief) problem on the 64 was the VIC-II stealing processor cycles.
The CIA 6526 shift register on the C64 is not used. Because the trace on the pcb that connected to it was accidentally cut by the board partner, and Tramiel was unwilling to take the time needed for the rework.
C64 uses the same very slow bit-banging method as VIC-20.
Yes, for two reasons. The VIC-20 used 6522 VIAs as I/O chips, and these had a notorious bug in their shift registers requiring a bitbanged IEC serial I/O routine instead. This wasn't a big deal on a system with 5K of RAM, but it was a real problem on the 64. The 64 has 6526 CIAs for I/O, where faster IEC serial communications should have been possible, but the wiring got screwed up during board design and VIC-II DMA ("badlines") caused timing interruptions at inconvenient times, which demanded slowing it down even more. (A remnant of this is UI- and UI+ to speed up and slow down loading when used with the VIC-20, but that only works on the 64 if the screen is off.)
Commodore tried to solve this twice. The first time was for the Plus/4 series with TCBM drives which connected through the expansion port. The only drive of this type was the 1551, which was very fast, but only worked with the Plus/4 family. Commodore was going to design a TCBM interface for the 64 as well, but it wasn't really necessary as pretty much everyone had a fastloader by then. The 128 has a fixed serial bus and burst mode when combined with the 1571 disk drive, which is also very fast and doesn't require using the expansion port, but by then it was 1985 and the 8-bits were on their way out.
The 1571 is way better than the 1541, IME. It's faster with the 128, it's 100% compatible, it's more reliable and less prone to alignment problems, and it can also read MFM formats. But Bob worked on the 1541, so he loves it. :)
Paperclip (word processor) had an 80 column preview mode, which showed your text in hi-res 80 columns. It seemed like magic at the time and made ten year old me feel like I was performing serious business.
The IBM PC wasn't really a family computer like the C64 was. It was a business machine that could be fun for the family when dad or mom were done with work.
Obviously, they are comparing to only the high-end competitors (e.g., Atari 800 but not the 400, and no TI 99/4A which also used their own chips like Commodore touted as a selling point, nor the TRS-80 Color Computer that was intended for home use unlike the Model III business computer). Buyers who knew the real set of alternatives, at and below the C64's price point, might question why they need 64KB RAM, when the popular lower-priced competitors not shown in the table also did fine games and Basic programming (the main uses of home computers) while costing less money.
Then there's structuring "TV Output" as a feature of the C64, which they say the TRS-80 Model III doesn't have. But that's because the TRS-80 has an integrated display monitor, while the C64 includes no display in that price comparison.
I don't know what "'Smart' Peripherals" are. But that IBM PC defined industry standard peripheral interfaces for years.
The competitors also had obvious strengths not shown. Want your word processor to be in crisp 80-column text? A real spreadsheet program? Math coprocessor? Better graphics? Option to upgrade to a hard disk drive?