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?
