|
A 'Host
Adapter' is generally a misunderstood term.
Except for a modem desktop/laptop computer
where the hard drive Controller is a VLSI
chip integrated into the motherboard, computers
like the Commodore need something extra;
a Host adapter! Technically, the Host Adapter
is simply required to convert the Commodores'
8-bit data and 16-bit address bus into a format
that can be then handled by a hard drive
controller. The Host Adapter converts the
Commodore data into a SCSI bus format. The Lt. Kernal
Host Adapter actually takes LK DOS-generated
SCSI commands and passes them on to the hard
drive via a simple PIA interface.
Xetecs' Rev-C and Fiscal Informations'
first-design Host Adapters
Before we discuss
the Host Adapter in detail, we should
understand SCSI. The term means Small
Computer System
Interface, which implies that SCSI
is not something that would be used in a
mainframe, and that it is intended to
connect one autonomous system to another.
Equally as important as what is in the
name SCSI is what isn't. SCSI is device-independent.
Although most people think of SCSI in terms
of mass storage (disk, tape, etc.), the fact
is no portion of any SCSI specification ever refers
to a particular type of device (except the host
adapter). You won't see a SCSI command,
for example, described as "this command
reads 10 blocks of data from the hard
drive." Device-independence means that
SCSI can be made to work with almost
anything -- modern document scanners, for
example. There are even printers that can
be driven via SCSI. So it can be said that
SCSI is a true, general purpose, intelligent
interface.
The SCSI
implementation used in the Lt. Kernal is a
modified form of SCSI-1, which is defined by
the ANSI X3.131-1986 standard. For the sake of
discussion, X3.131 covers three major but interrelated
aspects of SCSI:
- Hardware interface.
X3.131 describes in agonizing detail exactly
how the bus and attached hardware are to be
interconnected, what voltages are to be
employed, and the physical attributes
of the cable and its connectors. With
the singular exception of the rarely
used high voltage differential
implementation, the SCSI bus operates
at TTL levels.
The cable type
specified in X3.131 for single-ended
(unbalanced) use is a 50 conductor,
flat ribbon cable with IDC female termination
at both ends (and in the middle if
desired), and a characteristic impedance
of 100 ohms. The maximum permissible
length is six meters, a little more than 18
feet, and there should be at least 20 centimeters
(about 8 inches) of cable between each
device on the bus. Since SCSI-1 defined
an eight bit data bus, a maximum of
eight devices, including the host
adapter, may be connected. It should be
noted that the DB-25 cables used with
the Lt. Kernal, Apple Macintosh and
some modern external SCSI hardware (e.g.,
ZIP drives and document scanners) are totally
non-standard.
SCSI-1
implements a total of 18 circuits on
the bus: nine data lines (eight data bits
plus parity) and nine control lines.
Different combinations of bit patterns
on the control lines are used to manage
the bus and tell devices exactly what
is transpiring at any given instant (this
is the bus protocol). Not all of these circuits
are used by the Lt. Kernal, primarily
because the 6821 PIA used to interface
the SCSI bus to the host bus only has
16 available output lines (controlled
by two eight bit host side data
registers). The Lt. Kernal uses one 6821
data register to drive the eight data lines
-- parity is not implemented -- and the other
6821 data register to operate eight of the
nine control lines.
- Bus
protocol. X3.131 also describes in
agonizing detail the sequence of
operations that must be carried out in
order for a SCSI transaction to be executed.
Included are definitions of signal timing
requirements, how devices are to react to
each phase of a SCSI transaction (there are
eight phases in all), how to cope with bus
errors, exactly what control line bit patterns
are expected for each transaction
phase, what to do if the reset (RST)
line is asserted, etc. The Lt. Kernal
does not implement the entire bus
protocol (for example, arbitration and
select with ATN are skipped).
- Data
interchange. Lastly, X3.131 spells
out (again, in mind-numbing detail) how
commands are to be issued, what
commands are mandatory, what commands
are optional and what commands are considered
vendor-specific (a.k.a. vendor-unique),
as well as how data is to be exchanged and
the kinds of status messages that are passed
back and forth. The Lt. Kernal implements
a small subset of the entire SCSI data
interchange protocol suite. This is not
as serious a limitation as one might
think: only three or four SCSI commands
are needed for the overwhelming
majority of operations that are to be
executed. BTW, a key concept in this
protocol is the command descriptor block
or CDB, which can be thought of as a fixed
length data packet that a device can decode
to find out what it is supposed to do.
In general terms,
a SCSI transaction is initiated when the
host adapter selects the target device (a
hard drive, for example) and sends it the
CDB. The target decodes the CDB and either carries
out the command specified in the CDB
(read a data block, for example) or sends
a complaint back to the host adapter (saying,
for example, the block address in the CDB
is out of range). Once selection has been
made and the CDB has been received by the
target, it (the target) will thereafter control
the bus and indicate to the host adapter what
it should do. Upon completion of the
transaction, the host adapter and target
device will become idle and the bus will
be ready for another
transaction.
In modern SCSI
subsystems, the host adapter hardware
interface and the execution of the bus protocol
are handled by a SCSI ASIC (Application
Specific Integrated
Controller).
Generally speaking, the host computer
merely has to assemble a CDB, give it to
the ASIC and tell the ASIC which SCSI ID
is to be contacted. The ASIC will execute
the appropriate bus protocol steps to make
the connection, send the CDB to the device
(assuming it responds) and report the results.
Once this initial series of setup steps has
been completed, the host will resume control
and process whatever data interchange that is
required. BTW, the current crop of ASIC's can
queue multiple operations, thus making best
use of the bus under all conditions -- true
multitasking.
Unfortunately,
when the Lt. Kernal was first designed,
SCSI ASIC's didn't exist. Even after ASIC's
did become available discrete logic was
retained to maintain backward compatibility
with older units, as well as to avoid cost-runup.
So in the Lt. Kernal host adapter, the 6821
PIA handles the hardware interface to the
SCSI bus, and primitives within the LK
DOS code take care of bus protocol and data
interchange operations.
Keep in mind that
all the 6821 PIA does is generate TTL
outputs in response to bit patterns written
into its data registers. The acronym
PIA means Peripheral Interface Adapter,
the key word being adapter. Conceptually,
the 6821 is no different than the 6520 PIA
that was found in the PET, and CBM line of computers,
6522 VIA (versatile interface adapter) used
in the VIC-20, or the 6526 CIA (complex interface
adapter) found in the C-64, B-128, C-128,
1571, 1581, etc. In all of these cases,
we're referring to a relatively simple
piece of silicon that accepts TTL signals
from the host computer's internal bus and
presents them in a different format on a
different bus. The *way* in which these signals
are understood and used is entirely dependent
on the software responsible for driving the
PIA/VIA/CIA.
All the 6821 PIA
is a line driver, no different in basic
functionality than the 1488 and 1489 line
drivers used with the EIA-232 (RS-232) serial
interface. Because the 6821 is a general
purpose, 16 bit adapter, it could be used
equally well to drive a parallel printer
or turn light bulbs on and off (with suitable
circuitry). Had reasonably priced SCSI
ASIC's been around when the Lt. Kernal was designed,
all of the bus protocol overhead could have
been off-loaded from the computer's CPU, with
a corresponding shrink in the amount of code
that had to be resident in shadow RAM. The
off-loading of the bus protocol in itself
would have significantly boosted the speed
of the system, especially since the ASIC
would have been able to manipulate the
SCSI bus hardware lines much faster than
possible in software.
The photo below
shows Xetecs' newest designed, Rev. C Host
adapter (most commonly used). Shown are
the locations of the system Firmware EPROM,
additional hard-wired logic (2 @ PLDs) and two
8K RAM chips. (Note: The newest DOS even added
a diagnostics program that performs over 60 internal
tests on the Host Adapter.) The Switch
(SW1, 4-switch DIP) was normally set to
zero (all off) unless you were using a
separate Multiplexer unit for use with
multiple Commodores computers and one hard drive.
In a 'multiplexed' application, the switch is
used to set the Host Adapter Number which differentiated
that computer from up to 15 other connected
computers (see the Host Adapter -Multiplexer
section for more information).
The two
Programmable Logic Devices (PLD), identified
as PLD-1.0 and PLD-2.0, contain 'hard-wired' logic used
in switching Shadow RAM. Using PLDs made it
possible to reduce the number of discrete
integrated circuits; similar to the
Commodore 64's use of a 82S100 PLA.
However, these devices were discontinued
in the late 80's and are no longer
manufactured. Unfortunately, when these devices were programmed, the
'security bit' was set, which means the JEDEC code can not be read by a
universal programmer. However, the designer told
me that the P5C032-25 PLDs contain simple Combinatorial logic, which means reverse-engineering
is possible.
One last component
of the Host adapter hardware worth
mentioning is the White (square) switch just
above the EPROM. This is called the "I.C.Q.U.B." switch and, when pressed,
would Freeze and Capture the program that
was running on the Commodore. If the
program was a Game or business program,
pressing this switch allowed you to save
the program, in its current state, to the
hard drive. However, unlike ISEPIC, the
same game or business program would only
run again from the LTK. Still, for the Gamer,
slow-loading a copy-protected game (that
would only load from a 1541 floppy) would
only have to be done once. From then on,
you could load the same game Instantly from
the Lt. Kernal! What about loading Level two of a Game? The nice
feature about the Lt. Kernal is that (1) the LTK can be set to the same
Device number as your 1541 and (2) if the LTK looks for a file that is Not
on the hard drive, it automatically goes to the floppy! You figure out the
rest :)
So, from a
Hardware standpoint, the Host Adapter is
the heart of the Lt. Kernal system. Just about
Any SCSI hard drive can be used with
Xetecs' LTK. But the Host Adapter was
specifically designed for use only with a
Commodore 64 or 128 computer. So, if
hardware repairs are necessary, it's performed on the Host
Adapter or you replace the hard drive.
|
