Why was the 1541 so slow?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.