While I am working on the layout of my Apple Disk ][ emulator, I thought I would give a bit of background on the Disk ][ and my plan to conquer it.
 |
Functional Digram of Disk II
from 'Understanding the Apple II' by Jim Sather |
The Apple Disk ][ was a major achievement for Apple and Steve Wozniak. They were able to replace a large number of logic ICs on a standard disk controller with a ROM-based state machine or "Logic State Sequencer ROM". The disk head is positioned by direct software control of the head stepper, rather than an absolute positioning system. To get to absolute track zero, the controller slams the head against the stopper repeatedly, causing the loud clatter recognizable as the Apple II start-up sound. This head control accounts for 4 wires connecting the drive and the controller card. The drive is enabled by an additional line that activates the drive motor and serves as a drive select. Writing is handled by two lines; the write request, which puts the magnetic head in the write state, and the actual write data serial line. There are +5v, +12v and GND power lines. Finally, there is a write protect line that indicates whether there is a notch in the disk, and a serial read pulse line. The read pulse is controlled by a special IC that outputs a 1us pulse for every field reversal on the disk. The interval between the start of consecutive write pulses is about 4us. The data transfer is asynchronous, with no clock line, but allows for some variability in when the read pulse can occur.
With this information, my plan is to convert all of this into an
SPI serial stream. The 4 head stepper lines, 2 write lines and 1 enable line will be multiplexed into an 8 bit/byte serial stream (with one empty 'reserved' bit). The read pulse will be 'emulated' by 4 bits of data: 1 high bit, and 3 low bits for every read pulse. At a 1MHz transfer speed, we end up with a 1us high pulse, and 3us low, for a total of 4us. Just what the Disk ][ controller card needs! To add the write protect, I can add another line, or multiplex it into the read pulse since we have 2-3 bits of empty data that will always be low. The clock line can be from the drive controller card or the micro-controller. The main problem it that the emulator will need to transfer 4 bits of SPI data for every 1 bit of Disk ][ data. Still, this is better than my original plan of 8 bits SPI/1 bit of Disk ][ at 2MHz. The benefit is that the SPI transfer can be easily handled natively by a typical micro-controller. No processor intensive bit-banging is required. Also, we don't need a micro-controller at all to handle the timing: it is built into the SPI transfer. We'll see if these advantages make up for the extra bit shifting required.
By the way, I have decided to use the FTDI UM232H for my proof-of-concept rather than the Arduino/Atmega AVR. The FTDI chip puts out a nice square SPI wave, with no delay between bytes like the megaAVR. This is important for our timing sensitive abuse of SPI. However, this might not be an issue at the slow speed we are going. Also, I am familiar with
libusb which I can use to control the FTDI chip and not so familiar with the Arduino IDE (although it looks easy enough).
