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.