3 ms·

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 dri

by juancn 1y ago

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.

fmajid 1y ago
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.
- TMWNN 1y ago
  ... 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 https://news.ycombinator.com/item?id=41685888>
  - ajross 1y ago
    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.
  - CamperBob2 1y ago
    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.
  - II2II 1y ago
    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.
    - Tuna-Fish 1y ago
      > 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.
classichasclass 1y ago
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.
- Tuna-Fish 1y ago
  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.
  - deleted 1y ago
    [deleted]
leptons 1y ago
>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. https://www.lemon64.com/forum/viewtopic.php?t=58317 https://www.lemon64.com/forum/viewtopic.php?t=58317
- ako 1y ago
  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.
  - bonzini 1y ago
    It gets rid of the clock bit, synchronizing the two CPUs so that the 1541 can transmit 2 bits at a time. It was still slower due to GCR decoding. Over the last 10 years people have started to write streaming GCR decoders too.

by juancn 1y ago

fmajid 1y ago

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.

TMWNN 1y ago
... 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 https://news.ycombinator.com/item?id=41685888>
- ajross 1y ago
  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.
- CamperBob2 1y ago
  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.
- II2II 1y ago
  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.
  - Tuna-Fish 1y ago
    > 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.

classichasclass 1y ago

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.

Tuna-Fish 1y ago
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.
- deleted 1y ago
  [deleted]

leptons 1y ago

>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. https://www.lemon64.com/forum/viewtopic.php?t=58317 https://www.lemon64.com/forum/viewtopic.php?t=58317

ako 1y ago
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.
- bonzini 1y ago
  It gets rid of the clock bit, synchronizing the two CPUs so that the 1541 can transmit 2 bits at a time. It was still slower due to GCR decoding. Over the last 10 years people have started to write streaming GCR decoders too.