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?

  • 12
    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. Commented Dec 13, 2020 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
    Commented Dec 14, 2020 at 1:09
  • 1
    @MichaelGraf - so 4,000 bps? Still not exactly setting any records! Commented Dec 17, 2020 at 20:09
  • 2
    @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). Commented Dec 17, 2020 at 20:26
  • 2
    @MichaelGraf yet C64 disk fastloaders were not faster than ZX Spectrum tape fastloaders. Commented Aug 7, 2021 at 7:18

3 Answers 3


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 two 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 need time to react and respond. And finally the C64 side also needs management as well as the bit transfers. 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 (no speed 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 directly handling the serial IEC. Its response and transfer time are close to the minimum possible. Reading from SD/MMC does not require any mechanical movements, and has better search latency and higher speed data transfer from SD/MMC to controller RAM.


An important thing to recognize is that at any given time the drive can either be communicating with the C64 or receiving data from the drive head. For each 254 bytes of data received during the normal loading process, the following steps have to happen in sequence:

  1. The drive decides to read a particular sector.
  2. The drive waits for the disk to rotate to the sector header.
  3. The drive reads the contents of the sector.
  4. The drive decodes the contents of the sector.
  5. The drive outputs the data to the computer.
  6. The drive selects the next sector and loops back to the beginning.

The need to perform those operations separately in sequence limits the speed to a fraction of what could be achieved on a system like the Apple II, which can actually manage a throughput of slightly over 20kbytes/second if decoding is processed while the data is being read from disk.


Much of the slowness had to do with the decoding. There are now various fast loaders that take advantage of undocumented opcodes and other 6502 hacks. With the drives, you could not reliably have more than two zeroes in succession. So that required converting between what the user wanted to store and what the drive could reliably store. So lookup tables were required, and 5 bits were needed for each nibble. Now, they didn't bother trying to make the decoding work in real-time. So, it would have to read and store the raw data, then do the decoding and CRC checking before sending it to the computer. But, as others later discovered, you could also do much of the work during the disk I/O.

  • I wonder how hard it would have been to write a routine which could fit comfortably in the 1541 memory and record the sector number and first two data bytes of each sector, starting with whichever sector spun past the head next? If one were to blindly hope that the first two bytes would be read correctly, without validating the CRC, I would think it would be possible to transmit that information to a C64 or even VIC-20 before the ignored part of the data was finished, and this would allow the computer to build a map of where every sector of every file was located in under 8 seconds.
    – supercat
    Commented Jan 27, 2023 at 16:33
  • Normally, the "V"alidate command takes a long time (e.g. minutes), and the Validate operation included in Kwik Copy doesn't seem to have done anything to improve that, but I would think an under-10-second version could have been accomplished quite fast, and a multi-file delete could have simply erased directory entries and then done a validate.
    – supercat
    Commented Jan 27, 2023 at 16:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .