17

The Commodore 1540 disk drive, along with its better-known successor the 1541, is a computer in its own right, with its own 6502 CPU.

Why was it designed like that?

It adds significant cost to the drive, such that the drive ended up costing about as much as the computer to which it was connected.

It's not like no one thought of doing it any other way. The industry had seen the Apple II drives that just used the CPU in the computer.

It wasn't for performance gain. On the contrary, the Apple II got a lot more performance out of its drives!

One thing I can think of is that it may have been what allowed a serial cable to be the connection between computer and drive; maybe having the computer directly control the drive, requires multiple signals to be sent simultaneously, or reassembling the bits at the other end already requires some smarts in the drive? But even if so, surely a parallel cable would be cheaper than putting a whole (even if minimal) computer in the drive?

Another possibility is that they were thinking in terms of offering newer, higher capacity drives that the host machine would not know about? Which would be a reasonable thing to plan. In the end it did not work out, because copy protected games, but the engineers can be forgiven for not thinking of that.

Or was there some other reason I have not thought of?

Improve this question
5
  • 7
    Additional possibly: it is cheaper than using a real drive controller, because Commodore owns the chip foundry that produces the 6502 and 6522, both of which are already designed. I do not know whether this reasoning, although attractive, has a strong foundation in reality though.
    – Tommy
    Commented Jun 12 at 23:14
  • 2
    On the cost argument, if I recall correctly the Disk II was almost twice as expensive as the 1541 which makes the cost argument suspicious.
    – throx
    Commented Jun 14 at 3:35
  • 1
    While it may not have been the design intent, performance could very easily have been an issue - I recall that my father wrote a custom business application for a neighbor, and some of the database maintenance tasks were offloaded to the CPU in the dual-drive unit (I think it was a 2040); this allowed the maintenance task to "run in the background" while other tasks could be run in the foreground on the PET/CBM.
    – Jeff Zeitlin
    Commented Jun 14 at 10:17
  • 2
    @throx But I was under the impression this was because Apple sold their drive at a much higher profit margin?
    – rwallace
    Commented Jun 14 at 10:28
  • @rwallace as the ‘80s dawned and then progressed, I wonder whether Apple’s approach ended up costing them more as they couldn’t use off-the-shelf drives without modification. Emphasis on “I wonder”.
    – Tommy
    Commented Jun 15 at 11:17

5 Answers 5

Reset to default
22

TL;DR: Commodore Peripherals Are Intelligent Peripherals - they need a CPU anyway.

Instead of integrating peripherals with the PET, like many systems did, Commodore added a (somewhat cut down) version of the HP-IB (*1). It allowed to get the machine out the door early on without having to develop a disk drive (or other peripherals) at the same time. Only the generic interface hardware and communication protocol software had to be done, while peripheral implementation and DOS development could be postponed ... and during development HP-devices be used.

It's also the reason why Commodore BASIC didn't feature any DOS/printer/Serial or whatsoever commands, only generic channel handling.

The VIC-20, as a low end PET follow up inherited that design - now with a serial communication and the 1540 drive. Not at least as it allowed to save on software cost. Writing software can cost much in terms of money and time. By using the same structure as used with the PET, only the low level communication routines had to be adapted to the new serial protocol everything else ("the whole stack") could be used as is.

Integrating a controller into the VIC-20 would have meant to rewrite communication as well as DOS, while not solving the issue how to connect other peripherals than disks. Not to mention that not including a high speed peripheral like a disk drive simplifies the computer design, as it eliminates complex timing issues and/or the addition of DMA.

The 1541 is only the last step in this evolution, as it's essentially just a 1540 with slowed down serial speed.

Bottom line:

  • Faster development
  • Modular design
  • Expandable design
  • Lower soft- and hardware development cost
  • Lower development risk

One point:

It wasn't for performance gain. On the contrary, the Apple II got a lot more performance out of its drives!

Neither CPU nor Drive were part of this - the serial bus is the only relevant bottleneck here. And that was added to cut cost.

On a side note it's strange that question is asked about the drive, but not any printer. Printers also had their CPUs - except for some rather strange fellows - but calling it a "computer in its own right" has no ring.

Heck, by that every keyboard or mouse would be a computer. It being a 6502 in case of the 1541 doesn't make a difference (*2)

Looking back, computer without intelligent peripherals seem rather the exception than the norm, even without touching USB and other more recent systems.

*1 - A bit like Atari's ACSI many years later - and similar to later machiens using IDE by adapting a (simplified) ISA bus protocol.

*2 - Not to mention that the 6500 series was meant as controller.

Improve this answer
19
  • 5
    It is the fate of many computers in their old age to end up as a device controller or front end in some younger system.
    – dave
    Commented Jun 12 at 23:20
  • 4
    A floppy drive need not use any kind of DMA if interrupts are disabled while reading and writing disks. Having the restore key trigger an NMI on a CPU while it was writing a disk would probably not have been a good idea, but the cost of the 1526 and 1540 could probably both have been reduced if they'd used the VIC-20 CPU to do most of the heavy work. On the flip side, RAM expansion would have been essential when using a floppy, since allocating space for buffers from an already limited 5K wouln't leave much left for anything else.
    – supercat
    Commented Jun 13 at 3:46
  • 8
    "Printers also had their CPUs - except for some rather strange fellows but calling it a 'computer in its own right' has no ring." ...I don't know, when you're talking about a workgroup laser printer that not only has its own CPU, but it's a fully-independent network device and runs its own webserver, print server, file server... I have no reservations about describing that as "a computer in its own right". Heck, some you can telnet/ssh into. And I'm pretty sure on more than one occasion, I've sent jobs to a printer with a faster CPU and more RAM than the machine I was printing from!
    – FeRD
    Commented Jun 14 at 8:01
  • 3
    Ahem. Calling the OED a 'random dictionary' is insulting our cultural heritage :-)
    – dave
    Commented Jun 14 at 19:00
  • 2
    TLDR to call the OED a 'random directory containing words' would be the same thing as calling... Germany a small part of the EU.
    – Questor
    Commented Jun 14 at 19:36
6

Late 1981: 6502 - 3$ (MOS for Commodore, internal prices); Typical working FDD controller chip (off-the-shelf) - 30$

Improve this answer
2
  • 3
    But wouldn't a CPU also need ROM/RAM/etc? Or does the controller also need extra things?
    – paxdiablo
    Commented Jun 15 at 3:39
  • There are three approaches one could take when interfacing a drive to e.g. a PET or VIC-20: (1) Use a controller chip, and the design will be relatively insensitive to the host system; (2) Have the host CPU perform precisely timed I/O directy, in a way very sensitive to the host system, or (3) Have some other CPU perform precisely timed I/O directly, in a manner agnostic to whatever device is connected to it. Having a $600 which is expected to be compatible with future computers was more palatable than a $500 device that wouldn't be expected likewise.
    – supercat
    Commented Jun 17 at 16:48
5

Basically the floppy drive contains a computer which acts as the floppy drive controller, but it also contains the "DOS" or Disk Operating System, which basically means that you don't read/write raw blocks of disk sectors, but you open and read/write files.

If the disk drive did not contain a CPU, it would require to connect to some other local bus which has the memory bus, and have a floppy controller sitting on that bus, and with the floppy cable going to the powered disk drive. And each computer would then need more ROM code, maybe on the FDC bus attachment or built-in, that can use the floppy and provide the file system level access.

Improve this answer
4
  • 1
    The Apple Disk Controller II card has eight small DIP chips, none of which is actually a disk controller. I don't know what aspects if any were patented, but absent such issues the design could have been easily adapted to the VIC-20, in the same form factor as ordinary VIC-20 cartridges. While there are advantages to having floppy controllers interface with DMA, there's no actual requirement that they do so.
    – supercat
    Commented Jun 13 at 15:48
  • 3
    @supercat IIRC, it's bit-banging the interface with the CPU. So the CPU has no time to do anything else than to sit in a loop while transferring data. Such thing would have been impossible on e.g. C64 - the tape is handled like that but the data rate is so slow it can be done with some help from the CIA when reading tape data. There would be no time to handle floppy data rates like that, especially with the VIC-II halting the processor for multiple cycles during the "bad lines" where it fills the internal buffers for next few video lines.
    – Justme
    Commented Jun 13 at 16:12
  • 1
    Using such an approach on the C64 would have required disabling interrupts and blanking the screen during disk access, but would have been perfectly workable given such constraints as evidenced by the fact that the Apple II actually works that way.
    – supercat
    Commented Jun 13 at 17:03
  • 1
    The critical aspect of timing is that an LDA XXXX / BPL *-3 loop needs to be able to grab a value that might be available for less than eight cycles. Replacing the universal shift register that's used for both input and output with a separate 74LS595 for input and a 74LS596 for output could have eased the timing to about 30 cycles, but losing 42 cycles for badlines would still have broken things.
    – supercat
    Commented Jun 13 at 17:18
1

A lot of it comes down to history.

Commodore had previously designed the 2031 and 4040 for the Commodore PET, and the 8050 (and eventually 8250) for the SuperPET. Internally, the 1540 (and 1541) was/were pretty similar to those, including the disk operating system running on a CPU built into the drive.

All of those used HPIB to connect to the drive, which was more expensive, but much faster (5x or so). All but the 2031 were also dual drives, which let you take quite a bit more advantage of the drive's intelligence--for example, you could issue a command to the drive to back up disk 0 to disk 1 (or vice versa) and the drive would to it entirely on its own, so you could do other things with the computer while the drive did copying on its own.

This was also quite expandable and versatile--HPIB acted as basically a small network, so you could connect a number of computers and drives, and all the computers shared access to all the drives. In theory, you could do transfers directly from one computer to another as well, but there was little software to take advantage of that (and without multitasking, you couldn't do anything else with either computer while they exchanged information.

Unfortunately, between a slow point to point connection and only single drives, the 1540 and 1541 lost essentially all those advantages.

Improve this answer
3
  • As I understand it, the 154x allowed the arbitrary code to be executed on the drive CPU, which was used for turboloaders. This choice seems unusual. Contrast early MFM hard drive controllers, which often incorporated a Z80, but didn't have any mechanism to change what code the Z80 was executing short of blowing a new ROM. Is it known why the 154x drives were designed to allow this?
    – john_e
    Commented Jun 17 at 22:16
  • @john_e: The 1541 certainly did allow that. Did MFM controllers usually have dedicated RAM chips, or did they use all-in-one chips like a RIOT or RRIOT which would have been limited to 128 or 64 bytes of RAM, respectively? The 1541's RAM, at 2K bytes, was big enough to hold a non-trivial amount of code, but a 64-byte RRIOT wouldn't be.
    – supercat
    Commented Jun 17 at 22:50
  • @supercat: The IBM / Xebec MFM controller I was thinking of has 1K of memory (in the form of two 2148 SRAMs). From the Z80's point of view it's at 8000h and contains a 512-byte sector buffer, the Z80 stack and some controller state.
    – john_e
    Commented Jun 22 at 10:51
1

There always has been a tradeoff to make between using discrete logic, custom chips, and microprocessors(since they existed) and some combination of these when making any component in a computer system.

So probably from economic, system design and system performance considerations they went with a microprocessor.

Improve this answer

You must log in to answer this question.

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