11

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?

Improve this question
7
  • 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, 2016 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, 2016 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?
    – Brian Blake
    Apr 26, 2016 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).
    – Eric Shepherd
    Apr 26, 2016 at 18:17
  • @Eric Shepherd - that was actually a very good answer.
    – Brian Blake
    Apr 27, 2016 at 0:36

1 Answer 1

Reset to default
8

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).

Improve this answer
2
  • 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, 2016 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, 2020 at 23:06

You must log in to answer this question.

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