From lasner@watsun.cc.columbia.edu Tue Sep 24 03:35:41 1991 Flags: 000000000001 Return-Path: Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA04188; Tue, 24 Sep 91 03:35:39 EDT Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB) id AA27183; Tue, 24 Sep 91 03:32:54 EDT Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12901; Tue, 24 Sep 91 03:02:14 EDT Received: by watsun.cc.columbia.edu (5.59/FCB) id AA03967; Tue, 24 Sep 91 03:02:11 EDT Date: Tue, 24 Sep 91 3:02:10 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Message-Id: From: Charles Lasner (lasner@watsun.cc.columbia.edu) To: PDP8-LOVERS@ai.mit.edu Subj: TD8E versus TC01/08 and other sordid remarks There has been a whole lot said (or implied) by various members of this group regarding the TD8E. Some of it raises some issues that should be de-mystified, etc. The TD8E is an *economy* version of a DECtape drive/controller. Its only purpose is compatible data interchange with sites using TC01/08 and other TD8Es. Many applications meant for use on a machine with a TC01/08 or other disk devices *cannot* function with a TD8E. These include any application that uses either interrupts *or* DMA. Further, the handler code for the TD8E is larger and causes trade-offs in performance that are not encountered in the TC01/08 versions. Using additional hardware coupled with appropriate software can partially overcome some of these problems, but none of this is in current use. Let's examine some of these issues in detail: The TD8E reliability problem. The TD8E is intrinsically less reliable than the other tape systems because it requires mechanical maintainence of the drive to a degree not required for use with TC01/08. Curiously, this means that the TD8E is a good diagnostic tool for maintaining TU56 drives used on TC01/08, since running adequately on a TD8E guarantees reliable performance on a TC01/08 :-). Most of this problem stems from the following: The TD8E requires the PDP-8 to be in close sync with the gyrations of the tape in terms of instantaneous timing. The design of DECtape in general is such that small to moderate speed changes occur constantly. This is caused by friction in the tape heads and guide interface and is normal for a drive in good working order, or at least up to a point. Dirt, wear, sticky oxide contaminating wear surfaces, etc. are all normal facts of life in a DECtape drive. The rear cheek plates will tend to wear a thin score line at the tape path which builds up walls of oxide making the effective depth of the "trench" much larger unless the oxide is removed often. Ignoring this last problem will also make the actual score line deeper sooner as well. The media also tends to slowly wear at the edges because of the rubbing, which causes the tape to be less stable when passing over the head. Severe wear situations sometimes cause the tape to have fluted edges which interferes with smooth tape motion severely. All of these factors together add up to an instantaneous jitter factor in the transfer of data off the tape. The TC01 and TC08 were designed to handle this jitter and can actually deal with situations where the nominal 133 microseconds per 12-bits transfer is deviated from by as much as 100 percent. Thus data can transfer in as little as 66 microseconds or as much as 266 microseconds depending on the frictional factors. Note that the average tape speed is fairly constant, merely slightly increasing or decreasing as the effective tape diameter changes with overall tape position. Anyone who has ever looked at the timing track output of a TU55 or TU56 drive directly on an oscilloscope will understand this phenomena correctly. The TD8E problem is that a critical software loop tries to keep in sync with the data transferred during these potentially jerky transfers. The longer transfers aren't problematic, just the shorter ones. However, the software *never* includes timeout checks, so the coding is ignorant of the fact the timing is getting erratic. On the TC01/08, the data separator circuit can issue a timing error if the data becomes either too slow or too fast. (The so-called TIMING error is actually the OR of these and several other conditions, including an inability to accomplish a DMA cycle in time as well, etc.) I guess this means that the TC01/08 is a good diagnostic tool for maintaining TU56 drives for TD8Es :-). The reason there is no time-out checks in the TD8E code is because there is no time to handle the overhead of the counting! TD8E handlers are highly compromised for many other reasons, and can't afford more overhead, even if it would make transfers more trustworthy, etc. This is because of those short-cycle transfers described above. Should a short-cycle data transfer happen during a phase where the code is "overloaded" easily, then an undetected error will happen. It is conceivable that the tape can become deformatted at this point if timing is lost while writing. This is impossible on the TC01/08 because the hardware shuts down all transfers when *any* error occurs, so the TIMING error prevents problems. But all existent TD8E code lacks timeout checking for too-short and too-long transfer times. Examining the prevailing TD8E handlers reveals some exceptionally weak areas prone to problems: The ROM-based TD8E handlers are little more than setup routines for the code contained in the MR-8EC ROM. This allows the handlers to occupy one page, pretending that the TD8E is a "smart" device, and that memory ends sooner than FIELD 7. This code is very inefficient because it resides in FIELD 7 yet uses temporary storage in FIELD 0. The cross-FIELD overhead really hurts in terms of potential data loop overload due to jitter. The OS/8 12K system and non-system handlers are not really much better because there is a critical time when the forward checksum is being calculated and then written where timing can easily be disrupted by a coincidently short jitter-disrupted cycle. On a side note, I have partially solved the last problem in the equivalent P?S/8 TD8E handlers because I have invented a slightly longer piece of code (two instructions longer) that greatly improves the chances of a reliable read in a jittery situation and may slightly improve writing reliability. It is conceivable that by use of other more efficient coding tricks enough space can be bummed out to add this feature to the OS/8 handlers (other than the ROM). All current software handlers are superior to the MR-8EC ROM code in another way: the checksum calculation is more efficient in the software than the ROM because the ROM is a mediocre adaptation of an early (and obsolete) version of the software. All software was upgraded to use a more efficient coding technique for the checksum calculation which recognizes that the EQUIVALENCE operation is merely the inverse of the EXCLUSIVE-OR operation. The ROM-based code actually (and wastefully!) bothers to invert the data in numerous places to naively and incrementally implement what the TC01/08 does in hardware. The better software merely XORs the data and fixes up at the end only. The resultant tighter code adds to the jitter immunity (albeit slightly). The P?S/8 versions are also slightly more efficient on this point as well (only a couple of cycles saved, but each one helps :-)). It should be noted that DEC distributed an "offical" TD8E subroutine in source form to allow users to access tape blocks independently of OS/8. This early code is where the poor ROM techniques originated. This code can be upgraded to take advantage of all newer software experience. The TD8E hardware bug. It should be mentioned in passing that there exists a disastrous hardware bug in the TD8E that only affects the 12K system handler for OS/8. This bug is totally fixable using only a razor blade, wire and soldering tools (etch add/deletes only, no components), and has been documented elsewhere. DEC never discovered this problem so there is no "official" DEC ECO available to implement it, but it should be considered mandatory. It is conceivable that the 12K system handler can be redesigned to eliminate dependancy on the affected hardware being functional, but the official version is totally at risk. The bug only appears in certain hardware configurations and is probably dependent on such seemingly irrelevant parameters as: a) Bus slot where the processor and TD8E cards are plugged into. b) Whether there is one or two Omnibuses in the box. c) CPU revision level. d) Whether there is an RK8E present unless it is fully ECO-ed according to DEC specifications. This corrects a known interaction where the TD8E fails to operate because the RK8E partially wakes up erroneously. The RK8E seems to also interact slightly with this problem as well. e) Whether or not there are dirty or clean gold fingers on the TD8E card. Amazingly, a dirty TD8E might not glitch while a clean one will! f) Whether or not EAE is installed. The glitch may occur either way or may reduce by removing or adding the EAE cards. g) Power supply voltage settings and ambient temperature. The hardware problem is due to a marginal timing error in the design of the TD8E which allows a potential attempt to clear the AC being erroneously generated during the SDLD instruction. While inadequate in width to be reliable, this glitch can occasionally succeed in clearing the AC. A tight software loop such as SDLD; JMP .-1 will display the glitch on an oscilloscope connected to the C0 buss line (C0 grounded means clear the AC during output IOTs). Changing any of the above parameters may influence the analog properties of this waveform due to its "illegal" nature. From a software perspective, the bug is that the SDLD instruction which loads the AC into the data register should *NOT* clear the AC, yet it *sometimes* *DOES* !! Only the 12K system handler cares about this because the code uses the data register to pass a parameter between sections of coding. This is essentially legal on working TD8Es because the data is always valid for 133 microseconds nominally, and indefinitely if the tape is not moving. (The code assumes the tape is not moving or is deselected at the time which is barely acceptable.) All other code deals with the AC as being "dirty" after this instruction so the AC gets cleared afterwards deliberately thus avoiding the problem. (A case could be made to change the TD8E so the instruction *always* clears the AC so the code can be tightened up, but this would then be an incompatible device :-(. The OS/8 12K system handler would *always* fail instead of mysteriously sometimes failing.) TD8E-inflicted system weaknesses. The TD8E supports no interrupts because the overhead of an interrupt handler is sufficient to cripple any potential code, even if the TD8E were to be handled as the prime interrupt candidate. Thus any application that requires interrupts be enabled can't run any TD8E code, be it OS/8-provided code or user-written because of the overhead of a potential interrupt during a critical TD8E event. A complex system can be created where interrupts could be allowed during the search phase of the TD8E operation, where the worst-case penalty would be missing the correct block necessitating reversing the tape direction, rewinding, reversing again and retrying the search. It still is necessary to prevent interrupts during the data transfers. The P?S/8 TD8E system handler implements a pseudo-interrupt feature that can be added to OS/8 if space permits. Both ROM and non-ROM P?S/8 systems support the feature. The SKON instruction is used to prevent interrupts during the entire handler process time, and then restores the former state of interrupts when the handler exits. This makes the code dependent on the 8/e or better CPU instruction set. Considering the jitter problem, it is not recommended to attempt to run the TD8E on slower machines, but the KK-8/a PDP-8/a CPU can be attempted on an 8/a system. (Without the SKON instruction, it is possible to run the P?S/8 handler on an 8/l using the DW8E option.) Use of DMA overlapping with TD8E operations is not recommended, but there is no direct way to inform a handler that other devices are actually doing DMA. OS/8 in general lacks this problem relative to standard programs using only OS/8 handlers because OS/8 handlers never cause interrupts (although some tolerate being interrupted by other devices) and there are *never* any concurrent operations. Several devices use coding tricks that depend on this fact so they can use the 3-cycle addresses of the TC01/08, TC-58, and DF32/RF08 as temporaries. For example, the TD8E system handler uses 7750-7755 as temporaries because no RF08 operation is allowed (within OS/8) to overlap with the handler's usage of these locations. Solving the TD8E problems. If the KG8E is available, a TD8E handler can be written to use it for checksum calculation. This would greatly relax the TD8E timing in critical areas, and would possibly allow for the implementation of time-out checking and/or limited interrupts and DMA during TD8E operations. Clearly the code would be shorter to accomplish the same functions as well as faster, so the other "tricks" should be easier to fit in. The resultant TD8E code would not function without the KG8E, but overall tape format would remain unchanged. Performing all known ECOs to the drives is *highly* recommended because the jitter is substantially lower for an ECO'd drive, especially after the drive has been used for a few years. It is certainly compelling to want the TD8E over the TC01/08 considering the added complexity of a pos/neg bus interface and the overall bulk of the TC01/08 itself. It is disappointing to note that DEC did implement a TC8E Omnibus DECtape controller to the prototype stage, but never sold it. It was totally compatible with the TC01/08 and a frill feature was added: as in the PDP-11 controller, it was possible to make the data transfer complement obversed when transferring while the tape spins backwards, so the transferred data words would appear in reverse order, but with correct data values otherwise. This is *not* compatible with the TC01/08 which just let the data come in complement obversed without correction when transferring backwards. Since this was an option, it could be defeated for programs that depended on the "old" way. I believe there was also a third-party announcement of such a device, most likely Computer Operations, but sales were undoubtedly minimal. Most TC01/08 users won't deal with the TD8E because they have the better controllers in place. Serious use of the TD8E is possible but demands dealing with the issues raised here. cjl