Service manual

Service Manual
Input
Four pulses are sent: the fourth pulse is repeated until
ROMCS is asserted in response. The following eight
pulses then clock in eight data bits, most significant bit
first. ROMCS asserted (overdriven to disable the ROM)
is interpreted as a logical '1'. If pulses continue without a
break, they should be interpreted as further polling for
input and more data may be transferred without returning
to the initial four-pulse start-up.
Output
Three pulses are sent: if ROMCS is asserted (
overdriven, disabling ROM) in response to the third
pulse, the interface is ready for data. A break then
occurs, and either another attempt is made or data is
sent. Data is transmitted as an eight-group sequence of
either one or two pulses, where one pulse is interpreted
as a logical '1'. Each sequence of eight bits is preceded
by a sequence of three-pulse poll operations to ensure
the interface is ready for data. A dummy three-pulse
sequence is sent at the end of a series of bytes to
ensure that the last byte is recognised.
The interface is forced to drive only the LCD module
when a pin on the 20-way IDC host connector is NOT
grounded. The target will then always read zero from the
interface (causing POSTs to execute) and will not write
data to the LCD faster than 1 byte / 5ms, to ensure the
LCD module always has sufficient time to process
commands. The LCD module requires a maximum of 1.
6ms to process the slowest command.
The shift register drives the LM020L LCD directly in 4-bit
mode to permit control of both data and the RS control
line with only 8 bits of I/O. The LCD is never read by the
integral test software, even to poll the display's BUSY bit.
Instead, another monostable is used to generate the 5ms
pause time required to ensure every command has
sufficient completion time.
When in host control mode (the connection of the host
cable to a user port will short to ground the DEN input)
the interface may be controlled by user port bits as
follows:
CB1 (COUT): Host output - clock pulse when
writing data to the interface (must
be input when PB1 is clock).
CB2 (WRD): Host output - data from host when
writing data to the interface (must
be input if MSTR is not asserted).
PB0 (RDD): Host input - data from interface
when reading data.
PB1 (CIN): Host output - clock pulse when reading
data from the interface (must be
input if CB1 is clock).
PB2 (MSTR): Host output - asserted low by the host
to obtain control of the shift
register.
PB3 (RDS): Host output - strobed low to indicate
data has been read from the
interface.
PB4 (TXRDY): Host input - set high to indicate
interface has data ready to send
to host.
PB5 (WRS): Host output - strobed low to indicate
data has been written to interface
by host.
PB6 (RXRDY): Host input - set high to indicate
interface is read to receive data
from host.
PB7 (RST): Host output - set low to assert
RESET on target.
External debug protocol
The integral test software initially performs a four-pulse
sequence followed by a gap to ensure the interface state
machine is properly reset. A byte '&90' is then
transmitted to indicate readiness for a command. This
value may change in later issues of the software to
indicate changes in the command protocol. The target
then waits for a single byte command. The following
values are currently acceptable:
0 Go to LCD driving mode
&08 - &OF Write data
&10 - &17 Read data
&18 Execute (jump to address)
&20 - &27 Perform bus cycles
&FF Perform self test
If the input operation to read this command never sees
ROMCS overdriven, no interface hardware is recognised
and the IOC power-on-reset bit is tested to determine
whether a soft or hard reset sequence should be
performed.
Note that the interface hardware in LCD mode will
always return 0, causing the POST to be performed. A
diode connected between LA21 and ROMCS will appear
always to return &FF, forcing a self-test regardless of the
state of the IOC power-on reset flag.
In each case (except for Execute), the lower three bits of
the command byte provide for options on the command
execution.
Part 5 - Main PCB fault diagnosis Issue 2, June 1991 5-15