AARDVARK@ENI.Prime.COM (11/28/89)
I have an old 32016 development system which has the *old* 20 Mb disks with the no-longer-supported-by-anyone (and for good reason :-) X3.101 interface (pre-scsi). Does anyone know whether there exists an I/O board that supports SCSI (and appropriate drivers)? Don Koch Internet mail: aardvark@primerd.prime.com Disclaimer: The above reflects only my views and not those of my employer.
john@starfire.UUCP (John Lind) (11/30/89)
In article <51900003@ENI.Prime.COM>, AARDVARK@ENI.Prime.COM writes: > I have an old 32016 development system which has the *old* 20 Mb disks > with the no-longer-supported-by-anyone (and for good reason :-) X3.101 > interface (pre-scsi). Does anyone know whether there exists an I/O > board that supports SCSI (and appropriate drivers)? Well, I am assuming that your development system is a MultiBus (I) system, since you didn't actually say. Several people make MBI SCSI HBAs, but the only one I have experience with is the Rimfire 1500 from Ciprico. This may be more board (and more money) than you want. The PC board is pretty full, because this is a full-featured controller. It uses a custom Short Burst Fifo chip, custom Bus Controller chip (for the host bus), and a fast third-party SCSI state-machine bus interface chip, and an i80186 for the on-board processor. This baby clips right along. It has a single-command mode, but the usual mode of operation is through a command list in the host memory. The driver interprets IO requests into commands in the command list, bumps the pointers, and tells the board to check the queues. That's all you have to do until the command is completed. The controller uses a "pass-through" scheme for a number of reasons -- the command consists of a header of information that is just for the controller to use (memory address and such useful things), followed by the SCSI CDB (Command Data Block) pretty much as it will be sent out on the SCSI bus. The board is available with or without a floppy disk interface. Floppies are handled through the command list as if they were SCSI devices -- you use a psuedo-SCSI target ID of FE (SCSI target IDs are 0-7, so this is safely out of range). The board is available in single-ended or differential configuration (very few differential peripherals exist, however), and a SCSI-II version is under development to do SCSI FAST and SCSI WIDE. The orignal controller supports mixed synchronous and asynchronous devices at very high transfer rates, disconnect/reselect, and pretty much anything else you would expect from a high-performance SCSI HBA. I own a Ciprico Tapemaster 1000 and a Rimfire 1400, and can speak for them as well-built products. They are serving starfire quite well. I do not myself own a Rimfire 1500, but am currently under contract with Ciprico to do some custom firmware changes for one of their customers. So, a dis-disclaimer. I do work under contract for Ciprico, and have been an employee of theirs. I have many friends there, but none of them nor I will directly benefit from the sale of a controller. In fact, you won't be able to buy one from them directly, since they don't do retail sales. However, if you give them a call at 612-559-2034, they will be able to put you in contact with the distributor/sales rep for your area. Please let me know if you follow up on this -- I would love to get your opinion of the controller. -- John Lind, Starfire Consulting Services E-mail: john@starfire.MN.ORG USnail: PO Box 13001, Mpls MN 55414
john@starfire.UUCP (John Lind) (11/30/89)
Argh! Concerning the Ciprico Rimfire 1500, I forgot a very important feature -- it supports Scatter-write/Gather-read for all you folks with a paged memory scheme. You don't need to use a bounce buffer for this guy -- just give him the list of starting addresses and lengths for the physical memory fragments of the buffer, and it will go to it. For Unix users, this is only important for the raw (character) device interface, but if you are using your SCSI bus for tape, this is very important indeed -- things like tar and dd run much better if you don't have to bounce the data through a contiguous memory buffer, and who wants to wasted 32-126K of memory, anyway? -- John Lind, Starfire Consulting Services E-mail: john@starfire.MN.ORG USnail: PO Box 13001, Mpls MN 55414