Explanation of (and fix for) TD8-E reliability problems
Excerpted from a UseNet posting by Charles Lasner
----------------------------------------------------------------------
    If  a TD-8/E is used at the highest level DEC designed it for
(highest ECO  level),  then  certain  programs for the TD-8/E are
still unreliable.   The  excuse  for  this was turned into a "bum
rap" on the entire  beast.    The design limits of the TD-8/E are
well  known;  living within  its  limits  should  cause  reliable
operation.    Ultimately, all TD-8/E problems  stem  from  either
improper  maintenance,  slightly  flakey  software  which can  be
rewritten and sometimes was, failure to implement known  ECOs  to
the hardware, or curiously enough this "non-ECO" I and  a  friend
of mine personally uncovered.

    Despite  being  derailed    several    times    by   software
"witch-hunts", the problem was  finally revealed as the following
mistake:  certain TD-8/E programs,  such  as  the OS/8 12k system
handler require a valid feature of the TD-8/E to work, namely the
SDLD  instruction  should load the data register,  and  also  NOT
clear the AC.  The software reasoning for  this  is that the SDRD
instruction  can  read  the  data back later, so a  parameter  is
passed in the register, and it is also needed immediately  in the
AC.   Properly  "protected"  from  unwanted conditions, this is a
valid technique, as  long as the instruction works as documented.
Most existing programs really  don't  care what happens to the AC
in this case, and they  deliberately  clear  the  AC  since  they
"know" SDLD doesn't do this.   Due  to  a  hardware  "glitch"  in
design, the AC WILL occasionally clear!

    This is why this problem is never seen by users of either the
MR-8/E-C ROM TD-8/E system,  or any non-system handlers.  For the
users of the 12k system  handler,  I  have  heard  various horror
stories:  One user was under  DEC field service contract who paid
expensive 1970's money for continous down-time of  over  9 months
of  DEC trying to fix the problem unsuccessfully.    The  primary
repair person said that the problem was that he  had  to  replace
the  entire  CPU,  even  though  several  attempts  at  this were
unsuccessful.  This  person  was  actually  ALMOST  RIGHT!

    The actual problem is an invalid  timing  relationship in the
logic that governs which TD-8/E instructions will  clear  the  AC
and which will not.  There is a collection of gates which control
the "clear the AC" control line (C0) as a  function  of which IOT
is executed.  There is a "hole" in the logic  in  that one of the
controlling signals is not properly delayed sufficiently.  On any
system where the  buss is physically "long", i.e., in two Omnibus
blocks,  a  glitch  appears   on  C0  when  executing  SDLD.    A
fascinating analog display occurs if  you  'scope loop SDLD;  JMP
.-1 and connect to C0.  A tall spikey glitch occurs in the window
of time that C0 is read by  the  CPU  for AC clear purposes.  The
amplitude and width is very unstable, but the  'scope loop catchs
it with ease.  The glitch may or may  not  be present in one buss
machines.  It appears to also be CPU-dependent, so 8/A  users may
or may not see this (I never checked at the time;   didn't have a
KK-8/A available back then.) and perhaps certain KK-8F board sets
were more immune, thus the repairman's dillema above.  Installing
EAE may change details  of  the  glitch.    This  logic  is  even
highlighted in the maintenance manual,  which is filled with "how
does  this  sub-section  work"  documentation,  an   elegance  of
documentation perhaps, but in this case, it doesn't work!

    The problem, once isolated, is trivial to fix.  One way is to
place a capacitor across one of the gates to ground, to slow down
the signal a little;  this method  is  a little kludgy because it
uses  an  "analog"  property  of  the  chips,  which   might  not
duplicate.   Breaking a line and inserting a resistor  will  help
this slightly.  A better way is to insert two  inversions  in the
logic  path using available spare gates.  It takes a little  more
cutting  and  soldering  but  is the reliable fix.  If it were  a
manufacturing ECO,  they could fix it merely by re-laying out the
PC  board  without  additional  components.    Once  the  fix  is
accomplished, the TD-8/E became  totally reliable again, even for
the harried 12k user.

    Other TD-8/E areas of unreliability stem from bad maintenance
of the drive  itself;    following  all  ECOs solves the problem.
Unlike the "automatic" controllers (TC01/08/11, etc.), the TD-8/E
expects the software to "keep  up"  on a word-by-word basis.  The
nominal time for a word is  133  microseconds.  Due to cumulative
software overhead, especially in the ROM system, there isn't much
spare time over 133 microseconds available, especially at certain
key  points  in  the  transfer  such as the last  data  word  and
checksum transfer.    The  automatic  controllers  can  deal with
transfers that are 20-50% faster than expected, but this software
cannot.  Failure to  follow  the drive maintenance and mechanical
ECOs will yield more than  merely premature failure of media (and
possibly destruction of heads, which should  theoretically  NEVER
wear  out due to the air-bearing design  (read  NO  head  contact
here!) as long as you keep it all  clean.),  but  also unreliable
operation.  The same tapes brought to automatic controller  sites
work fine.

    The reason is that most mechanical problems  yield  some form
of minor wear or dirt which causes friction.  This causes "jerky"
motion on a "microscopic" level.  If you look  at  head data on a
'scope, the data arrives less "smoothly" such that some words are
stretched, while others are shrunk in time.  This means that  the
worst case time for a word could be too short for the software to
keep in  sync with, so there are occasional failures.  This could
even lead to  "deformatting"  of  the  tape  in extreme cases.  A
well-maintained drive will deliver  data  for decades with little
jitter, thus allowing the software to perform adequately.

    Except  for the ROM-based system (which today most users need
not use  because  they  now have the memory in their machines for
the 12k system),  the  software  such  as  OS/8  handlers  can be
improved to be even  more robust and defensive against the jitter
problem.  I am the  principal  author  of  an alternate operating
system for the PDP-8, known as  P?S/8.   Perhaps some of you have
heard of it, but that should be  a  separate  discussion.   (This
TD-8/E example is already too much of a  digression  from  Todd's
question!)  The  P?S/8  usage  of  the  TD-8/E  includes superior
handling  of  some  of the timing-critical transfer states of the
data  transfers.  The P?S/8 handler is so much better than  DEC's
OS/8  handlers that TD-8/E P?S/8 can be run on a PDP-8/L equipped
with a DW-8/E!   (Except for ONE handler feature:  P?S/8 handlers
are designed to work  with interrupts on.  The TD8/E handler uses
the SKON instruction to turn  off  interrupts  during the handler
oeprations, and then restore it at  the end of the handler.  This
instruction isn't available on machines prior to  the  8/E.  OS/8
Fortran IV maintains a table of devices which  can't tolerate its
interrupt  structure,  so  they avoid calling the TD-8/E handlers
with  interrupts on;  other programs aren't as elaborate, so  the
more general-purpose  P?S/8  method would be better if available,
but, alas, only  on the PDP-8/E, F, M, A.)

    If there  is sufficient user interest AND I have enough time,
I may rewrite the OS/8 handlers to use the same techniques as the
P?S/8 handlers, perhaps even  incorporating the SKON technique if
there is sufficient room.   PIP10  would also require some fixes,
since it uses an internal TD-8/E handler for the PDP-10 DECtapes.
I can pass along the ideas I  used  to the more "impatient" users
who wish to solve this problem sooner.   (I spend most of my time
writing  other  things,  mostly  -8  code  for  1990  money,  and
maintaining KERMIT-12, etc., as well as P?S/8 itself.)

    Ultimately  there  are only three things you can't do with  a
TD-8/E over a TC01/08 system:

1)  You  can't  use  unrestricted live interrupt systems with the
TD-8/E since  it  doesn't  support  interrupts  at  all,  and the
software has no "extra" time during the data transfer.  This does
not  preclude  "dead-reckoning" searching  with  interrupts  from
other devices during the search phase.

2)  You can't write a one-page handler  for  it, but two pages is
adequate, so OS/8 mostly "likes" the device.

3)  You  must   ensure  that  simultaneous  DMA  virtually  never
happens.  This  means  things like running VT-8/E displays (P?S/8
allows TINY text messages  on  the  top line of the VT-8/E during
the TD-8/E handler:  the  screen  merely says "WAITING" while the
handler does its work.), or RK8Es, etc.  This is why RTS-8 cannot
unconditionally run on a TD-8/E system.

These limitations are purely a result of  design trade-offs.  All
other obstacles can be overcome by following the  "rules"  of the
game.
