It is difficult to say how far a non-working HP9866A printer needs to be 
dismantled before attempting to troubleshoot it . For a newly-acquired 
machine,. the covers, plug-in PCBs, printhead and printhead driver should 
all be removed, it is probably worth also removing the mechanism  and 
logic backplane and separating the rear panel to clean and oil the 
cooling fan. For a unit which has been in use and which has recently 
developed a fault, it may be repair it after dismantling rather less of 
the machine, but a warning is necessary here : 

The printhead power supply can supply enough current at a fairly high 
voltage (20V) to do extensive damage to the rest of the printer's 
electronics. The input to this power supply, of over 50V is possibly also 
dangerous to the repairer. And if, due to a fault ,the printhead enable 
signals -- the {\bf  BankN} lines  on the printhead connectors -- are 
held asserted, then the printheads will burn out. Replacement printheads 
are very difficult to obtain.

For this reason, I strongly recommend removing the {\bf Printhead PSU} PCB 
and the printhead when repairing any part of the control logic. After the 
repairs are completed and the unit seems to work, refit the {\bf 
Printhead PSU} and check that none of the {\bf BankN} signals are held 
on. On then refit the printhead and test the printer fully.  There was 
a `Test Fixture' which connected to the test  connector on the {\bf 
Printhead PSU} PCB and which allowed the output voltage of this PSU to 
be reduced, thus protecting the printhead if there was any fault in the 
logic. Although this fixture is mentioned in the official service manual 
no internal details are given and thus although  it was {\em probably} a 
(variable) resistor network that connected to the input potential divider 
on U2, I cannot be certain, ad my repair procedures will not make use of 
such a device.

\section{Power Supply Troubleshooting}

With all the plug-in PCBs, the printhead and the {\bf Printhead Driver} 
PCB removed, set the rear-panel voltage selector switches appropriately and 
check there is a good fuse of the correct rating in the mains fuseholder. 

If the rear panel or {\bf Logic Backplane} have been removed, then refit 
them. Reconnect the 2 edge connectors to the logic backplane. 

As in the case of the HP9800 calculators, it is difficult to safely 
operate the mains-on/off switch when the switch bracket is removed from 
the front cover and mains is applied, so turn on this switch first and 
used a switched mains socket (if you have them on your workbench) or a 
switched cable to control the power.

As in the case of the HP9800 calculators, electrical breakdown on the 
mains input side is very  uncommon. However, it is worth checking taut there 
earth pin of the mains input connector is connected to the metal chassis 
of the unit. And if you have a high-voltage insulation tester (`Megger') 
then check the insulation resistance between the live and neutral pins 
(strapped together) and the case with the mains switch on the unit turned 
on. 

With the printer standing on one side, connect the mains and switch on. 
If the cooling fan runs then firstly it is working correctly and secondly 
(and  more importantly) the mains fuse has not blown. In this case check 
the AC voltages from the transformer secondary windings at the logic 
backplane edge connector and the DC voltages across each of the 2 large 
capacitors on the chassis. If either of the latter are missing then 
suspect the associated bridge rectifier.  

If the fan does not start, check any one of the AC voltages. If it is 
present, then the most likely problem is a fault in the cooling fan 
itself.  

If the mains fuse blows, the n the most likely problem is that one of 
the bridge rectifiers or smoothing capacitors has shorted. Remove the 
mechanism (if you have  not already done so) for access to these parts. 
If these all test good, and indeed if the mains fuse continues to blow 
with the transformer secondary winding leads disconnected from the bridge 
rectifiers, then unfortunately the mains transformer is suspect.

At this stage it is worth checking the 2 power transistors and the diode 
mounted on the main chassis. With the PCBs removed these can be tested at 
the terminals of the associated edge connectors. Again, if replacement is 
necessary, the mechanism has to come out.

It is worth pointing out that many of the plug-in PCBs have test 
connectors on their top edges which carry many of the useful signals 
needed for the following tests. Consult the schematic diagrams for the 
connection details

Now refit the mechanism and card guides if they were removed. Refit the 
{\bf Logic PSU} PSU and apply power again. Check the 3  voltage outputs 
form this board on the backplane pins. Again, should the mains fuse fail 
at switch-on, check the input rectifiers and smoothing capacitors for 
shorts. The  $\pm$12V power supply circuits are very easy to sort out, if 
there is voltage across the smoothing capacitor then the only likely fault 
is a defective e 3-terminal regulator. The 5V power supply is a little 
more complex, Check the 7A fuse on the PCB. If this has failed, then most 
likely the pass transistor has shorted (or maybe Q1 on the PCB has 
shorted)(, causing the output to rise too high and tripping the crowbar 
circuit. If the pass transistor and fuse are OK and there is still no 
output, check the input voltages to U3. If {\bf +5VRef} is missing then 
either U3 has failed or Q4 is turned on, possibly because the 
AC-present detection circuit is malfunctioning. Of course it;'s possible 
for a fault in U4 or its associated components to shut the power supply 
down by indicating an over-current situation where none, in fact, exists. 
Finally on this PCB check that the {\bf Init/} signal is logic high If  
not, check the 5V Vcc supply to U5, U5 itself and the associated components.

If  the +5V  power supply is present, the power-on indicator on the switch 
bracket should be glowing. If not, then the bulb has most probably burnt 
out. Replace it. Check the paper-out (Load) indicator by grounding the 
White/Blue wire on the logic backplane edge connector. Again, the most 
likely fault here is a burnt-out bulb.

Switch off the mains,insert the {\bf Printhead PSU}, and switch on again. 
Check the output voltage from this board, either at the edge connector that
would connect to the {\bf Printhead Driver} PCB  or across either of the 2
largest electrolytic capacitors (C1, C2) on the PCB. As this is a
switch-mode PSU, it is herder to debug then the linear supplies previously
dealt with, but not impossible. Begin by checking he voltage on the
emitter of the chopper transistor Q2, mounted on the main chassis. If this
is missing,, it is likely that the 10A fuse on the PCB has failed. This,
in turn, may be due to problems with the chopper transistor, the
inductor on the PCB or the output capacitors C1 and C2, also on the PCB. 

If the chopper is getting power, but there is no output from this part of 
th PSU, check the {\bf osc} (oscillator) signal  on the test connector 
with an oscilloscope., A non-linear ramp should be present here. Now check 
TP1 on the PCB with  a logic probe.  This point should be toggling, if 
not, then check the inputs to U6a, Either the comparator U5  is not driving 
the rest of the circuit (in which case check U5 and U2), or one of the 
other circuits is shutting the power supply down, possibly due to a lack 
of one of the other voltages. This should not be difficult to trace.

If TP1 is toggling and there is still not output, check the transistors 
Q2, Q4, Q5 and Q6 that drive the chopper. After getting this power supply 
working, disconnect the mains input and remove the {\bf Printhead PSU} PCB 
again and set it aside until the printer logic is essentially working.

\section{Getting the Motor to Run}

Next (with the {\bf Logic PSU} still fitted), refit the {\bf Data Path},
{\bf Control} and {\bf Motor Driver] PCBs. Connect the motor edge
connector to the top of the last PCB. As an aside, the only reason for
having the {\bf Data Path} fitted is to make {\bf RotEn} a logic 0, thus
enabling the manual paper feed logic

Apply power again and carefully  (so as not to touch the mains 
connections  on the on/off switch) press the feed button. The motor should 
turn. If not then start by checking the output of U15a on the {\bf 
Control} PCB. It should be toggling while the feed button is pressed. If 
not, then check that {\bf Autofeed} is not being held low due to a fault 
in the state machine or the decoder U13. Check that the motor oscillator 
is running (that the output of U23d is toggling) and the inputs to U22a.

Once {\bf MotorClk} is correct, check the 4 motor drive signals, {\bf 
$\phi$A}}, {\bf $\phi$A/}, {\bf $\phi$B} and {\bf $\phi$B/} at the 
backplane connector. Lack of activity here suggests a problem in the motor 
counter *U21a and U21b) or the associated open-collector inverters.

When these signals are correct, move on to the {\bf Motor Driver} 
PCB.First check the (unregulated) power supply voltages on C1 and C2. Then, 
using an oscilloscope, look at the {\bf MA} and  {\bf MB} signals on the 
motor connector. Problems here are generally caused by defective 
transistors on this PCB. Or course the problem could be an open-circuit 
winding in the motor itself, This is easy to detect (using an ohmmeter 
across the terminals of the motor edge connector when it is unplugged 
from the {\bf Motor Driver} PCB), but much harder to correct.

Of course with no paper in the printer, the Load lamp should be on. 
Operate the paper detection microswitch with a suitable tool and check 
that the lamp goes out when it is depressed. If not, check the debounce 
flip-flop U28a and U28b on the {\bf Control} PCB and the driver 
transistor Q1. 
 
\section{Repairing the Control Logic}

When working on the control system, the {\bf Printhead PSU} PCB and the 
printhead should be removed, but all other parts should be fitted. 

First check {\bf SMCLk} and {\bf OutEn/} on the {\bf Control} PCB test 
connector. There should be a clock signal  of about 850-900kHz on each 
one. If not, check the master clock circuit (expect about 3.5MHz on the 
output of U8c) and the clock divider circuit. Without the correct clocks, 
the state machine can't possibly work properly

The easiest way to locate faults in the control logic is to use a logic
analyser to trace the operation of the state machine. The {\em Inverted}
form of the 5 state bits -- {\bf SMA(0)/}\ldots {\bf SMA(4)/} are
available on the test connector on the {\bf Control} PCB. Since the state 
changes on the rising edge of {\bf SMClk}, the analyser should be clocked 
on the falling edge of this signal so that it samples stable signals.

Two further comments are necessary. Firstly, if any of the state
flip-flops, U2a, U6b, U6a, U18b and U2b are faulty, the inverted signals
on the test connector may not reflect the actual signal being sent to the
state machine ROM. And secondly, remember that every state transition is
conditional, the {\bf CC} signal cannot be inhibited. Unconditional
transitions are simply the result of having the 2 possible next states
actually being the same. But if the input gates to the state flip-flops
are malfunctioning, the actual next state may (incorrectly) depend on the
{\bf CC} signal. If the state machine seems to go in an impossible
sequence, then investigate this area. 

\subsection{Character Input}

Connect the printer to a suitable machine, such as an HP9830, which can 
send individual characters. Use a suitable rod to operate the paper-out 
microswitch so that it appears that paper is loaded (if necessary remove 
the microswitch from the mechanism). It us helpful to have the printer 
standing on one side panel so that the test connectors on top of the PCBs 
and the {\bf Logic Backplane} pins are both accessible. 

It is useful to have a way to reset the printer electronics. A momentary 
SPST switch (e.g. a `push to make' button) connected between {\bf InitIn/} 
and ground on the {\bf Logic PSU}  test connector is a good way to do this.

Monitor {\bf IFFlg/} on the {\bf Logic Backplane} or interface connector
and send a printable character (other than a linefeed). If {\bf IFFlg/}
pulses low then the character input section of the state machine is
basically working. 

If  not, then if logic analyser is available, connect this to the {\bf 
SMA(n)}  signals on the {\bf Control} PCB test connector. Reset the 
printer and if possible set the logic analyser to trigger if the state is 
no longer 00. If the logic analyser does not support that sort of 
trigger, then trigger when {\bf SMA(1)/} goes to 0. 

Send a character as before and see what states the state machine goes 
through. If the sequence is totally crazy, then suspect a problem with 
the state machine flip-flops, the input gates or the state machine ROM 
itself. 

If no logic analyser is available, then monitor {\bf SMA(1)} with the 
logic probe. While this will not indicate anything like as much, it will 
at least indicate that he state machine is doing something as the machine 
leaves state 00.

If nothing happens at all when a character is send, then look at {\bf
Stb/} at the output of U22b on the {\bf Control} PCB. If that is not
changing state, then check to be sure that both {\bf PaperOut/} and {\bf
Feed/} are high. Debug the debounce SR flip-flops if necessary. Then
check {\bf CC} and {\bf CC/} (input and output of U1d) to make sure they're
behaving correctly. And then, check the state machine flip-flops, gates
and ROM. 

If the state machine appears to be running but {\bf IFFlg} never goes low, 
then check {\bf InClk/} on the {\bf Logic Backplane}. Reset the printer 
and send a character. if {\bf InClk/} never toggles then check the state 
machine output decoder U13 on the {\bf Control} PCB. If {\bf InClk} does 
toggle, then check U22a on the {\bf Data Path} PCB. If {\bf IFFlg} goes 
low and never returns high, then reset and send another character  while 
monitoring {\bf ClrFlg/} on the {\bf Logic Backplane}. If this signal is 
toggling, then check U21a, U21d and U22a on the {\bf Data Path} PCB. 
Again, if not, check the decoder U13 on the {\bf Control} PCB. Of 
course if the interface flag flip-flop U22a (on the {\bf Data Path} PCB) 
seems to be working correctly but {\bf IFFlg/} is not, then suspect 
the  open-collector buffer U20c.

Once the printer is working well enough to accept characters, there 
are  a few other signals that are worth checking. Of course it is now no 
longer necessary to reset the printer before sending each character. 
First check that {\bf SClk} is pulsing low for each character entered. If 
not, the fault is likely to be U20d or U13 on the {\bf Control} PCB. 
then check that the character counter is correctly incrementing after 
each character -- its outputs are available on the test connector on the 
{\bf Control} PCB. If not, then it is possible that the characters are 
not being treated as printable, check the input latch and the character 
testing gates U10, U16d, U16c and U16b on the {\bf Data Path} PCB.


\subsection{Paper Feed}

Reset the printer to clear all the counters and then send a single 
linefeed character. If you are monitoring the state machine with the logic 
analyser, check that it  does the transition form state 1B to state 15. 

In any case, the stepper motor should turn the rollers to advance the 
paper by one character line (if there was paper present). There are 3 
possible problems here : 

If the motor doesn't run at all (and, incidentally, {\bf IFFlg/} remains 
low) then it is likely that {\bf AutoFeed/} is never going low. Check the 
state  machine and its output decoder. 

If the motor advances one step and {\bf IFFlg/} remains low, then it is 
likely the state machine is stuck in state 09, waiting for the motor 
timing monostable to time out. You can check this my monitoring the {\bf 
SMA(n)/} signals with a logic probe. if this is the case, then check U22b 
the associate gates and the flip-flop U18a on the {\bf Control PCB}.

The last possibility is that the motor starts running and never stops. 
The general cause of this is that the condition at state 1F is always 
true, so the state machine stays in the paper  feed loop. Again, a logic 
analyser will prove the point. This generally means that the row counter 
or {\bf RotEn} on the {\bf Data Path} PCB is the problem. The counter 
outputs can be checked on the test connector of this PCB, {\bf RotEn} is 
the output of U19a.  If  the motor is running, then the counter should be 
incrementing on each step, this is 

\subsection{Print Cycle}

Now send a reasonably long line of printable characters (but fewer than 
80) and a linefeed. The correct behaviour is for the rollers to move by 
one character line but rather slower than before (as the printer is 
processing each dot row). As before there are several easily-spotted 
failure modes.

If the printer `hangs up' with {\bf IFFlg/} l;low having not moved the 
paper at all, it is likely that it is stuck  in the buffer-fill loop, 
states 17,04,08. The easiest way to   check this is with a logic 
analyser, if one is not available, continual {\bf SClk} and {\bf PHClk} 
pulses (at a third of the state machine clock frequency) are a symptom of 
this problem. Check that the character counter is incrementing and find 
out if {\bf Start/} is ever going low. Finally suspect the state machine 
condition multiplexer U14.

If the paper advances one dot row and the printer hangs then the state 
machine has entered the print cycle loop but for some reason it is not 
completing it. Again a logic analyser is the best way of finding out 
what the state machine is doing, the most likely problems are : 

It is stuck in the `shift by 4' loop at 07,1C, waiting for {\bf LnFlg/}. 
This can be detected with a logic probe by a continual stream of pulses on 
{\bf ForceSpace/} and nothing on {\bf SClk} (The latter distinguishes it 
for the buffer-fill loop). In this case, check if the output of U20a  on 
the {\bf Control} PCB  is toggling. If not, check this gate, if it is, 
investigate the 4-state counter U17a and U71b.

It is stuck in the transfer characters loop from 18 to 03. Generally  this 
means that {\bf NewBank/} is never being asserted. Check the character 
counter and the gates that produce this signal.  

It is stuck in the complete dot-line loop because {\bf Firstbank/} is 
never being asserted so the condition at state 0C never passes. Check U15c 
on the {\bf Control} PCB.

It is hanging in state 0A waiting for the timing monostable U26a (on the
{\bf Control} PCB) to time out. Again, this is easy to detect wit ha logic
probe as the state machine flip-flops will be static in that state. Check 
the monostable and associated gates.

If the printer starts to feed the paper and never stops, it is likely that 
{\bf Row7} is never being asserted, and this the condition at state 16 
never passes. Check that the row counter is incrementing and then check 
the output of U19b on the {\bf Data Path} PCB.

Once the print loop is basally functional, send the line of characters 
and linefeed again, and check {\bf PHEn}. It should be toggling. If not, 
check U24 on the {\bf Control} PCB. 

\section{Locating Data Path Problems}

In general problems in the data path are easier to find than those in the 
control system because, if the latter is working, the printer will accept 
characters and attempt to print them. Many faults can thus be located by 
examination of the printed output.

Begin by refitting the {\bf  Printhead PSU} PCB -- the only electronic 
section now not fitted should be the printhead. Power up, and check that 
{\bf PH+} is at about 20V and that all of the {\bf BankN} are `dead'. 
Now, with the paper out microswitch operated as before, send a line of 
text followed by a linefeed. After this, again check that all of the {\bf 
BankN} signals are dead. If not, Find  out why not before fitting the 
printhead. Check the {\bf PHEn/} signal. If it is stuck low, check the 
timing monostable  U24 on the {\bf Control} PCB. If {\bf PHEn/} is high, 
then check  the bank select NOR gates,  the drivers and the transistor 
array U8  on the {\bf Printhead Driver} PCB. Do not fit the printhead 
before curing such faults, a burnt-out printhead is not pleasant.

Now, power down, refit the printhead power up and load a roll of thermal 
printer paper\footnote{Thermal fax paper works perfectly.}. Check that 
that the 'Load'  lamp on the switch bracket has gone out, if not, find 
out why the paper is not operating the paper out microswitch.

Again  print a line of text (ending in a linefeed). This time something 
should appear on the paper, and there are several  possibilities : 

The printer prints correctly. There is not much more to do. Just refit 
the casing parts and enjoy hard copy output on the HP9830.

The entire line is blank. This normally means the printhead is not being 
driven. Check {\bf PHEn/} and the bank select gates. No data being loaded 
into the dot shift registers on the {\bf Printhead Driver} PCB can cause 
this (it can also cause this, so check {\bf PHClk}. Of course the printer 
might be printing space characters in all positions dues to a problem with 
the input latch or the data shift registers on the {\bf Data Path} PCB, 
but this is rare. Also rare, fortunately, is a  totally data character 
generator ROM which can produce either entirely blank or entirely dark 
characters. 

If every fourth character is blank, it suggests that the associated {\bf 
BankN} signal is never being driven. Check its driver transistor in U8 on 
the {\bf Printhead Driver} PCB and the associated gates.

If the same dot column of every character is either blank or always dark, 
then the problem is most likely in the dot data path. Check the appropriate 
{\bf PHData(n)} signal on the test connector of the {\bf Data Path} PCB. 
If it is not changing state during the print cycle, then check the 
inverter that drives it and the character generator ROM. If {\bf PHData(n)} 
is toggling, then check the inverter that receives that bit on the {\bf 
Printhead Driver} PCB ,ad the associated dot shift register.

If characters on the right side of the printout are correct, but those on 
the left side have either missing or dark dot columns then most likely 
the dot shift register for that bit of {\bf PHData(n)} is defective. 
Remember that characters are loaded from the right hand end of the line 
(so that the first character ends up being shifted all the way to the 
left), so a fault in the shift register that stops the bits flowing any 
further will cause this fault.

A single missing dot column is most likely due to a problem with that 
printhead. Assuming a replacement printhead is unavailable, it may be 
best to move the defective one to the rightmost position and try to only 
print short lines.

If some or all characters are printed wrongly but are still valid character 
patters, then the problem is most likely in character code data path. 
Check the input register flip-flops, the data storage shift registers and 
their input gates and the character generator ROM. 

If the first dot row of the line is correct, but subsequent rows are 
wrong (particularly if only wrong for some character codes), then suspect 
the recirculation gates on the shift registers. 

If the first line is correct but subsequent lines have their dot patterns 
rotated to the left (in 4 character increments) then the problem is most 
likely in the control system,m. Check the {\bf char0} signal and ensure 
that the state machine correctly skips the rotation loop at the end of 
each dot line. 

Minor defects in the characters such as missing or extra dots are most
likely due to the character generator ROM. Since this is an HP custom part
(it is a mask programmed ROM of a similar type to the ROMs used in the
HP9800 calculators), it may be simplest to live with this problem if it is
not too severe. 


