Coming from the TRS-80/TandyColor Computer lines, I had always heard of how slow some other systems disk storage were, regarding data transfer rates, etc... The CoCo lines disk storage was pretty fast - I never had any complaints other than the hurdles we had to jump thru to access double sides drives (either use flippies or modify the DOS).

I've got an Atari 800 system now with a 1050 disk drive, and am waiting to find some disk software to test the system (the 800 works great). Can some explain the reasons why the data transfer rates were so slow? I have heard that in many cases, the cassette was faster - is this true?

I've also heard and read about mods to the Atari drives to address this issue. Are any still available today? Are the SIO adapters available today prone to the same issues?

  • Slow? Never waited more than half a minute even for a full-memory game. It's the Atari cassette recorder that was abysmally slow, and its mods were in high demand, shortening the wait time by an order of magnitude.
    – SF.
    Apr 22 '16 at 8:04
  • 1
    The question is rather broad, and differences in disk storage (a huge subject in itself) and speed of loading are also two different questions. Maybe narrow it down a bit? E.g. for a description why the (default) C64 floppy access was so slow, see here
    – dirkt
    Apr 23 '16 at 7:58
  • 1
    Okay, I can be more specific: CoCo data transfer rate: 250 kbps Atari 810 data transfer rate: 19.2 kbps (not modded) Atari 1050 data transfer rate: 19.2 kbps (not modded) Apple ][ data transfer rate: 1.5 kbps Coleco ADAM Data Pack: 11.5 kbps C=64: Let's just call it the slowest of the group Is it safe to assume the Atari hardware was dealing with the slowness of the SIO bus? Apple ][ fared better than the C=64. Or was it just the implementation of the floppy standard wasn't the same across the board? Apr 26 '16 at 17:18
  • 2
    There wasn't really a standard at all early on. The drives were just devices that would throw bits onto a disk and read them back; it was up to the individual manufacturer to make sense of those bits. So everyone implemented their own structures on the disk in order to suit their particular needs, or based on marketing requirements (such as in Apple's case, where they needed a disk drive ready to demo at CES so they threw together a format over a couple of days and wrote the code to make it work). Apr 26 '16 at 18:17
  • @Eric Shepherd - that was actually a very good answer. Apr 27 '16 at 0:36

The major difference between drive speeds in classic computers is the philosophy and design of the drive and it's attachment mechanism. Some computers, such as the TRS-80/CoCo and Apple II lines, used a bus-level connection that allows the drive's controller to dump data in a parallel fashion from the drive to the computer's RAM.

Other lines, such as Atari and Commodore, used a serial interface that could only transfer 1 or 2 bits of data at a time, though the drives were smart devices with their own processor which offloaded the control of the drive from the computer, which has its own advantages such as letting music and graphics operate as "normal" while data was being pulled from the drive. Also, the serial mechanism allows for more devices to be attached. I've had over 6 different IEC devices attached to a single Commodore 64 when running a BBS and there was never an issue.

Although the Commodore's serial out of the box was slow, it could be sped up considerably using fast-disk routines which re-wrote the code for the IEC bus in both the computer and the drive. The most famous of these was JiffyDOS, which is quite good. It requires that a new ROM be placed in both the drive and the computer to work, but the speed improvements are well worth it. For example, JiffyDOS can see a 10x improvement when moving data around on fast devices such as the CMD Hard Drive or a modern device such as the uIEC (pronounced micro-IEC).

  • 2
    Commodore's implementation wasn't slow because it was serial, but because a hardware bug in the VIC-20 meant they couldn't use the IO chip for serial/parallel translation, and had to do it all on the CPU. The C64 was worse in that they kept the same implementation but had to slow it down more due to VIC-II video timing. The "correct" implementation would come along with the 157x drives and the C-128, which showed how much faster it could have been years earlier...
    – Joe
    Jun 13 '16 at 20:01
  • @Joe The C64 (and VIC-20) were indeed slow due to the serial interface: just slower yet due to the bit-banging before the C128 and 1571 fast mode. Even in "fast mode" the interface was only 5200 cps according to Commodore. The Apple II's interface was more than ten times that speed.
    – cjs
    Mar 12 '20 at 23:06

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.