The continuing saga of SCSI. (small computers systems interface)(installing SCSI peripherals) (Hardware Clinic) (Column)
by Mark Minasi

SCSI IDs and parity keep communication on the SCSI chain unambiguous and error-free.

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 mjust 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 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 ecxample) 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'v e 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, "I dentify 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--itm 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, "Waht 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 lomega makes a cartridge backup device called the Bernoulli Box. One of its offerings is the lomega 44+44 Bernoulli backup device. It's a metal case containing two 44MB cartridge drives, and it's SCSI compatible. If I connect an lomega 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 SLUNs; 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 noice affecting the signal transmission. You may have heard or 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. (The things that can contribute to bits being toggled in transmission include static on the lines and sun-spots 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 (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 sujpport 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 CD-ROM 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 terminatting it. (Don't worry--termination is a good thing in the SCSI world.)