HARDWARE CLINIC: SCSI in Detail   (2/94)


By Mark Minasi

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' manufacturers, 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 theoretically 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 possible 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 AHA1542 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:<sc14>UTILS<sc14>ASPI4DOS.SYS DEVICE=C:<sc14>UTILS<sc14>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, ASPI4DOS, 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, There 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
ASPIDISK.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 ASPI4DOS and ASPICD came from a single
vendor--Adaptec, in this case, as part of a package that it calls EZSCSI. 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, top-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 AHA1542 is
recognized, and so my OS/2 CONFIG.SYS automatically gets these lines.

BASEDEV=AHA1542.ADD DEVICE=C:\OS2\CDROM.SYS IFS=C:\OS2\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 support the Adaptec AHA1542.

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 drivers, OS/2 drivers,
Windows NT, and SCO UNIX. Drivers are also widespread for hardware from
Ultrastor 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.I13 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 boards: a well-defined common 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. 

COMPUTE, February 1994




Transmitted:  94-01-19 16:26:05 EST

