Apple‐68k: Ideas for Extending the DCD Protocol - FujiNetWIFI/fujinet-firmware GitHub Wiki

Problem Statement

The floppy drive port on Apple Macintosh computers can communicate with floppy drives and the HD 20 hard disk. We would like to extend this to support other virtual devices.

Possible Approaches

  • Extend the DCD protocol
    • Patching the Sony driver
    • Replacing the Sony driver
    • Working along with the Sony driver
  • Keep the DCD protocol as is
    • Using special block offsets
    • Using special files, and tag bytes
    • Using special files, magic numbers, and access sequence

Extend the DCD protocol

Extending the DCD protocol with additional messages seems like an obvious choice as the DCD specification already supports device selection. However, on the Macintosh, access to the IWM chip is done via a device driver called the ".Sony" driver. Extending the DCD protocol would require patching or replacing that driver with one that was capable of sending the new messages.

Patching the Sony driver

The Sony driver has changed at various times during the Mac's evolution, as new ROMs were released and new floppy disk densities were introduced. At a later time, the IWM chip itself was replaced with a newer SWIM chip and changes were made to the Sony driver to support it. Because there is not just one Sony driver, but an entire lineage of them, patching that driver seems technically daunting.

Replacing the Sony driver

Replacing the Sony driver with another of our own making is a possibility. The Mini vMac emulator does this to support its custom disk image format. But unless we choose to disable all floppy drives or HD 20s on a FujiNet-enabled system, we would still have the challenge of supporting all the hardware the Sony driver ever supported in our driver.

Working along with the Sony driver

A third option is to keep Apple's Sony driver in place, without modifications, but attempt to access the IWM when it is idle. This is challenging because longer I/O operations done by the Sony driver can be interrupted and restarted, so any code that attempts to access the IWM would have to coordinate its actions very closely with the Sony driver. This level of coordination would require a deep understanding of the Sony driver, and likely involve some patching, making it no better than any of the other proposals.

Keep the DCD protocol as is

Some possibilities do not involve changes to the Sony driver. These solutions assume that the FujiNet device is emulating an HD 20 and that we send commands using DCD commands that are already present in the Sony driver, such as commands to read and write blocks from the device.

Using special block offsets

Assuming the Sony driver does not validate block addresses, special messages could be sent and read by reading and writing to blocks beyond the end of the emulated drive. Tashtari has called this approach "negative LBAs"

If the Sony driver does validation, it might be possible to use blocks that are still within the emulated drive, but outside of the volume's partition.

Using special files and tag bytes

Another possibility is to use blocks that are within the volume itself, as part of special files. This requires FujiNet to be able to distinguish access to those blocks from access to other blocks in the file system.

On the HD 20, Apple has defined an interface where each 512-byte block has an additional 20 bytes of tag information. These bytes are loosely defined by Apple to contain meta-data that can be used to aid disk recovery tools. Since these bytes are transmitted with each DCD command, it may be possible to use these to signal to the FujiNet device that a read or write is a special command.

Using special files, magic numbers, and access sequence

A last possibility is to include a magic number in the 512-byte block itself. This is prone to false positives in random data, so it might be coupled with an additional requirement that blocks be accessed in a very specific, but unusual, order. For example, a special command might consist of writing the magic number and the associated command to a block and then immediately reading the block preceding it. FujiNet would detect such a request, perform the command, and return the response.

The advantage of the last approach is that the API consists simply of writing at specific offsets within files, something a majority of Mac programming languages could do, even Basic or HyperCard making the API very accessible.