For the Commodore 64 & 128 Computers

Written by eBay's 94Bravo




Hard Drives




Editing SYSGEN



SCSI Adapter

Multiplexer Unit


Drive Case & Cables

The Wall

DOS Commands


Lt. Kernal Host Adapter circuit board

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.

Lt. Kernal - Newest/Oldest Host Adapter
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).


Lt. Kernal Host Adapter component location

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.

Home | Host Adapter | Sysgen | Drives | Files

Lt. Kernal Data Archive 2003-2007 / Contact Author for Inquires