The biggest problem with SASI vs SCSI is that from almost the gitgo
SCSI required select plus atn (attention) to be applied and that messages
be handled.
The only message in SASI is the status at the end of the data phase, and
it comes in whether atn is there or not.
The main thing you should look for in SASI is that it can control whether
ATN is applied on select, usually you will need to control this in the SASI
initiator software you use for the driver.
The other feature that most controllers will have that will wipe you out
(potentially) is that they will read and handle message phases automatically,
and do something you dont want them to.
Disconnects are not allowed in SASI, and a lot of controllers would disconnect
and piss off the SASI target engines.
I still see a lot of gate implemented SASI adapters in bins for a $1 or two,
but
you would have to reverse engineer them. Also almost all SASI devices were
supported in the dark ages pre open source, when everything was a trade
secret and proprietary, with manuals super hard to get.
Most companies mystified me by treating their engineering manuals as defense
grade secrets. What possible justification does one have for not publishing
how to interface to your product? Then or now. The stupidity of marketing
"technical" departments astound me with this crap.
</rant off>
Hope this helps.
Jim
Tony Duell wrote:
Has anyone here successfully interfaced a SASI device to a PC at the
hardware level?
I've got a few classic systems which use SASI (or not-quite-SCSI)
controllers to talk to SASI-ST506 bridge boards and from there to ST506
type drives.
I was under the impression that SASI was sufficiently close to SCSI that
a SCSI interface could talk to a SASI device given the right software. It
would probably make things simpler if the SASI device and the controller
were the only things on the bus.