From SASI to SCSI: Standardizing the Peripheral Bus

The Small Computer System Interface, or SCSI, helped computers communicate with a wide range of storage and peripheral devices through a shared command model. The name is commonly pronounced “scuzzy,” but the more important idea is that the host did not need to understand every device’s low-level mechanics. A host adapter could issue standardized commands to a target, and a disk, tape drive, scanner, or other peripheral could define how it responded. SCSI became influential because it treated external devices as intelligent participants on an interface rather than as passive extensions of one computer’s internal bus.

SCSI’s history is often compressed to “a faster disk cable.” That misses its layered design and standards process. The system had electrical and physical signaling, bus arbitration, device identification, command sets, and rules for detecting and recovering from errors. Those parts evolved separately. Later SCSI versions expanded both the protocol and the physical interface, so a statement about “SCSI” can refer to different generations with different widths, speeds, connectors, and capabilities.

The problem with disk-specific interfaces

Early computer storage interfaces were often closely tied to a drive’s controller and the host system. As disks became available from multiple vendors, system makers needed a way to connect drives without designing a wholly new host interface for each model. Shugart Associates developed the Shugart Associates System Interface (SASI) in the late 1970s as a way to standardize communication between a host and storage peripherals. Computer History Museum’s storage history traces this line from SASI to the SCSI name and later standards work.

SASI reflected a changing division of labor. The drive or controller handled details such as positioning, while the host issued higher-level operations. A standard command boundary could let an operating system request a read or inquiry without knowing the drive’s internal mechanism. That shifted some complexity into intelligent controllers and defined a common language between host software and peripherals.

In the early 1980s, an ANSI standards effort began turning the interface into a formal industry standard. T10’s archive identifies ANSI X3.131-1986 as the original SCSI standard and explains that it was later superseded by SCSI-2. The timing is important: SASI was a precursor and practical influence, but the standardized SCSI specification was a product of a committee process that had to reconcile vendor proposals and define a broader interoperability contract.

A bus with initiators and targets

In classic parallel SCSI, the host adapter acted as an initiator and a peripheral controller as a target. The initiator selected a target and sent a command; the target returned status and, where applicable, data. A logical unit number (LUN) identified a logical device behind a target. A single physical enclosure or controller could therefore present multiple logical units, although the way products used LUNs varied.

This is different from a modern point-to-point link where each endpoint has a dedicated connection. A parallel SCSI bus was shared: devices connected to the same electrical bus and used arbitration to obtain the right to communicate. Each device had an identifier, and the bus needed appropriate termination at the ends to limit signal reflections. Incorrect termination, mismatched signaling, duplicate IDs, cable problems, or incompatible bus modes could prevent the system from discovering a device even when the drive itself worked.

SCSI also allowed some targets to disconnect while performing a long operation and later reconnect when ready to transfer more data. That capability helped a host avoid tying up a bus during a mechanical seek or tape operation. Queueing and concurrency support became more sophisticated in later generations. These mechanisms illustrate why SCSI’s design cannot be reduced to a cable’s transfer rate: bus protocol rules and command behavior were equally important.

Commands were the portable contract

The SCSI command set defined operations and data structures that a host could use to communicate with devices. Commands such as inquiry, read, write, and request sense gave operating systems a common way to discover devices, access blocks, and inspect error conditions. The exact command sets and command lengths varied across device classes and standards generations. A disk-specific command was not necessarily meaningful to a tape drive or scanner.

The command model did not remove all incompatibilities. Vendors could implement optional commands, vendor-specific extensions, or different feature sets. A device might be electrically compatible with the bus but lack the command an operating system expected. Device-class standards and later common command-set work helped expand interoperability, but software still needed to interpret inquiry data and handle failures carefully.

The architecture thus separated several questions that are often conflated: Can the electrical interface carry signals? Can the devices share the bus correctly? Does the target respond to the required command? Does the operating system’s driver understand the response? Does the application support that class of peripheral? “SCSI compatible” answered only some of these questions.

SCSI-1, SCSI-2, and the growth of scope

The original SCSI-1 standard, ANSI X3.131-1986, formalized a parallel interface and a command protocol. T10’s archived committee materials identify it as the original standard. SCSI-2 later refined the command set and broadened device support. T10’s historical archive includes the final SCSI-2 committee draft and describes its project and designation; the official ANSI publications are separate from those archival working documents.

The 1986 federal FIPS publication reproducing the ANSI X3.131-1986 text is a particularly useful public archival source for the original standard’s technical scope. It documents device types and interface requirements as they existed at that time. It should not be treated as a specification for every later SCSI product. A SCSI-2 or SCSI-3-era disk could support features and physical interfaces absent from SCSI-1.

Later extensions introduced wider data paths, faster transfers, different connectors, and additional command sets. The phrase “SCSI-3” also came to describe a family of standards rather than one monolithic specification. T10’s modern scope includes many SCSI command standards while other organizations manage related transport layers such as Fibre Channel or USB. The term therefore identifies an evolving architecture and family, not one specific cable or speed.

Host adapters and the operating system

The host adapter bridged a computer’s internal bus and the external SCSI bus. It provided electrical signaling, arbitration, and command transfer. The operating system’s host-adapter driver then exposed devices through higher-level storage or peripheral APIs. This separation allowed an operating system to support a variety of adapters and peripherals without encoding every board’s hardware behavior into every application.

The adapter was not merely a plug converter. It could contain firmware, manage DMA, handle bus phases, and provide device discovery and error reporting. Its capabilities affected which SCSI modes were usable. A newer drive connected to an older adapter might operate at a slower shared mode, or not at all if signaling and command expectations were incompatible. Conversely, a high-performance adapter could not make an older target support commands it did not implement.

SCSI’s flexible peripheral model made it attractive in workstations, servers, and professional systems where users might connect disks, tape drives, optical devices, or scanners. It also carried configuration costs. Each device needed an ID, buses needed termination, cable limits mattered, and systems often required driver or firmware support. The same flexibility that made SCSI powerful also made it more demanding than a simple internal drive connection.

Reliability and errors were part of the interface

Storage communication has to represent more than successful reads and writes. A target can be busy, become ready later, detect a medium error, report an illegal command, or return sense data that explains why an operation failed. Request-sense behavior and status values let a host distinguish conditions rather than treat every failure as a generic I/O error.

This mattered operationally. A tape drive might need time to rewind or load media; a disk could report a recoverable read problem; a removable-media device could be present without a readable medium. The command protocol allowed the host to query and react to those states. A hardware connection alone did not imply that the peripheral was ready for an application request.

The bus itself introduced failure modes. Termination and cabling affected signal quality, and simultaneous devices needed unique identifiers. Troubleshooting a SCSI system therefore involved inspecting the physical chain, IDs, adapter settings, firmware, command support, and operating-system logs. This layered diagnosis is a direct consequence of the design’s separation between transport and device behavior.

Why SCSI mattered to system builders

SCSI offered computer manufacturers a way to support a broad peripheral ecosystem without owning every device design. Peripheral makers could target a documented interface, and operating-system vendors could implement common drivers. A system integrator could choose storage capacity, tape backup, and specialized devices according to the workload. This decoupling helped professional workstations and servers adopt peripherals from multiple suppliers.

SCSI also encouraged a different model from the tightly integrated PC disk interface. Many SCSI systems treated devices as external, addressable targets. The same disk model could be connected to different hosts, and one bus could serve multiple targets. That did not guarantee universal plug-and-play, but it made interoperability an explicit product goal.

As storage requirements changed, SCSI’s standards family expanded and diversified. Parallel SCSI gave way in many markets to serial transports, while SCSI commands continued over transports such as Fibre Channel and USB Attached SCSI. The command architecture outlived the original cable. This is an important historical distinction: a technology can preserve its logical protocol while changing its physical transport.

A careful SCSI vocabulary

An account of SCSI should say which generation and layer it means. SCSI-1 refers to the 1986 ANSI standard. Parallel SCSI describes the traditional shared bus. SPI standards describe a parallel physical interface. SCSI command sets define device operations. Later serial transports may carry SCSI commands without using a classic parallel bus at all. Treating these as synonyms leads to inaccurate claims about connectors, speed, or device counts.

The same care applies to the relationship between SASI and SCSI. SASI influenced the standardization path, but SCSI became an ANSI standard through a broader technical committee. It is inaccurate to say that one company simply published a finished SCSI standard and the industry adopted it unchanged. The archive records a progression from proposals and drafts to approved standards and later revisions.

The legacy of an intelligent peripheral interface

SCSI’s lasting contribution was a common command-oriented boundary between a host and diverse devices. It defined how initiators selected targets, how commands were conveyed, how data and status returned, and how systems could handle errors. The architecture left room for new device classes and transport implementations, but that openness required careful standards evolution and operating-system support.

The history also shows why standards work must account for both physical and logical layers. A cable and signaling specification cannot make two peripherals agree on a command; a command document cannot compensate for an electrically invalid bus. SCSI brought these pieces into a family of specifications and made peripheral interoperability a system-level goal. Its modern descendants may no longer use the familiar parallel connector, but the command boundary remains an influential piece of storage history.

Related:

Sources: