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
