The origin of SCSI [WAS:RE: The origin of the phrases ATA and IDE ]

jim stephens jwsmail at jwsss.com
Thu Oct 5 15:08:59 CDT 2017



On 10/5/2017 11:50 AM, Chuck Guzis via cctalk wrote:
> On 10/05/2017 11:18 AM, Tom Gardner via cctalk wrote:
>> I suspect this might start another discussion, but as I understand it Apple had little to do with the evolution of SASI into SCSI.
>> Shugart Associates published SASI in 1981 and took it to ANSI in 1982 where they renamed it SCSI to avoid using a vendors name.
> You could well be right--I do recall that there was "Mac SCSI" and then
> the slightly different "Everyone else's SCSI".  I ran into this when
> talking with some SMS/OMTI engineers about an ST506-to-SCSI bridge board
> that I have.  Their reaction was "Oh, that's Mac SCSI--you want real SCSI".
John Henry, the founder was an interesting fellow.  "One More Time, Inc".
> What I found curious was the CDC manual that called SCSI "SASI subset".
> To me that says that SASI was the more elaborate protocol and SCSI
> initially picked and chose from it.
There was a subset of commands taken from the Adaptec specification for 
SASI which was share with
the initial committee.  But the SASI suffered from a number of 
deficiencies in how it was defined and
implemented.

The objectives were twofold.

Put the large footprint of logic and function in the device(s).  The 
objective was to implement what could
be done in the devices to make the initiator end of the interface as 
simple as possible.  (This is the end
connecting to systems).

The SASI initially as was SCSI transfer protocol was interlocked. The 
transfer was limited to low transfer
rates as every transfer had to wait for the receiving end to acknowledge 
the receipt of the transfer.

Who was interested:

The problem that existed at the time was that transmission of data at 
that time had hit a technical wall.
SMD was the dominant technology, and the increase of the transfer rate 
made it difficult to impossible
to do the logic to transfer the data, and also do the error checking / 
correcting logic with existing logic.

We had a disk controller, for example that used a TTL CRC chip.  The 
higher transfer rate CDC drives
outran that.  Also the existing choices for ECC were not fast enough 
eiither.

So the drive companies with the existing market, CDC and the like were 
casting about for a byte bus
structure that they could dominate and move to.  Unfortunately it didn't 
work out that way for CDC as
they could not play the games they had with SMD, and though the 
supported the early SCSI work,
Emulex and LSI Logic (NCR) actually did a lot of the work.  Emulex saw 
SCSI as a dominate or die technology
area, and NCR saw it as an opportunity for their semiconductor 
business.  Emulex also had silicon, but
the NCR / LSI logic company was actually far better at selling OEM for 
that purpose.

At the system level, Sun was an early adopter, and supporter.  Their 
silicon was NCR and LSI logic
supplied.

Of course Adaptec supported SCSI from the gitgo as well, as they had 
invented the protocol.

I worked with the committee from the first meetings on.  Larry Bouchet, 
who invented SASI and was
committed to making it a standard.   At the time plugging into systems 
was seen as still a viable business.

The other things going on at the time, was the rise of 5 1/4" 
winchesters.  There were a few companies
who had made a commodity business out of making adapters, and quickly 
put out SASI then SCSI
controllers.  They had an interest in making sure that such as CDC 
didn't integrate the controllers
into their products.  At the time for a period that was something that 
they got away with.  Eventually
all of the companies either were bought out or went on to disk drives 
(WD was boards, bought out
Tandon and jumped over to drives in a painful transition).  OMTI, not 
sure where they went, but they
had no other business but boards.  And another giant, XEBEC moved to 
disk controller for the PC.

in one of my cabinets I've got a lot of the documents from the beginning 
if it survived my moves.

My company, Irvine Computer was supported by CDC to make a SASI and 
later a SCSI compatable
controller for the CDC quarter inch tape, the Sentinel.  I assisted CDC 
people @ MPI to make
the Sentinel have proper function in tape operations, as well as such as 
the EOT handling. The
device truly isn't a QIC write only memory.  The tape cartridge design 
with the rubber band
notwithstanding for archival purposes, you could use them for a 
reasonable period back then
and get your data back.  Also insisted they allow proceeding after errors.

While on the committee, the folks at a large company which was based in 
Oceanside, starting with A
who were making write only QIC drives came into the mix about a year 
in.  They and the disk
drive controller folks had no interest in having a useful device defined 
for the tape.  It took some
fairly contentious meetings to present how tape was supposed to work as 
well as how it could
work over the SCSI protocol as a serial device to get a reasonable 
definition into the standard.

Were it not for this fuss, you would have had a tape command "BACKUP" 
and "RESTORE" and that
would have been it.

Apple didn't enter into the mix until the SCSI had gone thru enough 
revisions to actually be useful.  It
was one of those pioneers take it in the b**t problems, and Emulex, our 
company, CDC and a couple
of our customers went with early definitions, which had to have nearly 
total rewrites to track
changes to the standard.  SCSI was truly designed by the work of the 
participants in the committee,
and would have been unworkable without that.  (cue camel jokes).


> I do know that many SASI devices work as SCSI-1 devices.  Somewhere, I
> still have an early PC ISA SASI (not SCSI) adapter for an Ampex
> Megastore unit.
Only if the system is able to run without the devices supporting ATN and 
disconnect.  That was the thing that usually broke things badly.
> I'm also well-acquainted with what Andy Johnson-Laird called "SCSI
> Voodoo" in trying to get several different SCSI devices to work off the
> same SCSI-2 bus.
I worked for Peer Protocols, and we had a development reference system 
used by most people to get into SCSI compliance and function.

The biggest problem you had was the requirement to assert ATN when 
selected properly.  Later the tag queuing caused huge headaches as 
manufacturers implemented that feature.

It eventually was made mandatory for the most part by linux, and perhaps 
Windows requiring the tag queuing drilled own to the lowest level of the 
system's use of the disk.  The capability to do that, or fake it is 
required to allow the kernel to queue commands to run, and have the OS 
continue to run till command completion.

thanks
jim
> --Chuck
>
>



More information about the cctech mailing list