The Commodore 1541 floppy disk drive, sold for use with the 64, was notoriously slow for historical and technical reasons:

  1. Marketing insisted on compatibility with the 1540, the floppy drive sold with the Vic-20, which was slow because the shift register in the 6522 VIA chip didn't work, so it had to transfer a bit at a time instead of a byte at a time.

  2. Then it had to go even slower because unlike the Vic-20, the 64's video chip has to completely take over the bus one out of every eight active scan lines.

Okay, so given the worst-case combination of those two factors, with no development time allowed for alleviating the problem, one could see how the drive could end up only being able to transfer one bit per horizontal blank = 63 microseconds. 1/(63e-6) = 15873 bits/s = 1984 bytes/s.

But apparently the actual speed was only 400 bytes/s.

Why was the actual speed only a fifth of what would seem to be possible even with the unhappy combination of historical and technical problems?

  • 8
    Nitpick: The 1541 wasn't slow, the Commodore serial bus protocol was -- as evidenced by the software-only fastloaders which could achieve a tenfold gain in speed without any change to the hardware. – Michael Graf Dec 13 '20 at 23:07
  • 1
    Been playing around with a C64 with 150K/sec storage and now I know why it feels ludicrously fast! – Brian H Dec 14 '20 at 1:09
  • @MichaelGraf - so 4,000 bps? Still not exactly setting any records! – Maury Markowitz Dec 17 '20 at 20:09
  • 1
    @MauryMarkowitz — Is that a bits or bytes per second? Most software fastloaders achieved a factor of 10 (which would be 4,000 bytes / second), with some claiming a factor of 15 or 16. Adding a parallel cable to the User Port would bring you to somewhere around 25x (at the expense of an extra cable and changes to the drive). – Michael Graf Dec 17 '20 at 20:26

the drive could end up only being able to transfer one bit per horizontal blank = 63 microseconds. 1/(63e-6) = 15873 bits/s = 1984 bytes/s.

That would be the bitrate during transmission within a byte, but bytes are framed and handshaked, which adds an average of 160 µs per byte. Resulting in (63 * 8) + 160 µs, or ~664 µs per byte. So the upper transfer sped is rather at or below 1500 byte/s

Above numbers are the absolute minimum, the time between to bytes can be as long a 1000 µs and still within specs. Additional turn around times are in front of commands and between blocks/commands. Next, the 1541 does need time to react and respond. And finally the C64 side does as well need management past pure bit transfer. All of this adds up.

But apparently the actual speed was only 400 bytes/s.

Before everything else, it's important to keep in mind that these 400 Bytes/s are about reading from a real world FD drive. With real head movement, search latency, transfers and turn around. The often used test is about reading a 185 block program, which means at least 10 track changes and so on.

A good benchmark for real world transfer rates using an unmodified C64 (nospeed loader, all original routines used) without a mechanical drive might be the SD2IEC interface. It offers an average throughput of 650 Bytes/s. The SD2IEC is essentially an Atmel ATMega running at 8 MHz direct handling the serial IEC. Its response and transfer time are close to the maximum possible. Reading from SD/MMC does not carry any mechanical movements, search latency and rather high speed data transfer from SD/MMC to controller RAM.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.