|
|
|
HOST ADAPTER
- Details &
Troubleshooting
|
|
|
|
|
|
Xetec
HOST Adapter:
This section
describes the Host Adapter hardware subsystems
and provides recommendations
for component replacement or substitution.
The sections on System Firmware and RAM
also partially explain the operational
theory of how the system works. Topics
covered include:
|
|
|
PIA:
The Host Adapter
was designed around a Peripheral Interface
Adapter (PIA), MC68B21P. This was a commonly
used device and is still available today. The
"B" indicates this is a 2 MHz device that was
necessary for Commodore 128 compatibility. There
is also a 68A21 (1.5 MHz) and 6821 (1 MHz) version
of this device. If you are using the Lt.
Kernal on a C64, you could use any of the
three versions as a replacement component,
but it's recommended to simply use the
commonly available 68B21P device.
The PIA provides
the means of interfacing the Commodore bus
and hard drive controller via two 8-bit data buses. The PIA's Control
Register and two Data Direction Registers (DDR) control
the two-way flow and are switched by
LK DOS and four control lines. However,
when the Commodore is first turned on, *Reset initializes the PIA which
zeros all PIA registers, sets the PA & PB data bus as Inputs and disables
all interrupts. So, how does the PIA know what to do next? The
hardwired code contained in PLD-1, PLD-2 and the Boot firmware contained
in U7 EPROM set the PIA registers and start communications between the Commodore
and hard drive. Once Bootup is complete, LTK DOS takes over control
of the PIA.
When the Commodore
needs to send a command to the drive, LK
DOS assembles a SCSI Command Descriptor
Block (CDB) command. This CDB is then loaded into one of
the PIA data registers and sets the DDR
to output this CDB to the hard drive
controller. The hard drive controller
interprets the CDB and responds. If,
for example, the CDB requested a
particular block of data to be read
from the drive, the PIA needs to change
the direction of data flow (via DDR) and
wait for the drive to respond. Until the
data is ready, the Commodore does not sit idol;
it goes on with what it needs to do. In the mean
time, when the hard drive controller sends
the block of data, the data passes through
the PIA and goes into part of lower Shadow
RAM. When loaded into RAM, the Host
Adapter sends an interrupt to let the
Commodore know the data is ready. This is
the concept of how data and handshaking
takes place between the Commodore and hard
drive controller.
|
|
|
Program
Logic Devices (PLD):
The logic
contained in the two CMOS, 20-pin DIP, P5C032 PLD
(Programmable Logic Device) chips (U1 and U2) provide the
decoding and control logic needed to map the
Host Adapter Shadow RAM in and out of processor
space. The 5C032's are UV-erasable, 1st-generation Intel PLDs and
are capable of Combinatorial or Register logic (combinatorial in the
LTK). As mentioned before, the 'Security Bit' was set when
these devices were programmed by Xetec in an attempted to protect their
LTK design. However, because an EPROM is called a poor mans
PLD (and the logic is supposed to be combinatorial), decoding the PLD's
logic is possible. You need to know that all inputs (pins 1 - 9
plus pin 11) are used as inputs and pin 14 of U2 plus pin 15 of U1 are wired-OR
(*NMI) Input/Outputs (I.C.Q.U.B.).; - Pin 14 & 19 of U1 and pin 13 of
U2 may be unused inputs, an I/O wraparound or N/C; - Pin 13 of U1 (CAEC)
is an Input/Output; - based upon U3, pin 23 (*CS2), Pin 12 of U2 may be an
Output only or an Input/Output (see datasheet).
Once you have decoded the logic
table, there's no need to program another rare P5C032
blank. Instead, use a direct substitute (e.g.,
EP320IPC) or adapt any number of
similar devices including a GAL (16V8)
or PEEL (18CV8P-25). No, you can't use the logic table directly,
but there are any number of programs you can use for conversion (including
PLDShell, ABEL, etc.).
|
|
|
System
Firmware:
U7 of
the Host Adapter contains Bootup Firmware.
This not-very-populated 2764 EPROM
performs some very important tasks during startup.
When the Computer is first turned
on, the Host Adapter's PIA and 16K RAM
need to be configured and LK DOS needs to
downloaded from the hard drive. (The firmware contained
in the EPROM is slit into two sections - first half is for C64 bootup
while the second half is for C128. Both serve the identical
function). So, if we looked at the
first nine (9) bytes in the EPROM, we begin
to see how this initialization is done.
The following is a simplified and compressed
explanation of the Lt. Kernal bootup sequence.
Remember that once the EPROM has booted the Lt.
Kernal, it is no longer used.
The
fifth to ninth bytes of the EPROM contain
the familiar "CBM80"! Well, what do you
know, the EPROM contains an AutoBoot program
(Commodores' normal cartridge
autoload routine). Because the Host
Adapter is plugged into the Expansion
Port, byte zero of the EPROM is also
looking at $8000 (hex) of the Commodore!
So when power is first applied to the
computer, the Commodore looks at bytes 5
through 9 of the EPROM and if it finds
"CBM80", it continues with an AutoBoot routine.
Startup then continues by looking at the
first 4 bytes of the EPROM ($8000-$8003)
to determine the Cold and Warm vectors,
both of which turn out be $8014. From now
on, it's easy to see that bootup is just a normal Cartridge bootup routine.
Remember that at this point in time, there is
No Lt. Kernal or Lt. Kernal DOS software at
work; only firmware programs contained in
the Host Adapter's EPROM. This same bootup
happens for the C128. The Host Adapter tricks the computer to look in the
second half of the EPROM, thinking it is $8000 (Host Adapter P1, pins 1&2
either grounds or is High at pin 2 of U7 - bank switches either 32K halves
of the EPROM).
The
program at $8014 does several things. It
sets the PIA control registers, assembles a CDB and
sends the CDB through the Host Adapter to
repeatedly select SCSI ID 0. If there
is no response from the hard drive, LTK bootup is aborted and the
Commodore boots to its normal startup screen.
But if the computer determines that the
responding device is a hard drive, the
drive is instructed to send the first Block
of data from cylinder 0, track 0, sector 0 of LUN
0. (Note: In a modern SCSI computer
system, all SCSIs IDs are polled, but only
SCSI ID 0 is addressed in the Lt. Kernal).
If the hard drive responds, the data from
this read should contain three pieces of
data; the SYSGEN-installed Serial Number,
hard drive parameters for ALL installed
hard drives and rudimentary code needed to
load the balance of the LK DOS. This data
block is temporarily stored in the lower
8K of Shadow RAM.
NOTE: Gee, I wonder, is there enough space
left in the EPROM to first send a "Disable Parity" command to the
Drive? Sure would be nice to use a 2.5 inch laptop drive
:)
If the
serial number data from the hard drive
read does not match the serial number
stored in the EPROM (bytes $0A to $11) the whole
bootup process comes to a screeching
halt! If the serial numbers do match, the
supplemental boot code and the hard drive
table data (now in Shadow RAM) are used to
read LK DOS from the hard drive as part of
the EPROM bootup process. Once the serial
numbers match and the LK DOS is loaded
from the hard drive, the Lt. Kernal is now
running under LK DOS and the boot EPROM is
subsequently switched out as bootup is
complete.
If you
want to know how the hard drive parameters
got onto the drive in the first place,
refer to the SYSGEN and Hard Drive sections.
The concept of the AutoBoot
routine is straight forward, but unless
you understand what's supposed to happen,
you will have difficulties diagnosing the
system.
This is
also why a proper SYSGEN installation onto
the hard drive is important and why some
data loaded during a SYSGEN needs to 'match'
the Firmware stored in the EPROM. See the sections
on SYSGEN and Hard Drives for more information
on how to verify/change the serial number on the
SYSGEN disk.
Of
course, when you install a new hard drive,
there is No DOS data to load! So, refer to
the Hard Drive and SYSGEN sections to see
how this is handled.
|
|
|
16K
Shadow RAM:
There are two
CXK5864PN-15L 8K RAM chips in the Host
Adapter (U8 and U9). Some Host Adapters used
Dallas RA000001A RAM chips. In either
case, these are the same as a more common
6264P RAM chip. I guess the first question
is why does the Host Adapter have RAM at
all? The Commodore has RAM and a Kernal
ROM and the Host Adapter has an
EPROM.
The Host Adapter
has extra RAM because the Commodore itself
was not designed with a Disk Operating
System, or DOS. The only thing the Commodore
has is a kind of BIOS (Basic
Input/Output System) or startup routines
contained in the Kernal ROM. If the LK DOS
was loaded into Commodore RAM (as it
was in the earlier LTK design), there won't
be as much RAM left for application software.
Also, in the early LTK designs when LK
DOS was loaded in Commodore RAM under the
Kernal ROM, it lead to software conflicts
with other programs. And, because of these
early software conflicts, Fiscal decided
that No LK DOS software should reside in
the Commodore RAM, resulting in Shadow RAM
being incorporated into the Host Adapter's
design.
So, by having two
extra 8K RAM chips in the Host Adapter,
you can start to see why and how they're
used. Back when the Host Adapter's firmware was
beginning an initial boot, shadow RAM is switch
off. But after the first Block
of data from cylinder 0, track
0, sector 0 of LUN 0 was read, it's stored
in part of lower 8K RAM. The Bootup
firmware then (1) sends new vectors to
lower ram in the Commodore, (2) the Commodore
Kernal ROM is copied into the upper 8K RAM
and then (3) this copy of Kernal ROM (in upper
8K RAM) is modified (vector jumps) by Host Adapter
firmware.
Now that the upper
8K RAM contains a modified Kernal ROM,
it's treated like a ROM from then
on (Write disabled). The lower 8K RAM (which
already contains the serial number, drive parameters,
LTK LU number and hard bootstrap
code) is then loaded with needed LK
DOS mini-subroutine code from the hard
drive. It would have been impossible to
load all LK DOS into Shadow RAM, which
created some problems for programmers. So
what we have is:
- A LTK-modified
Kernal ROM in upper 8K RAM, acting
like a ROM
- Serial number
and all installed hard drive parameters
loaded in part of lower 8K
RAM
- Some LK DOS
code also loaded in the Lower 8K
RAM
- Two 512 byte
blocks (in lower RAM) are set aside for
input from and output to the hard
drive
- Host Adapter
is looking at RAM in the Commodore at
$8000 (yes, both C64 and
C128)
- Shadow RAM is
then Output Disabled
- And, because
the modified Kernal ROM and LK DOS are
hiding in Host Adapter's RAM, that's
why it's referred to as SHADOW
RAM
From this point forward, Shadow
RAM is primarily used as a temporary holding place for Data exchanges
between the hard drive and Commodore. One trick feature is that Data from
the hard drive is in 512 byte blocks, which needs to be split into Commodore
256 byte blocks. The same conversion takes place in reverse (Commodore
to hard drive) by stacking and splitting data in Shadow RAM. (On
a personal note, John and Marty Flickinger were two software guys who
needed a serious vacation after this design! :)
Needless to say,
if you have a bad RAM chip in the Host
Adapter, you can expect to see some mind-altering symptoms and can waste
time troubleshooting. If you suspect
you've got a bad RAM chip, switching out
these $2 parts is better than countless
hours spent stirring at an oscilloscope
screen. (Yes, a scope will tell you if one
of the two RAM chips have blown output chip drivers
and/or lead to why the outputs are being pulled
low.)
Note: All of the
other active components used in the Host
Adapter are commonly available '74LS' series
TTL integrated circuits with the exception of
one 2N3904 transistor. (See the Files page for
Datasheets on all integrated circuits used in
the Host Adapter) Finally and if you have
the desire, reverse-engineering the Lt. Kernal is one of the best reviews
of 1980's, 8-bit world, designs!
|
|
|
|
|
Host
Adapter Troubleshooting Tips:
*** First, start
with the basics! Turn everything off.
Disconnect the LTK Host Adapter and then power-up
the Commodore by itself to ensure you have a working
computer. And, as with ANY power-consuming device
connected to the Expansion Port, consider if you
are using a stock/wimpy power supply or a more
reliable after-market or custom-built
power source? Are the +5 volt DC and 9
volt AC levels correct? Can you cook an
egg on the power supply (i.e., stable outputs)?
Power supplies that are marginally operating will
generally seem to work fine when the computer
is first turned on. However, after a minute or
so, if the system seems to be performing
erratically, try another power
supply.
*** If the power
supply is operating properly, but you only
see a partial Lt. Kernal startup screen,
which then returns to a normal Commodore startup
screen, the problem is most likely a corrupted
LK DOS software on the hard
drive. Reinstalling LK DOS software should
remedy this problem, but (by reinstalling
LK DOS software) you will destroy all
files on LU 10 (DOS)
including any user files you placed there.
However, All of your files in LU 0 through LU 9
(if you used that many LUs) are still on the drive and are accessible
again after you have reinstalled DOS and Configured the system back to
your previous LU settings.
*** If the
Commodore works normally by itself, turn
it off again and ensure that the two Control lines
are still properly connected inside the Commodore
64. If you're using a C128, ensure that the daughter-board
is properly seated into U7 IC socket and
HIRAM is connected to Pin 23 of U11. After
checking the Host Adapter edge-connector
for corrosion, reconnect the Host Adapter
in the Expansion Port, ensuring that it's
properly seated in the connector. Note:
When inserting the Host Adapter into the Expansion port, Do Not rock the
Host back-and-forth! In worn Expansion port connectors, it is possible to
force the pins left and right, which could short to adjacent card-edge pads.
Also make sure that the HIRAM/CAEC (C64) or IDE
cable (C128) are connected to the correct
place on the Host Adapter.
*** Are you using
a C128 or C128D AND did you just install a
new (different) hard drive? If so, the Lt.
Kernal Defaults to 40-Column mode (not
80-column like the C128). So, change the C128 to
40-column mode. Now that you can bootup, install
LK DOS software and do a full
reset (remember to switch to
40-column mode on the C128). Next, go to
the Config screen, select
F3 and select C128,
80-column mode for your normal startup. From
now on, you'll properly bootup in 80-column
mode on your C128.
*** Next, power-up
the external hard drive and listen for
normal drive spin-up. Then, turn on the
Commodore. If the hard drive needs a SCSI Command
to spin-up (Start Unit), you've
picked the wrong drive for use with the
Lt. Kernal system. (Note: Even though
'Start Unit' was one of the optional
commands in the original SCSI-1 standard,
is it not used by either the Commodore or
LK DOS software). If you are installing a
new drive for the first time, does the
drive have a jumper for 'Start Unit' and
is it properly configured? (check the
drive specifications either online or in a
drive manual)
*** As soon as the
Commodore is turned on, you should hear
(see) the hard drive being accessed by the
Host Adapter (looking for LK DOS software).
If the drive starts searching
for data, the Host Adapter is functioning
as it should and the problem may be either
be a bad hard drive, corrupted LK DOS data
on the drive or you selected the wrong
drive to use with the Kernal (see below
and the section of Hard Drives). Some of
us keep a spare hard drive with a
clean-installed LK DOS for just this
testing purpose (i.e., does the spare hard
drive boot up normally?) Remember too that
older SCSI drives generally die at startup
(e.g., old Quantums and 'sticktion').
*** One simple
test to determine if the Commodore is
talking to the hard drive is to use a drive activity
LED connected to the drive. Contrary to what the
manual says, (if you are installing LK DOS software
for the first time), leave the data cable
connected between the Host Adapter &
Drive and then apply power to the drive and
computer. What you should see is the drive activity
LED flash at about a one-second rate. This indicates
that the Commodore is correctly trying to access
data on the hard drive even though hard
drive parameters have not been downloaded
into the Host Adapter's Shadow
RAM.
Selecting the
right hard drive has a lot to do with how
the Host Adapter behaves. If the hard drive
you are using is one that has been
connected to the system and was working
before, you might consider simply
reinstalling LK DOS software; with or
without first formatting the drive (i.e.,
remap the drives' media for defects).
However, if you are trying to use a new or
different drive, first read the Hard Drive
section.
*** If you are
installing a new/different hard drive, did
you forget to set it to SCSI ID# 0 (Zero)?
The system is hardwired to only look for LK
DOS data on SCSI ID#0. Therefore, if the hard drive
is set to anything other than ID#0, it will seems
as though the Host Adapter is not working.
*** Also, when
trying to use a different hard drive,
unless the drive is properly Terminated, nothing
will work right! It's been my
experience that if termination resistors
are not installed on a single-drive LTK
setup, the Commodore won't even talk to
the drive. The drive must be terminated and
Termination Power must be supplied by the drive. Older SCSI drives
generally use two or three inline 220/330
ohm resistor packs, which are powered by the
drive via jumper pins.
*** If the drive
you have chosen is set to 'Enable Parity',
the Host Adapter will probably not respond.
Even though the Parity Line is
not connected on the Host Adapter, a
'floating' parity line might be
interpreted by the hard drive controller
as a 'parity error'. Therefore, the hard
drive must have Parity disabled (check the
jumpers on the drive). Higher capacity
drives, with more sophisticated onboard
controllers, seem to be less affected by
the drives' Parity settings.
*** If you are
using a C128, and switch to '64 mode', did
you forget to change from 2 megahertz Fast
Mode to 1 MHz (check the F3 screen in Config)? If so, you will only see
a blank screen until you change
to 1 MHz mode!. Also, an alternative
testing approach for a C128 is to disconnect
the 10-pin IDE cable from the Host Adapter and
connect HIRAM and CAEC lines to a space
C64 computer and then retest (see Host
Adapter installation).
*** Another
comment about using a C128 and a 1571 drive
in Fast Serial Mode. When Xetec shipped LTK systems,
these systems did not support Fast Serial mode!
What Xetec did was to ship an extra serial cable
for the 1571 which had the 'SRQ' line cut
(disables Fast mode). Later, a
modification was devised that required
making a change to the C128 circuit board, which
does enable Fast Serial mode (see Files section -
'ltkernal.zip').
*** To help you better understand
how the Lt. Kernals' Host Adapter works, refer to the Site
section on the Multiplexer unit. The Mux section includes
a schematic, timing diagram and detailed troubleshooting procedure
that will also give you a good idea how the Host Adapter works.
*** If you
power-up the hard drive and then turn on
the Commodore and don't hear/see the drive being
accessed, wait! If the Host Adapter
can't bootup properly from the EPROM, the
Commodore should time-out in about 60
seconds and return to a normal C64/C128
startup screen. If this time-out does Not
happen, the Host Adapter is probably
hung-up in a bootup sequence. The next
thing to try would be to replace the EPROM
with a spare and test again. This is actually
a more common fix than you might think.
If replacing the EPROM doesn't resolve
the problem, you're left with component
troubleshooting.
Following the
above suggestions and reading the sections
on SYSGEN and Hard Drives will resolve the
majority of Kernal problems. The few remaining failure situations
require troubleshooting the Host Adapter
components. Using an oscilloscope, look to
see if the PIA is cycling or is it hung
up? What is the level of the reset line?
What happens to the R/W lines on RAM at power-up?
What are the 'levels' of static Hi and Low outputs/inputs?
If you need more help, refer to the Datasheets
in the Files section. (The most common failure
mode of TTL is a blown output driver) With the exception of the
PLDs, any competent Technician should be able
to find a defective Host Adapter TTL component
in a matter of minutes. Remember that the TTL
circuitry in the Host Adapter is pretty hearty
and will survive a lot of abuse. What the Host
Adapter doesn't like is being ripped out
of the Expansion Port sideways with power
applied or directly connecting the Host Adapter to a Mac
or PC SCSI bus!
*** I received a defective Host
Adapter that was traded for several years on eBay. A detailed
failure analysis showed that it was clear the Host Adapter had been
plugged into a Mac or PC SCSI Bus. After replacing U3, U4 and U6
(the 3 ICs that directly interface with the SCSI bus), the Host Adapter
worked fine and is now one of my working spares.
Preventative
measures: One additional thing to
think about when using the Lt. Kernal is that
the Host Adapter plugs into the
Commodore's Expansion Port. Therefore, you
should ensure that the computer setup and
routing of the SCSI data cable (from Host
Adapter to Drive) minimizes the chance
of pulling the Host Adapter out of the
Expansion Port, especially when
powered-up! This may seem obvious, but
frying the Host Adapter will definitely
ruin the Host Adapter and your Day!
Don't
forget that the Lt. Kernal works on an SX-64
computer, which means the Host Adapter
will be sticking out of the Top of the SX!
Therefore, if you really want to use a Lt. Kernal on a SX-64, it is
recommended that you modify the SX by mounting the Host Adapter inside
the SX-64.
Also, if you plan on using a Port
Expander unit for the Host Adapter, select
an Expander (e.g. CMD's EX2+1) that has a
horizontal connector so that
the Host Adapter can sit flat on the desk.
If you're thinking about inserting
the Host Adapter into a Vertical connector,
DON'T! I've personally seen three
Host Adapter with edge connectors that were
snapped off!
|
|
Lt.
Kernal Data Archive 2003-2007
/ Contact Author for Inquires
|
|
|