


Advertisement

There are a number of
slightly different implementation of the SCSI bus – SCSI 1, Fast SCSI ,
wide SCSI and SCSI 2. Each of these is an attempt to increase the speed of operation
of the bus in some way or another.
Each device connected
to the SCSI bus is identified by a unique ID number, 0 to 6, and each device
may be further subdivided in to Logical Unit Numbers, or LUNs. For example and optical disk mat be configured to be device
OD 5 but different partitions of
the drive may be allocated at LUN 0, LUN
1 etc.. In most cases devices only make
use of a LUN 0. So for example, the
first SCSI hard disk may be ID 0 LUN 0
and the second IS 1 LUN 0 and so on.
The problem with SCSI
is that while the interface between the
SCSI devices is reasonably well
defined, the interface between the SCSI controller and the machine
isn’t. the problem is that while it
is clear how an ISA, MCA or EISA SCSI controller should be built from the
hardware point of view, there is no
standard for the way software should
treat it. For example, a standard
ST-506, IDE or ESDI hard disk will be used to boot i.e start, the
machine because the software that deals with it is defined as a part of
the standard BIOS found
in every machine. However, there is no
standard software that
automatically boots from a device connected to a SCSI controller. After all,
how can the standard BIOS know that the
device is a disk drive – it might be
a tape drive, CD-ROM or a printer!
The most common
solution to this problem is to include a
special SCSI BIOS ROM on the controller itself. This will usually contain the
software that identifies the
device connected to the SCSI interface as a disk drive and
will even boot the system from the drive. In this case the usual system
BIOS has no part to play in handling
the disk drive and the usual setup procedure should
be used to set the drive
type to “none”. If an ST-506, IDE or ESDI
drive is used at the same time as a SCSI drive then it is usual for it not to be used to boot the
system. The SCSI BIOS usually scans the
SCSI bus when the machine is first switched
on by sending message asking each
device ID in turn to identify
itself. There is usually a limit on the
number of hard disks supported typically
two. If you need more then you have to
make use of additional software drivers. The devices are scanned in order of ID number, 0 to 6 and the first
device to identify itself as a
hard disk is used to boot
the system. After this SCSI
hard disk behave like normal
hard disks but low level formatting and
advanced diagnostic programs generally don’t work unless you obtain a version specifically written for SCSI drives.
The great attraction of SCSI is the idea of being
able to connect other devices to
the same controller. In practice this is more difficult than
you would imagine, again because of the lack of a standard software interface. You may be able to connect a SCSI
tape drive to the system with out any
fear of hardware incompatibilities, but
you also need a device driver to allow MS-DOS, or whatever operating
system, to make use of the
device. The trouble is that this driver
needs to be written specifically for the
device and the controller combination.
device manufactures have often overcome this difficulty by bundling a SCSI
controller and software drivers with their
device. So you get a SCSL controller
when you buy a hard disk, another