17

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?

rwallace
  • 60,953
  • 17
  • 229
  • 552
  • 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. – 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 01:09
  • 1
    @MichaelGraf - so 4,000 bps? Still not exactly setting any records! – Maury Markowitz Dec 17 '20 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). – Michael Graf Dec 17 '20 at 20:26
  • 2
    @MichaelGraf yet C64 disk fastloaders were not faster than ZX Spectrum tape fastloaders. – hippietrail Aug 07 '21 at 07:18
  • 1
    @MichaelGraf: I don't remember any software fast loaders back in the day other than Vorpal Disk Utilities being able to offer anything close to a 10x speed boost, and even that required that disks be written in a special format. – supercat Jan 24 '23 at 23:24
  • 1
    @supercat: Have a look at this table (cartridge-based fast loaders; https://www.c64-wiki.de/wiki/Schnelllader#.C3.9Cbersicht_Steckmodul-Schnelllader) and the one below (fast loaders loaded into RAM). There are quite a few in the factor 10+ range. Sorry I couldn't find an English version, but I think it's pretty much self explanatory. – Michael Graf Jan 25 '23 at 05:58
  • 1
    When did those come out? I'd guess that the 10x ones probably relied upon information being written with a custom format, in much the same way as the Vorpal disk utilities did. I think some newer utilities can manage to read data out-of-order, but I don't remember anything like that existing back in the day. – supercat Jan 25 '23 at 09:37
  • 1
    @supercat: The only ones with a custom disk format are Heureka-Sprint (25x) and Transwarp (50x); all the others use the standard Commodore format. I got the Final Cartridge III in 1987, and 10x feels very plausible. – Michael Graf Feb 08 '23 at 10:37
  • 1
    @MichaelGraf: Vorpal disk utilities, which I purchased BITD, used a custom disk format. Data written at normal speed cannot be read sequentially at 10x speed; if any fast loaders were achieving such speeds, it would have to be by doing a whole-track read at 2x interleave as soon as one needs to read any sector from it (which would take two spins), examing the data to figure out which parts are useful and which track to read next, and then repeating the process. I don't recall any fast loaders BITD doing that with normally-formatted disks, even though I was still using my Commodore 128... – supercat Feb 08 '23 at 15:10
  • 1
    ...quite a lot through 1988. My interest in it was starting to wane, though, so maybe the developments came just a smidge too late for me to notice. – supercat Feb 08 '23 at 15:11

3 Answers3

18

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.

Toby Speight
  • 1,611
  • 14
  • 31
Raffzahn
  • 222,541
  • 22
  • 631
  • 918
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.

supercat
  • 35,993
  • 3
  • 63
  • 159
1

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.

Purple Lady
  • 21
  • 5
  • 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 Jan 27 '23 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 Jan 27 '23 at 16:35