Palo Alto in 1990 was great for a young family (except for the $1300 per month price tag on our two bedroom apartment--$3900 today!). On Friday evenings, Betsy and I would walk little Charlie down University Avenue to The Good Earth restaurant, where I could have a burger and Betsy could sample that day’s healthy special and sip tea.
On the same street was the Stanford Theater, a beautiful movie palace with Persian flair. The David and Lucile Packard Foundation restored the building to its original splendor in 1989, only a year before I started working at Adaptive. They only screened classic films, often showcasing a specific director, and David Woodley Packard would often show up to introduce special screenings personally.
Adaptive, where I worked at the time, was close by. At lunch, I’d jump in my White ‘89 Honda Civic and head down the 101 to meet Betsy at our apartment. Most mornings she would push Charlie’s stroller down to the grocery store and pick up fresh vegetables and pasta for the day.
“What are you working on today?” she asked while we ate one afternoon. Six-month-old Charlie was not much good for conversation, so Betsy jumped at the chance to talk to an adult every chance she got.
“Well,” I said, excited to share my love of technology with the love of my life, “I’m starting on the SCSI drive.”
Disk drivers weren’t new to me, and it wasn’t the first time I’d used the SCSI bus. While working for Digital Transmission Systems back in Georgia, I learned the intricacies of SASI, the Shugart Associates Systems Interface and brainchild of Larry Boucher. By the time I emailed Larry with questions, SASI had been through standards wringer and come out the other side as SCSI. Larry hoped it would be pronounced “SEXY.” We win some; we lose some.
It took an entire board to drive the SCSI bus at Digital Transmission Systems. The processes I used to choose that particular card were typical of how I operated: all the vendors sent me manuals, I sorted them by thickness and started reading the thinnest, rejecting those that were too simplistic and stopping my search at the first one that met my requirements. Writing good code is easier for uncomplicated hardware.
Ever curious, I’d glance through the other manuals to see what made them so large. Usually it boiled down to muddled thinking which resulted in a mish-mash of first flush hardware designed that poked through the interface. It was a stretch to call some of them designs, really. Flipping through the lengthy manuals, they seemed to be accidents caused by too little funding, time, and thought.
The worst offenders were over-engineered messes rooted in the misguided impression that their creators knew what programmers would want. It was clear they hadn’t talked to one. As Steve Blank wrote, “There are no facts inside the building.”
Luckily, I didn’t have to go through this manual rigmarole for the 1990 port at Adaptive because of the Western Digital 33c93 integrated circuit. It was a beautiful thing. To truly appreciate it, we have to look to the SCSI protocol itself.
SCSI made the world simpler by acknowledging the benefits of Moore’s Law in relation to disk drives. Disks were originally pretty dull devices. They’d have a little digital logic to set the direction of the head spinner and the like. Data signals were analog and raw. In the 70s, interfaces like Storage Module Drive used a clock bit for each data bit, which would have to be separated. Other disk interfaces used a separate clock signal derived from a service dedicated to clocking. Either way, this required a lot of work on the controller to drive the physical disk transport.
All this work meant the early IBM controllers were the size of refrigerators. Then, minicomputers used multiple boards to create the I/O bus and disk controller. By the mid-80s silicon was cheap enough to put the controllers on the drive.
Where the previous controllers used low-level signals, SCSI allowed high-level commands to be sent to the drive. The command traveled on a 50-pin ribbon cable containing 19 data and control signals. Eight data signals carried read and write data as well as bus arbitration. The limit of eight meant there could only be eight things on the bus, including the controller.
The cable went through different phases to accomplish I/O. An arbitration phase was a chance for any device to ask for the bus. Each device had a SCSI ID, from zero to seven. It would raise its hand by asserting the data signal that corresponded to its ID. Device seven, usually the host bus adaptor, would assert D7. The first disk was usually ID 0 and would assert D0. The highest numbered data line won. Everyone stayed on the same page because all the devices could see all the data pins.
The next phase was device selection. Now that a device has temporary ownership of the bus, they need to declare which other devices they want to talk to. The selection is like the previous arbitration phase where a single data line served as the device number selected.
Then there is the command phase. The Command Descriptor Block (CDB) is sent over the data bus with the I/O parameters and a command such as READ, WRITE, UNIT READY and so on. Once the CDB has been transferred, the bus switches to the data phase, with the initiator sending the WRITE data or the selected target sending the READ data back to the initiator.
There are some more phases to pick up sense data, but you get the idea.
The best thing about the Western Digital 33c93 integrated circuit was that it did just enough of the work without doing too much, all while hiding what was going on. It took care of the phases to carry out a complete transaction, and when something went wrong, it threw up its hands and let me deal with the resulting mess.
I figured out how to boot from a tape, make the file system, and how to make a restore dump program. These programs were standalone; they didn’t have a kernel running under them. Instead, they had some code linked in that handled the open, read, write, etc.
The standalone code that replaced the kernel used a different device name format, one that specified devices and tape file numbers. For example, st(4, 3) meant open SCSI ID 4 as a tape and read the fourth file on the tape, 0 being the first. The disk was sd(0, 0) for SCSI ID 0, first partition on the disk.
The make file system program would prompt to open a device on which to create the data structures for the system. This would be “sd(0,0)” for root.
Since there wasn’t a full kernel, the device drivers had to be a bit different. The standalone code had its own drivers that avoided all the facilities that were not provided by the standalone code. The version of the SCSI driver for the WD33C93, for example, used the status registers in the chip to know when the I/O operation was complete. This wasn’t fast, but the install didn’t need to be. It just needed to be small and simple.
So the first version of the SCSI driver and the serial console driver were status driven, not interrupt driven, to allow us to get the beginnings of a file system installed on the MVME147 disk.
That version of the WD33C93 driver was only 166 lines of C.
Both versions of the SCSI driver, the smaller standalone one, and the faster full Unix kernel one, only sent I/O messages to targets. Other code in the system used those drivers to get the full jobs done. Tape.c provided functionality for the QIC tapes, and sd.c provided a Unix driver for the disk drives. This separation of functions is one of the reasons the code could be so small. There’s complexity in combination.
Early SCSI was a simple protocol, we only used three SCSI commands, and the Western Digital chip was a very well designed interface.
By the time I finished explaining this, I realized that Betsy’s eyes had glazed over and that it was time for me to head back to the office.
It’s because of Betsy’s patience that I learned to engage people in conversation about my work rather than blast them with an enthusiastic, often jargon-filled lecture. It took many years, but I got better at describing, listening, and answering questions. She’s remained my best friend every step of the way. I’m so lucky to get to share my love of technology with the love of my life every day.
Inventor, coder, and entrepreneur, Brantley Coile invented Stateful packet inspection, network address translation, and Web load balancing used in the Cisco LocalDirector. He went on to create the Coraid line of storage appliances, a product he continues to improve today.