Now that version 1 of the POC unit appears to be working well, I'm ready to extend the design to the next level, which is to work out some means of providing mass storage facilities. For me, that means SCSI hardware. Accordingly, I have acquired some 53C94 SCSI ASICs, along with a
63 page data sheet.
The 53C94 is new to me, but is conceptually similar to the older 53C90A, with which I am familiar. Both ASICs work with the "narrow" SCSI bus, but the 53C94 has a variant that can support an HVD bus, which can operate over a 75 foot (!) cable. The other difference between the two is the 53C94 supports both SCSI-1 and SCSI-2 commands, whereas the 53C90A only supports SCSI-1 (the original 1986 ANSI standard). As any SCSI device manufactured since the mid-1990s will understand SCSI-2, I will use that as my programming model. Also, as it so happens, I have some
narrow SCSI-2 hard drives in my junk pile with which to experiment (the pictured drive came from a server I had in operation 15 years ago).
The 53C94 was designed to automate the SCSI bus protocol so the host machine wouldn't have to engage in all the required signaling and bit twiddling. Initial communication with a SCSI target is made by loading a command descriptor block into the chip's FIFO, telling it the target SCSI ID and then telling the chip to start the arbitration and selection sequence. Once selection has been completed, the chip will generate a SCSI phase change interrupt and two way communication can commence. If the target device fails to respond, selection will eventually time out and the 53C94 will again generate an interrupt.
Hardware-wise, the 53C94 was targeted to the Motorola 68K MPU (as was the 53C90A) and was meant to communicate with the host bus via 8 or 16 bit DMA. The controller can be also be configured to operate in PIO mode, which is how I plan to use it (no 65xx compatible DMA controller handy). If it were possible to run it via DMA, throughput onto the bus could reach upwards of 20 MB/sec. <Sigh>
The SCSI side of the chip is straightforward to implement. The 53C94 is able to directly drive the SCSI bus without extra hardware, other than bus termination resistors (
take a look-see at this schematic I concocted). As is characteristic of 8 bit SCSI implementations, 50 pin connectors and associated ribbon cable are used to connect all devices to the host.
Adapting the 53C94 to the '816 isn't too difficult. Chip selects work the same as on the 2692A DUART that I am using for serial I/O (the 2692 was also targeted to the 68K), so no additional glue logic will be required on the MPU side. Ironically, when run in PIO mode, the chip's data path is through the lower eight bits of the DMA port and the "data bus" on the chip is not used at all. It seems kind of odd at first but makes more sense once one is familiar with the part.
The 53C94 requires a clock input between 10 MHz and 25 MHz. This clock is used for internal timing purposes and to correctly sequence the SCSI bus. While I could derive that clock from Ø2, it will be more convenient to provide a separate oscillator for the purpose. This is because the chip has to be told what frequency range to expect, which if from Ø2, means I'd have to recode the firmware if I were to change the clock. As with the 2692, a separate clock means operation of the 53C94 is asynchronous to the 65C816 bus, and the same timing gotchas that gave me trouble with the 2692 are potentially present.
The actual circuit will be part of a new-design mainboard. I was toying with the idea of hand-building this thing and adapting it to the current POC unit, but don't feel like struggling with that 84 pin PLCC socket and all those pins on the SCSI port.
The real work will be in crafting a suitable driver. The SCSI bus operates in phases and the 53C94 will generate an IRQ each time the bus changes phase, an operating mode that suggests that the driver should be a mixture of foreground and IRQ code. The IRQ part would act as a dispatcher to select the part of the foreground code that is appropriate for the current bus phase. I'm envisioning where the dispatcher would change the return address on the MPU stack by using the phase bits (which can be read out of a particular 53C94 register) as an index into a dispatch table. Thanks to the 65C816's improved stack features, this will be less a job to code than an equivalent running on a 65C02. It isn't going to be a piece of cake, though.
When operated in synchronous mode, SCSI-2 can achieve a 10 MB/sec transfer rate across the bus (the data sheet incorrectly says 5 MB/sec). In reality, this can't happen using PIO, as none of the 65C816 load/store instructions can execute quickly enough to sustain that rate (hence the value of DMA). The model that I've worked out so far suggests about 750 KB/sec average throughput with the MPU running at 20 MHz. The select and setup times on the 'C94 in PIO mode will require at least one wait state to run at that high a clock rate. 750 KB/sec isn't too bad, though. At that rate, an entire 64K frame could be loaded in less than 100 milliseconds. In practice, much smaller amounts of data are handled per bus transaction, so the performance should be just fine.
Login
Register
FAQ
Search
It does the job of translating LDA #65 into A9 41 and poking that byte sequence into RAM at an address of your choosing, which means it is a real assembler. Anything it can do over and above that is frosting on the cake.
