becker@uhccux.uhcc.Hawaii.Edu (Ralph Becker-Szendy) (07/31/90)
Hi folks I am beginning to build a SCSI adaptor for my homebrew 8-bit Z80 cp/m system, and I would like the network wisdom to tell me about mistakes in the design, point out pitfalls to stay clear of, suggest improvements, and flame me for my ignorance. Design and purpose: SCSI interface (using a "smart" controller chip), connected to the system bus (with a few TTL glue chips). Controls (for now) only one disk drive. I might add a second disk drive and a cheap streamer tape drive later on; maybe even a floppy controller (to get rid of the other floppy controller). Both the hardware and the device drivers will be kept as simple as possible (at least for the time being), performance will be sacrificed for ease of implementation. For the drive, I am restricted to 3.5" drives (for space and therefore cost reasons); also they are handy, usually quiet and low in power consumption. I don't think I take a large cost penalty in not using 5.25" drives. I have already ordered a refurbished Rodime 3057s drive (45MB formatted), for $215. Anyone know any awful ideosyncrasies of these Rodime drives? Soon I will add a bigger drive (maybe replacing the Rodime), for example a Conner CP3100 or 3200. The reasons for choosing Conner is that they are (1) reasonably cheap, (2) quiet, (3) reliable (according to what I hear in this newsgroup). One question: The Conner drive has 64kB buffer memory. Is that a real cache (with a reasonable block replacement strategy) or just a track lookahead buffer (the documentation isn't clear on that)? If I can find drives with a real cache (where recently used blocks stay in the cache longer) I don't have to add an extra cache of my own. Reason for the cache worries: cp/m reads the disk directory ALL THE TIME (for every extent of every file), and reads the boot track once per image activation. Having to step the heads back and forth for these operations all the time makes the system a lot slower. And I am spoiled by having a floppy controller with 128kB cache. While we are at it, what would you suggest for a cheap SCSI streamer tape drives for disk backup? Cost and ease of use is the foremost concern, compatibility with any other computer is not an issue (or do you know a Sun out there which runs cp/m?) Next, the controller. For the time being I have settled on using the Western Digital WD33C93A chip. Reason: It is pretty smart and easy to interface; the select-and-transfer commands can save me a lot of software work. Also, I got one of the chips sitting in my office (and is bloody hard to get any distributor to sell a $20 chip in quantities of one or two !). Are there any caveats about the WD chip (I have Western Digitals bug list)? Or would anyone like to suggest that there is a chip which does the job much better (i.e. simpler to use, not necessarily faster). If you suggest another controller chip, it would be very kind to point out where it is available IN SMALL QUANTITIES. For now the controller will be directly interfaced to the system (Z80) bus; I will not even use the interrupt capability (since it is hard to adapt an interrupt to the Z80 vector interrupt structure). On the SCSI side I will not use disconnect/reconnect, nor parity (does that get me in trouble with the disk drives?). Only logical unit 0 will be used. On a single-tasking computer with a single SCSI disk drive there is no need for an interrupt driven device disk driver, nor to ever disconnect from one periphereal and deal with another IO request. I will take a big hit in performance by having to transfer all the data in a polling loop, until ... Later on I will add an interrupt controller (probably using a Z80CTC for that), a DMA controller (Z80DMA), and a LOT of local memory (in the few megabyte range). The local memory will be used as a disk cache; it gets me the speed of a RAM disk (at least when reading, which is most of the time) without having to worry about managing a separate disk. The WD chip has the nice feature of being able to assume some kind of bus master role and store blocks directly into memory (I have to provide the addresses, no problem). If the cost of 1MBit static RAMs comes down, I can implement the cache using them (for example 8x 128kx8 bits, or 1MB). The ideal solution would be dynamic RAM (in space-saving SIMMs); but then I would need a DRAM controller which can make the RAMs be pseudo-static. I know of no DRAM controller for 1MBit RAMs which can do that (i.e. it has to handle the refresh and all timing generation all by itself, so the user sees only static memory, with a -WAIT or SYNC line to block memory access while a refresh is in progress). Texas makes a gadget like that for 256kbit memories, but not for 1MBit ones. Any suggestions on a DRAM controller chip which can do that for 1MB RAM chips? Doing it by hand with TTLs would be murder. Some stupid hardware questions: I know that you shall terminate the SCSI lines with 220Ohm to +5V and with 330Ohm to ground. No problem, for 18 SCSI lines that takes me six SIL resistor packs of 8 resistors each. Question: Does anyone know whether resistor packs which integrate the pull-up and pull-down are available (and if yes, where)? For example, a 12-pin single-in-line with 10 data bus connections, a +5V and a ground line; that would save a lot of space (and prevent me from terminating the wrong way round). Second, I have checked the SCSI-2 specs to find out about the reset line (-RST). As far as I can tell it is never needed during data transfers. So, could I just drive it from the CPU power-on reset with an open collector driver? Or can I even leave it disconnected (but terminated)? Will SCSI disks ever need the RST signal? Lastly, the software. Here the problem is (a) I am lazy, and (b) memory is extremely tight in a 64kByte cp/m system. Fortunately (b) is a good excuse for (a). As described above, there will be no disconnect/reconnect and no parity (at least for now). Error handling will be very simple: In case of any error (whether it is a SCSI protocol error, like unexpected phase, or a device error) as much information as possible is printed on the screen, a REQUEST SENSE command will be issued and the result printed on the screen, and the user is asked whether he wants to (a) retry the whole command, (b) reboot the operating system, that is stop the running program, or (c) ignore the error (the usual RETRY, ABORT, IGNORE thing). Here is the plan: The EPROM system monitor (which comes on after a reset, and has no tight memory limitations since the OS is not runnign yet) will issue INQUIRY commands too all 7 SCSI devices. For each device which responds and identifies itself as a disk, it will issue a START UNIT command (with no wait, so that might take some time). It will then do a READ CAPACITY. Now comes a little problem: I have to partition the disk (even if cp/m could handle a 200MB disk, which it does with a new BDOS, I wouldn't want that). I plan to store the partitioning information in the last disk block; like that the capacity of the disk is just reduced by 512 bytes. Is there any standard way of storing partitioning information? Given the drive size (total # of blocks) and the partitioning table the monitor can now build the drive parameter tables in memory, and is done. The disk driver in the OS (more accurately in the BIOS) will be extremely simple, to save on memory. Error "handling" or the lack thereof is already described above. The driver only knows two commands: READ and WRITE (not even the extended or long versions) of these. To make life easier, I will pretend that these drives have tracks with 256 sectors of 512 bytes each, and I will make the partitions begin on "track" boundaries (that is, on a multiple of 256 blocks). Like that the logical block address can be calculated very easily from the sector number, the "track" number, and the "track" offset for this partition. At least one partition will have a system "track"; that system "track" will be 128kB (and therefore over 20 times too long, but so what). For the time being I will format all disks with 512 byte sectors (that seems to be their favorite format anyhow, at least as far as Rodime and Conner are concerned). Speaking about formatting, that will have to be done outside the OS device drivers and the monitor program. Probably I will write a seperate program (easiest in a high-level language like Modula-2) which grabs control of the SCSI interface, issues the simplest formatting command (no extra gymnastics with MODE SELECT, funny formats or defect handling), reads the capacity back, stores the partitioning table in the last block, and then fills all other sectors with E5 (so cp/m knows the directory is blank). Any hints are welcome ... Ralph Becker-Szendy UHHEPG=24742::RALPH (HEPNet,SPAN) University of Hawaii RALPH@UHHEPG.PHYS.HAWAII.EDU High Energy Physics Group RALPH@UHHEPG.BITNET Watanabe Hall #203, 2505 Correa Road, Honolulu, HI 96822 (808)956-2931