Can two single Commodore disk drives emulate a dual disk drive?

Question

The floppy disk drives manufactured for Commodore 8-bit computers (by Commodore itself and by various third parties) are either single-drive units, or dual-drive units where two disk drives share the same housing and controller. Each unit is assigned a device number from 8 to 15 on the serial bus, and each drive within a unit is assigned the drive number 0 or 1. When issuing disk commands from BASIC or via Commodore DOS, you specify both the device and drive number. For example:

• LOAD"1:FERRET",10 loads the BASIC program FERRET from drive 1 of device 10.
• OPEN 15,8,15,"C1:GNU=0:YAK":CLOSE 15 copies the file YAK on drive 0 of device 8 to the file GNU on drive 1 of device 8.

Of course, there are certain exceptions—the drive number can usually be omitted, and will default to 0; for some BASIC commands on some machines, the device number can be omitted and will default to 8; and on single-drive units, drive 1 behaves as an alias for drive 0.

Commodore(-compatible) drives are notable for being completely autonomous computers with their own CPU and memory. Would it be possible to reprogram a pair of single-drive units to emulate a dual-drive unit? For example, if I had a Commodore 64 with two single-drive Commodore 1541s, assigned device numbers 8 and 9, and each with drive 0, could I make them behave like a single dual-drive unit with device 8 and drives 0 and 1? To be clear, I am talking about reprogramming the internal drive computers themselves, not adding a wedge to the Commodore 64 that intercepts and reinterprets BASIC disk commands. The reprogramming should be completely transparent to any C64 program, be it BASIC or machine language, that accesses drive 8 using standard commands.

In order for this to work, the custom program running on the 1541 assigned device 8 drive 0 would have to intercept all the commands sent to the device by the Commodore 64, check what drive numbers are specified, and take the appropriate action for commands involving drive 1. In most cases (loading, saving, validating, scratching, etc.) it would need to forward the command to the 1541 assigned device 9 drive 0, wait for it to finish processing the command, check the error status, and then forward this back to the C64. The only two DOS commands that (possibly) allow two different drives to be specified simultaneously, Copy (for copying files within or across drives) and Duplicate (for copying an entire disk from one drive to another), would probably need custom code.

The question is, is the approach I've described feasible? In particular,

1. Are programs running on the 1541 (or similar single-drive units) even capable of intercepting and reinterpreting standard DOS commands?
2. If so, is there enough memory on the 1541 (or similar single-drive units) to do this (including support for the C and D commands) transparently?
3. Has anyone actually done this before?

Answer 1

Interesting idea. I like it.

(Some thoughts, to long for a comment and maybe helpful as well)

Sure, why not. The interface is software defined, so any protocol change should be possible.

Except, how should the C64 know that a response coming from device 9 is to be ignored?

Equally important: wouldn't doing so mean that not only commands, but as well any data read from the virtual device 8 drive 1 (TDFKA device 9 drive 0) or written onto would have to pass the bus twice, always relayed by the real drive 8?

Doesn't sound very practical, as it would (more than) halve the speed of the already slow bus when accessing the second drive.

I could think of a solution like used by IDE drives as more adequate.

Instead of only modifying one drive (the 8) give new ROMs to both, allowing both devices to listen to the same address (8), but only respond if either sees the drive number assigned to it (0 or 1).

Or more correct: the device that assumes itself as 8/0 will handle all command transfers, while 8/1 only listens. After receiving the command, only the device that was addressed will act accordingly and start communication from there.

It would also not really need more RAM, as for each device the operation is almost the same as before. It just may receive the command without doing the handshake - or not act on the command received if it's for the 'other' drive.

In fact, the 'secondary' drive may as well respond to two addresses, the 'virtual', like 8/1, and a 'real', like 9/0. Thus allowing programs that expect a standard setup to continue working.

To set the addressing one could either change the interpretation of the device switches like

• 11 -> 8/0
• 01 -> 9/0
• 10 -> 10/0 and 8/1
• 00 -> 11/0 and 9/1

Thus allowing to have two virtual twin drives.

Alternative and maybe better one could use the feature of reassigned device numbers in the range of 12 ... 15 to activate the additional feature. That might make it 100% transparent to existing software when mapped like:

• 12 -> 12/0 and 8/1
• 13 -> 13/0 and 9/1
• 14 -> 14/0 and 10/1
• 15 -> 15/0 and 11/1

To make it absolutely transparent to existing software that will not expect that behaviour it might be useful to require activation via a User command or a Memory-Write. But that depends on your scenario.

And yes, Copy and Duplicate may need some work, but it might be less work than assumed. All parameters are already received on both devices, so some implied variation of talk/listen could be used without having the C64 involved as controller. Again, not sure how the C64 will react.

What's left might be issues with downloaded programs and likewise modifications as they are not aware of that configuration, nor a (potential) new memory layout.