SCSI in detail. (small computer systems interface) (Hardware Clinic) (Column)
by Mark Minasi

SCSI IN DETAIL

More and more devices that I install these days are connected to my PC via SCSI cables. Suppose you were to install a tape drive, a disk drive, a scanner, and a CD-ROM drive. Think about what you'd have to do to install them. It's quite possible that you'd end up installing a hard disk controller board, a tape drive controller board, and another interface for your CD-ROM drive. With each new board added to a computer system, you multiply your risk of ROM address, I/O address, DMA, and interrupt conflicts.

You'd also have to install DOS device drivers. What will happen when Windows 4.0 arrives? Windows 4.0 won't use DOS. It won't recognize your tape and CD-ROM drives. You could request updated drivers for the new operating system from the peripherals' manufactures, but these days you never know how long a company will be in business, or whether it will support older hardware.

SCSI simplifies things by allowing you to attach a variety of devices to a single board--the SCSI host adapter. Then you install a device driver for that board, so that it can communicate with your operating system. In this way, you can control several devices--seven peripherals, in the simplest arrangement, and the oretically about 12,500 devices in the most complex--with a single board.

When a new operating system comes along, all you need to do is to find the driver for your SCSI host adapter for that operating system.

Suppose I have a choice of two CD-ROM drives. One, from company P, uses a proprietary interface and ships with DOS device drivers. The other, from company S, uses a SCSI interface and ships with DOS device drivers. In fact, the system from company S ships with two device drivers --one for communications between the SCSI host adapter and the main system, and another for communications between the CD-ROM drive and the SCSI adapter.

The proprietary approach is simpler, resulting in smaller drivers and a simpler CONFIG.SYS. But the SCSI approach sacrifices some simplicity to gain compatibility. The CD-ROM drive, because it is SCSI compatible, responds to a standard set of commands, such as read track X, provide status report, eject disk, and so on. Any SCSI controller could control any CD-ROM drive in the same way. That makes it possibel to write a generic CD-ROM-to-SCSI interface driver.

This does not mean that all SCSI CD-ROM drives are equal; they aren't. But the basic programming commands stay the same. This means that if 500 different vendors all make SCSI-compatible CD-ROM drives, then it's not necessary to make 500 different CD-ROM drivers. One will do.

As a result, even though OS/2 2.1 is not as widely supported in device drivers as is DOS, it's duck soup to get OS/2 2.1 to recognize either a Toshiba or an NEC CD-ROM drive.

The next reason why the SCSI approach makes better sense than the proprietary approach is the interaction between the operating system and the SCSI host adapter.

DOS sees SCSI as a manager of block-oriented drives. Devices in DOS are either character oriented or block oriented. Character-oriented devices (serial ports and keyboards, for example) deal with data on a character-by-character basis. Block-oriented devices deal with data in blocks of a fixed size. Block-oriented devices include hard disks, CD-ROM drives, floppy drives, and LAN boards. A device driver prepares DOS for the SCSI host adapter, and that device driver must be specific to the SCSI host adapter.

Let's consider an example. Suppose I install an Adaptec AHA 1542 SCSI host adapter in a PC and an NEC CDR84 CD-ROM drive (SCSI compatible, of course) into that PC as well. I'd end up with just two lines changed in my CONFIG.SYS. Those lines might look like this.

DEVICE=C:[unkeyable]UTILS[unkeyable]ASPI4DOS.SYS DEVICE=C:[unkeyable]UTILS[unkeyable]ASPICD.SYS /D:MSCD001

Then the AUTOEXEC.BAT would include one new line, which in its simplest form would be as follows.

MSCDEX /D:MSCD001

The first driver, ASP14DOS, establishes SCSI for DOS. It says, in effect, DOS, I'm a new device called SCSI. You talk to me the same way that you talk to other block devices --just ask me to read or write data. But I may have a number of different block devices attached to me. In any case, don't worry about how many cylinders, sectors, or tracks I have--I'll handle all of that. Just tell me what data you need or what data you want written, and I'll take care of the rest. This device driver is sometimes called the SCSI Manager. The second device driver doesn't really talk to DOS; it talks to the SCSI Manager, saying, These is a device on your host adapter. It is a CD-ROM drive, and here are the kinds of commands you can give to a CD-ROM drive. If it were a hard disk, the driver wouldn't be ASPICD.SYS; it would be ASPICISK.SYS. The main difference between device drivers is that CD-ROM drives use a few commands that disks don't (such as eject and lock), and vice versa (a CD-ROM drive would have no use for a write command.

The driver also gives the CD-ROM drive a logical name, which is needed by MSCDEX.MSCDEX is the Microsoft DOS CD-ROM Extension; notice the /D:MSCD001 in the lines above. That links the CD-ROM driver and the extensions.

Naming the CD-ROM drive is necessary because it's possible to have more than one CD-ROM drive installed. By giving each a name, you can have several CD-ROM drives along with several separate instances of MSCDEX, and each copy of MSCDEX could have different parameters.

Look at those drivers carefully, and you'll see my earlier point about the simplicity of obtaining drivers. Both ASP14DOS and ASPICD came from a single vendor--Adaptec, in this case, as part of a package that it calls EZ-SCSI. But other vendors, such as Future Domain and Corel, offer similar packages--Power SCSI! from Future Domain and CorelSCSI! (they both seem pretty excited about these packages, don't they?) are popular, too-quality collections of SCSI drivers you should consider.

Now think about what's involved with moving to a new operating system--OS/2 2.1. OS/2 2.1 includes SCSI management features, so the installation program searches for well-known SCSI host adapter boards. The Adaptec AHA-1542 is recognized, and so my OS/2 CONFIG.SYS automatically gets these lines.

BASEDEV=AHA1542.ADD

DEVICE=C:[unkeyable]OS2[unkeyable]CDROM.SYS IFS=C:[unkeyable]OS2[unkeyable]CDFS.IFS

These three lines do for OS/2 just about exactly what the three lines we saw earlier did for DOS. The ADD file (first line above) is a file that essentially loads a BIOS-like part to OS/2, a set of low-level supports for some feature--SCSI, in this case. CDROM.SYS is a generic CD-ROM driver, like ASPICD, that works only because it's living in the SCSI environment and assumes that a SCSI manager is active at the moment. OS/2 then needs to support the file system found on a CD-ROM drive and needs something like MSCDEX.

OS/2 can, however, go a step further than DOS and install intrinsic support of a whole new way of organizing files via its Installable File System, or IFS. OS/2 ships with a CD-ROM File System IFS driver so that it can support CD-ROM drives of any kind. Again, note that at no time did I have to get NEC on the phone and beg for an OS/2 driver. All I had to do was to hope that OS/2 would should the Adaptec AHA 1542.

Is that a lot to hope for? I don't think so. There are several major SCSI hardware vendors, and even the beta versions of most new operating systems supported them. The Adaptec line is supported by DOS drives, OS/2 drivers, Windows NT, and SCO UNIX. Drivers are also widespread for hardware from Utrastor and Future Domain. Don't forget to look for drivers in obvious places. I've got an Ultrastor 22CA controller that I bought two years ago on promises of OS/2 drivers coming "soon." Six calls to Ultrastor over 24 months and poking around in its BBS extensively turned up nothing. As it turns out, the Ultrastor controller uses the IBMINT13.l13 driver that's included with OS/2.

Suppose I had added a hard disk, a scanner, a tape drive, or an optical read/write disk. The story would be roughly the same, although truthfully, it's harder to find SCSI scanner drivers at the moment, and not every vendor supports tape drives; for example, EZ-SCSI doesn't come with tape-drive drivers. But CorelSCSI! does. I also found the Corel tech support people to be very helpful when I ran into a configuration problem.

Suppose I had added a proprietary CD-ROM drive, such as one that comes with a sound board. I might have found drivers, and then again I might not have. My experience is with the Creative Labs multimedia kit, which includes the Sound Blaster Pro and a Mitsumi CD-ROM drive. Early on in the OS/2 2.x beta process, it looked as if we wouldn't get drivers, but Creative Labs now has drivers for OS/2--and good ones at that. (The moral of this story is that you should buy from companies with a reputation for good customer support, and Creative Labs' customers have always enjoyed good customer support).

In essence, SCSI provides for drivers much the same thing that the PC expansion bus provides for circuit mon denominator.

Speak Up!

Do you have a tough hardware problem you'd like Mark to tackle? Let him know about it by calling (900) 285-5239 (sponsored by Pure Entertainment, P.O. Box 186, Hollywood, California 90078). The call will cost 95 cents per minute, you must be 18 or older, and you must use a touchtone phone.