Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!know!tegra!vail From: vail@tegra.COM (Johnathan Vail) Newsgroups: sci.electronics Subject: Re: SASI = SCSI? Message-ID: <2034@atlas.tegra.COM> Date: 6 Feb 91 21:57:25 GMT References: <86715@unix.cis.pitt.edu> <1991Feb2.222821.12163@zoo.toronto.edu> Organization: Tegra-Varityper, Inc., Billerica, MA Lines: 40 In-reply-to: abeals@autodesk.com's message of 4 Feb 91 18:13:50 GMT In article abeals@autodesk.com (Segments Are For Worms) writes: henry@zoo.toronto.edu (Henry Spencer) writes: >In article <86715@unix.cis.pitt.edu> kwgst@unix.cis.pitt.edu (Filip Gieszczykiewicz) writes: >> Now, someone told me that the SASI interface is a relative >> of SCSI. >SASI is SCSI's grizzled old ancestor. They are nominally still interoperable, >last I heard. Uh, not really. In SASI-land, all you had to do in order to access the remote device was to assert its SASI ID during the selection phase. In SCSI-land, you need to assert both the controller's SCSI ID and the remote device's SCSI ID on the bus during the selection phase. There are lots of reasons why SCSI!=SASI and although what you say is true it may not hinder interoperation. An example of this is the OMTI SCSI controller which will work fine without the initiator's ID line asserted during selection phase. This is a case of a SASI interface working with a SCSI device. As long as you stick with a small subset of SCSI commands and don't do anything fancy with arbritration or disconnect/reselect this has a good chance of working. I would think that it would be much less likely that the opposite, as descibed in the original posting, would stand a chance of working. jv "theobromine: a compound which, contrary to it's name, contains neither bromine nor God" -- David Throop _____ | | Johnathan Vail | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail