danm@mspiggy (Dan McCabe) (11/08/83)
Well, after two weeks of hardware and software hacking at home, I have a hard disk interface for my CoCo and OS/9. Hardware: The hard disk is a Shugart SA-1004 (10M unformatted) with a SASI type controller. The only hardware which I built was a CoCo to SASI(SCSI) host interface. Hard disk controllers in general are intelligent controllers which talk over a parallel bus with hand-shaking (the SASI bus). The hand-shaking is very similar to parallel printer hand-shaking (e.g. Centronics). For each byte transfered, the controller asserts a REQ (request) line. The host interface puts the byte on the bus (or fetches it, depending on direction of transfer). The host then asserts ACK (acknowledge). The controller deasserts REQ. Once this is done, the host interface deasserts ACK. This repeats until all bytes are transferred. In general, 6 bytes are transfered for each command (from host to controller) and 256 bytes of data are transfer. My host inteface consists of 5 IC's and 32 resistors (for passive termination of the SASI bus). The IC's are: MC 6821 Parallel Interface Adapter (PIA) 74133 13 input NAND gate for address select 7404 for address select 74245(?) Octal bus transciever to drive SASI data bus 7407 Hex noninverting driver for SASI ACK, RST and SEL The two ports of the PIA talk to the SASI data and control bus. Unfortunately, the 6821 doesn't have the drive capacity to pull down the SASI bus with the termination resistors, so I needed the 74245 to drive the SASI data bus. The I/O line from the SASI bus controls the direction of the 74245. The address at which the host interface resides is $ff7c-$ff7f. This amounts to sending all address lines from A3 to A15 except A7 into 74133. A7 is inverted (by 7404) and fed to 74133. A2 goes directly to PIA as one of the enable lines and A0 and A1 are used as register selects on 6821. Note that this address range resides in the reserved memory area of the SAM, but so it goes, since RS didn't completely decode the address for its disk controller. Software: Since you cannot assert the interrupt line from the cartidge, all hard disk software runs by waiting for the controller to complete execution. The init routine resets the PIA and the controller, and homes the head of the disk (by issuing a Recalibrate command to the disk). It also initializes a disk busy (mutual exclusion) semaphore to not busy. That's all, folks. Getstat and Putstat simply return. No provisions have been made to format the disk (mine was already formatted). If your disk is not yet formatted, you will need to do so on the proper Putstat call. Term simply issues the Recalibrate command. Read and Write do all of the work and their functioning is similar. Both wait for the disk to be not busy. This is done by testing the semaphore. If the semaphore is clear, the disk is not busy. If so, the semaphore is incremented. Otherwise, the device driver waits until the next clock tick to test the semaphore. Once to disk is not busy, the disk is selected, a command is issued, data is transfered, and the status is inquired. Finally, the busy semaphore is decremented. Rather than loop for the controller to complete certain portions of the command cycle, waits are issued. This is done in two places. In the read command, a wait is issued after the command is sent and before the data is read. In the write command, a wait is issued after the data is written and the status is requested. If you could interrupt the CoCo, this would be the appropriate place for these interrupts; but you can't (or at least not with IRQ). Conclusions: The host interface is about the simplest piece of hardware which you can build that does anything useful. It can be built to do the REQ/ACK hand-shaking for you with a 7474 flip-flop, making your software simpler. However, feeling more comfortable with software than with hardware, I chose to simplify the hardware rather than the software. Adding a handshake flip flop complicates the hardware. The major problem which I emcountered was the documentation which Radio Shack provides with OS/9. The technical information manual is rife with errors and omissions. The worst of these was the fact you need an access code in your device driver as well as your device descriptor, a fact which was never mentioned. Without this access code, you will never be able to read or write the disk. Another error in the documentation is the mention of a sectors per cluster factor. It turns out that Microware V1.2 (and hence RS V1.00) ignore this factor and always set the cluster size to one sector. The software simply ignores this value. You put any value you want there (although you are safest with a value of 1). Another word of advice: when reading track 0, sector 0, don't forget to place that data into the drive table. This omission caused problems for me (my fault; RS mentions that you need to do this). I haven't extensively tested my device driver, but so far it seems to work just fine. I have copied all of my OS/9 distribution disk to the hard disk. I have also made a new boot disk which includes the new device driver and descriptor with the OS9GEN utility. The FORMAT utility works just fine on the hard disk (all it does for me is verify disk integrity and initialize the sectors to contain the correct data). Happy hacking, Dan McCabe decvax!microsof!danm P.S Please excuse any typo's. I haven't done any typing in the last week (vacation), so I am a bit rusty. Legal stuff: Radio Shack and Color computer are probably trademarks of Tandy Corp. Centronics is probably a trademark of Centronics Corp. SASI (SCSI) may or may not be a trademark of Shugart Corp. OS/9 is probably a trademark of Microware Corp.