The Commodore 1541 floppy drive was a separate computer in its own right, with its own 6502 CPU. It was designed that way because they were basically copying the design from the Vic, partly due to a directive to be able to reuse old hardware, and partly due to lack of schedule time.

This design had a significant downside: unlike the Vic, a large percentage of Commodore 64 owners actually ended up buying a disk drive, but it was expensive to do so, because, well, the drive was a separate computer in its own right, that cost about as much as a 64.

A logical response to this would have been to release a new version of the 64 with a built-in drive. There certainly were some successful 8-bit machines with built-in disk drives, like the Amstrad 664 and some of the later Tandy models. Of course, if Commodore wanted to do this, they would've had to make sure the new machine was backward-compatible, that it would run existing 1541 software.

They eventually sort of did this, with the 128D. Why 'eventually sort of'? Well, the 128D incorporated an entire 1571 drive into the case, complete with all the separate electronics, so there wasn't really a substantial cost saving. And they had to do it that way, because a redesign would have been incompatible. Sure, the high-level kernal interface could have been made compatible, but copy-protected games used low-level code that tweaked the hardware directly.

It seems to me if you were setting out to design a disk drive that is a separate unit from the computer to the extent of having its own CPU, the obvious way to design the communications protocol between computer and drive would have been to make it high-level, to have the drive just accept instructions to read or write particular sectors. But that's not what they did. The protocol actually allowed the computer to download and run arbitrary machine code on the drive. And once that capability existed, and was enthusiastically used, it would then be very difficult to change the design without breaking backward compatibility.

Why was the protocol as it was? Were they thinking in terms of facilitating copy protection, or using the drive CPU as a second processor? I have never heard any of the designers comment on that question. I'm guessing the latter. It quite reasonably didn't occur to them at the time that they were painting themselves into a corner for the future.

The same thing seems to have happened with the Atari 810 floppy drive, which likewise had its own CPU; later models added features, but never changed that fundamental decision. I'm guessing for the same reason.

Did any 8-bit drive unit ever accept only a high-level protocol, such that it would be possible for a later revision to omit the separate drive CPU, while retaining backward compatibility?

  • 6
    Commodore produced "a new version of the 64 with a built-in drive" a lot earlier than the 128D: in 1984 they released the SX-64, a portable (or rather "luggable") Commodore 64 with a built-in 1541 and monitor.
    – Psychonaut
    Mar 3, 2022 at 13:17
  • 1
    For CP/M that was common. It had the abstraction layer in the BDOS that did exactly this. Mar 3, 2022 at 13:26
  • 1
    Even today, disk devices that are designed to be backwards compatible with the 1541 (e.g. SD2IEC), use a CPU to implement the "high-level" protocol, which really is just hding the fact that the DOS for these systems runs on the disk device.
    – Brian H
    Mar 3, 2022 at 13:55
  • 1
    As for why CBM supported "low-level" protocols- likely they wanted to allow for replacement DOS running on the computer, like in the manner of GEOS.
    – Brian H
    Mar 3, 2022 at 13:59
  • 3
    "Did any 8-bit disk drive screen off the hardware?" is confusing in that it seems to indicate a disk drives (runs/controls) the screen. Perhaps "screen" would be better off as "hide" or "isolate".
    – paxdiablo
    Mar 3, 2022 at 14:54

2 Answers 2


Like the CPC664 / 6128, the BBC Micro had an internal floppy controller and provided a Shugart connector for floppy drives. Unlike the CPC (which always used a µPD765A) the BBC series had several different possible floppy controllers; the original design used an Intel 8271, but third party upgrades and Acorn's BBC B+ and Master used a WD 1770. The computer's DFS or ADFS filesystem ROM would act as an abstraction layer to conceal these differences from programs.

Any drive that used SCSI would also meet the requirement for a high-level protocol that didn't tie the manufacturer to a particular implementation at the drive end. SCSI hard drives were sold for some 8-bit micros, including the BBC and the Amstrad PCW. While SCSI floppy drives existed, I'm not aware of any being sold for 8-bit micros.

  • 2
    Digressive, but it surprised me to learn that SCSI support is baked into the original Acorn ADFS ROMs; adding it to my Electron emulator — given that I already had a virtual SCSI device for the machine to talk to — was a really quick job.
    – Tommy
    Mar 3, 2022 at 17:47

(This only addresses the question in the title and the last paragraph of the question.)

Did any 8-bit drive unit ever accept only a high-level protocol, such that it would be possible for a later revision to omit the separate drive CPU, while retaining backward compatibility?

Amstrad CPC disk drives are controlled by a NEC µPD765A floppy disk controller, and the drives units themselves are fairly dumb (same as PC disk drives — in fact PC drives can be used with CPCs with little effort). I wouldn’t call this a high-level protocol, but it offers far less freedom than 1541-style drives!

Technically this doesn’t fit your question above, since there was no drive CPU to omit in later revisions, but I think it fits the spirit of your question.

Another candidate is the Apple Disk II, although it needs to be reasoned about somewhat differently — the interface used by software is exposed by the slot-in controller, not the drive. The software interacts with an RWTS (Read or Write a Track and Sector) subroutine, and any controller/drive combination implementing the appropriate routines at the published addresses would technically be compatible. But see Passport and 4am’s cracking journals for some idea of the fun and games that were still possible with this setup.

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