HARDWARE CLINIC: The Continuing Saga of SCSI   (4/94)

By Mark Minasi

How to get along with SCSI.

Last month, we started looking at the techniques necessary to get a PC up and
running with SCSI peripherals. Although I said last month that I'd cover
active termination in this month's column, space considerations have forced
me to move that topic to next month's column. This month, we'll look at the
next two steps: setting SCSI IDs and installing peripherals.

Each device in a SCSI system must have a unique identification number called
a SCSI ID. The values for this ID range from 0 to 7, and as the numbers must
be unique, the SCSI system generally won't work if you attach more than one
peripheral that uses the same ID. Typically, the host adapter is set to 7.
You can change the host ID, but don't. Changing the host ID will
unnecessarily expose you to software incompatibilities.

Before installing a peripheral in your system, you should assign it a SCSI ID
(usually with a DIP switch, a jumper, a thumbwheel, or the like). There are
just a few rules for setting SCSI IDs.

Rule 1: Each device on the SCSI chain must have a unique ID. Putting two SCSI
devices on the chain with the same SCSI ID number will prevent both devices
from working and could keep other SCSI devices from working.

Rule 2: Don't use ID 0 or ID 1 for anything but hard disks. Much SCSI
hardware assumes that anything at ID 0 or 1 is a hard disk. In a pinch, it's
OK to assign ID 1 to something other than a hard disk drive, but never assign
ID 0 to anything but a hard disk unless you've got a PS/2 (we'll get to PS/2s
shortly).

Rule 3: If you plan to boot from a SCSI hard disk, make it ID 0. The BIOS on
your SCSI host adapter will expect a boot device to have SCSI ID 0 (except
for PS/2s, as I'll explain in a minute). This doesn't mean that you must boot
from a SCSI device if you have a SCSI host adapter, however. A number of
computers in my office boot from IDE hard disks and then use SCSI host
adapters to access CD-ROM drives. But any SCSI boot device must be at ID 0.

Rule 4: Check the documentation for your operating system to see if it
expects a device at a particular ID. For example, my advice to put a hard
disk on ID 0 or 1 is really DOS-, OS/2-, and NT-based advice. Other operating
systems (SCO UNIX, for example) may not care which ID you use for a boot
drive. At the same time, SCO must see any CD-ROM drives at ID 5. Sometimes
the only way to solve a SCSI problem is to try out different ID combinations
until something works. I've never fixed anything by fiddling around with the
host adapter's ID, but I've fixed things by twiddling the peripheral IDs.

Rule 5: IBM PS/2 machines with SCSI drives use ID 6 for bootable hard disks.

If some of what I've said sounds vague, it's because SCSI is still evolving.

Keeping track of SCSI IDs isn't as hard as it sounds. One of the really nifty
things about SCSI is that SCSI devices will tell you about themselves if
asked. When your system powers up, your SCSI host adapter says to the other
SCSI devices, "Identify yourselves!" For example, on a system that I own with
a SCSI host adapter and an NEC CDR-84 CD-ROM drive, I see a message on
boot-up that says Host Adapter #0 - SCSI ID 6 - LUN 0: NEC CD-ROM DRIVE: 841
1.0. This tells me that on host adapter number 0--it's possible to have more
than one host adapter--there is a device with SCSI ID 6. Sometimes, you'll
see a message that refers to a target SCSI ID. Target SCSI ID is the same
thing as SCSI ID. So when you see target, ignore it. Don't worry about LUN;
I'll explain that in a minute. The device is built by NEC, and it's a CD-ROM
drive. The specifics of its software indicate that it is the NEC 84 CD-ROM
drive, version 1.0. That identifying information makes it easier for software
to automatically configure new hardware. For example, when I install a
program like Adaptec's EZ-SCSI or Corel's CorelSCSI!, I needn't tell the
program that I have a CD-ROM drive on SCSI ID 6--it reads that information
right off the drive.

If it's not obvious how useful this is, consider what's involved in the
installation of a standard IDE hard disk drive nowadays. In order to get the
PC to recognize the drive, you have to tell the PC how many cylinders the
drive has, how many heads it has, and how many sectors are on each track on
the disk. Why can't the drive tell the PC? Or how about the ordeal of
installing printer drivers for every new piece of DOS software? It's silly
that when I install Windows or OS/2 on a system, the installation program
eventually asks me, "What kind of printer do you have?" That's something that
a computer and a printer ought to be able to work out between themselves. But
they can't, because of the the interface between IDE hard disks and PCs and
between printers and PCs.

Now let's get to that message that included LUN 0. LUN (Logical Unit Number)
refers to the fact that a SCSI device can have subdevices. Let's take an
example. A company by the name of Iomega makes a cartridge backup device
called the Bernoulli Box. One of its offerings is the Iomega 44+44 Bernoulli
backup device. It's a metal case containing two 44MB cartridge drives, and
it's SCSI compatible. If I connect an Iomega 44+44 cartridge device to one of
my SCSI systems, then I'll see a new SCSI ID, which refers to the 44+44
system. The two 44MB cartridge drives will be distinguished not by different
SCSI IDs but by different LUNs under the same SCSI ID.

This situation is fairly unusual in the SCSI world and, as a result, could
give your system heartburn. But now you'll know what LUN refers to. Again,
the vast majority of devices include only one LUN. But suppose a device has
more than one LUN; how far could this go?

In theory, each SCSI device can have up to eight LUNs. To make things even
worse, each LUN can have a sub-subdevice name called an LSUN (Logical
Sub-Unit Number) which can range from 0 to 255. Again, I do not recommend
trying to use LUNs or LSUNs; it will be difficult to get drivers to use them.

Once you have resolved your SCSI devices' SCSI IDs, you'll probably have to
enable or disable a feature called SCSI parity. Parity is a system for
detecting transmission errors. Transmission errors can arise from faulty
cables, bad connections, or electromagnetic noise affecting the signal
transmission. You may have heard of parity when working with communications
systems, which specify odd, even, or no parity. The parity system used by
SCSI is a mite complex--more complex than is worth explaining in detail, in
fact. But let's get an idea of how it works by looking at simple parity as
used by communications systems.

Data communications often send textual data--ASCII text files--rather than
binary data, such as Lotus spreadsheet files, WordPerfect document files, or
program files. Each character of text is represented by seven bits of data;
for example, a capital A, expressed as bits in ASCII, is 1000001. If you
transmitted 1000001 over a modem and it was received on the other end as
1000011, then the receiver wouldn't get an A; it would get a C instead. Just
flipping one bit can change the whole meaning of a message. (Things that can
contribute to bits being toggled in transmission include static on the lines
and sunspots affecting communications satellites.)

Parity adds a little redundancy, which makes it easier to spot bad
transmissions. Let's look at even parity. With even parity, the sending
device gets seven bits to send (a character) and then adds an eighth bit--the
parity bit. The value of the eighth bit is set to be either a one or a zero,
so that after the eighth bit is added, the total number of bits in the
eight-bit group will be even. In the A example, the data is 1000001, so there
are two ones--an even number. This does not need another one, so the parity
bit is a zero. The sender would thus send 10000010.

Assuming that the receiver is set up to expect even parity and seven data
bits, it looks at the eight data bits and checks to see if there are an even
number of ones. If there are, the receiver assumes that the data was received
without error and strips off the parity bit.

Only the data communications equipment (or the SCSI interface components, in
the case of SCSI devices) on either end of the communication are interested
in this parity bit. The parity bit is added by the equipment on the sending
end and interpreted and removed by the equipment on the receiving end. The
computers or terminals on either end are unaware that anything happened in
between.

Let's take another example of parity. The code for the character C is
1000011. In this case, the seven data bits contain three ones. Three is not
even, so the added parity bit in this case should be a one. The eight-bit
group is now 10000111, which has an even number of ones.

Again, the receiver would recognize the first seven bits as accurately
received and strip off the extra bit before storing the byte.

In order for any device to use SCSI parity, all SCSI devices must support it.
If any device does not support SCSI parity, then you must disable it for all
devices on the chain.

This can become vital because some operating systems like Windows NT will not
work at all with a SCSI CDROM drive unless it supports SCSI parity.
Therefore, you should plan to support SCSI parity from the very beginning;
buy only devices that support SCSI parity (and SCSI-2).

Next month, we'll look at cabling the whole mess up and terminating it.

COMPUTE April 1994



Transmitted:  94-03-15 16:46:48 EST

