Subject: Why a DECmate isn't a PDP-8 From : lasner@watsun.cc.columbia.edu (Charles Lasner) Date: Mon, 1 Mar 1993 18:39:56 GMT This newsgroup is primarily for PDP-8 family stuff, and will therefore support DECmates as well. But a DECmate isn't *quite* a PDP-8 as we know it. Certain problems thwart the prevailing software from running on it, and instead some "bastardized" versions have appeared (such as OS/278). This will be the first in a series of articles to detail the areas of incompatibilty and what can be done about them. 1) CPU issues. The DECmate is based on the 6120 micro version of the PDP-8. It is mostly compatible, and includes the powerful extension of CP memory and related hardware, dual push-down stacks, etc. Certain instructions have minor differences such as the exact definitions of the PDP-8/e-originating superset instructions GTF and RTF. The differences are so slight that the existing software for PDP-8/e interrupt handling will just work, but certain diagnostic programs will likely fail on these specific points. There are differences such as: PDP-8/e RTF does not clear the AC afterwards; 6120 does. This is even a useful improvement as there is no software reason not to clear the AC at that point. (The AC is being loaded from a temporary to restore the former status saved during an interrupt. Then the AC has to be loaded with the former AC value, thus a CLA after RTF is in all practical 8/e code. The RTF performing its own clear thus allows a 6120-only interrupt handler that is shorter/faster.) PDP-8/e GTF reads back the state of interrupt into bit[4]. PDP-8/e RTF ignores bit[4] and re-enables the interrupt. 6120 GTF reads back a one into bit[4]. 6120 RTF loads interrupt enable per AC[4]. For normal interrupt handling for PDP-8/e, this sequence is essentially compatible enough. Note that classic PDP-8 interrupt handling is totally compatible on all models, but that there are PDP-8/e and newer interrupt routines, etc. The use of extended memory instructions on the PDP-8/e is compatible with former processors, but can be extended via the KT8A or CESI MEC8 extensions. The 6120 is only compatible with the subset found on the PDP-8/e without those extensions because other instructions have been assigned to the same IOTs. These include new instructions such as GCF (Get Current Fields) which is essentially the non-interrupt-oriented version of GTF, etc., and a set of instructions only valid in CP memory to handle that section. Some of the instructions are defined for CP memory trap, and others are for manipulating the built-in dual stack. As long as the program sticks to the compatible subset found in a 32K PDP-8/e, the instructions are otherwise compatible. 2) Console issues. On I/O, the 6120 largely parts company with the PDP-8/e. The actual implementation of I/O on the DECmate consists of using packaged interfaces usually called "pie" chips (or Programmed Interface Elements). The problem with these chips is that they are only *almost* compatible with existing PDP-8 interfaces whereas the prevailing OSes demand *total* compatibility with the older hardware. There are several internal interfaces within the DECmate for particular use of no concern to the OS, and this is not at issue, such as the internal interface for the keyboard which is actually on an additional serial port (bidirectionally) or the APU/XPU interface, etc. PDP-8 compatibility demands that the device 03/04 instructions be truly compatible. On the 6121 PIE chip, liberties were taken with the design that cause out-and-out incompatibility such that only trivial programming examples still work, while the actual usage within the operating system is totally incompatible. A breakdown of the console instructions: 6030 Clear the keyboard flag, do not advance the reader if a TTY: is the console device, do not clear the AC. The 6120 version of this is to *set* the flag! (This instruction is not used on earlier models, so compatibility issues aren't as bad as it sounds!) 6031 Skip on the keyboard flag. Notably, the PDP-8 convention is that this instruction work *precisely* as stated. Specifically, 6031 must skip if the flag is set. Repeating the instruction must repeat the same effect. On the 6120, 6031 executes as skip on *and clear* the flag, thus 6031 when repeated is totally incompatible, because the flag won't raise until the data is read. PDP-8 OS compatibility demands that the 6031 repeat facility be present. Without this, various programs, handlers, and all BATCH operations are incompatible. OS/278 consists of a bunch of wimpy emasculated versions of cusps that either don't work properly, have existing bugs to be fixed, or kludges to create the perception of ^C and/or ^S/^Q handling being present correctly, but in point of fact, it is 100% deficient in this area. When OS/278 is run on an actual PDP-8, it behaves as poorly since it can't take advantage of the proper console interface, instead sticking to the subset where 6031 cannot skip repeatedly, etc. 6032 Clear the AC, advance reader run if a TTY: console, clear the keyboard flag. On the 6120, 6032 merely clears the AC. Since 6031 clears the flag, they didn't bother to make 6032 accomplish it. However, 6032 on the 6120 will allow the flag to raise for the *next* character since the interface is both buffered and simulated. Due to hardware limitations of the DECmate, it is not possible to re-implement the simulated console interface any better than currently provided. The base reason for this is that only the "even" IOT's are trapped and emulated while the "odd" IOT's are allowed to be used in hardware. Had the entire interface been trapped, we could emulate the compatible version! 6033 NOP This IOT is essentially reserved for situations where the interface baud rate could be programmed, but doesn't apply in the case of either the PDP-8 or the DECmate. 6034 Read the latest character, do not disturb the flag. The data is logically ORed into the AC. This is used to notice that the data is a ^C or other character without disturbing the flag, so that other software can check it again, after being swapped in. (It's used in conjunction with 6031 which doesn't clear the flag when it skips.) The 6120 version of this instruction is to OR into the AC the *previously read* character provided by either 6032 or 6036, but it cannot initiate a new character by itself. While it is of marginal utility to be able to re-read a previously read character, the inability to read in the latest character without disturbing the flag is the crux of the compatibility issue. 6035 Load interrupt enable for devices 03/04 per AC[11]. On the 6120 this is changed to device 03 only. The 04 function is handled by 6045. Since this is a PDP-8/e instruction, it is not a serious compatibility issue except for initialization routines that use interrupts. However, since the keyboard is emulated on the DECmate, interrupt timings may prove "choppy" compared to a real PDP-8, and interrupts to the console are not recommended. 6036 LOAD the AC with the latest character and clear the flag. Also enable reader run if the console is a TTY:. Essentially this is the OR of 6032 and 6034. The 6120 still ORs together the two operations, but the underlying two operations aren't compatible, since the flag is unaffected. However, reading the character will cause the next character's flag to raise (when available). If 6032 or 6036 is not executed, then the flag will *never* raise even if the user pounds on the keyboard! (There is an OS/278 ODT bug related to this which is fixable per se, but not the ^C handling as described above.) 6037 NOP 6040 Set the output flag. Actually compatible on 6120! (And not needed for compatibility with earlier machines that didn't have it.) 6041 Skip on output flag. Like the input flag, the 6120 also clears the flag when issuing 6041. There is less of a compatiblilty issue since it is possible to write code that doesn't depend on the second skip, as long as you time out the flag in any initialization code. (P?S/8 has always done this in the past; OS/8 tends to not overlap the console I/O so therefore the skip on flag gets checked after outputting not before, so this is good enough for most routines.) 6042 Clear the output flag. On the 6120 it clears the AC. Usually the AC contents is unimportant during 6042, so not a serious compatibility issue, but diagnostics will fail. 6043 NOP 6044 Output the character, do not clear the flag. Same on 6120, but since the output routine is emulated, the flag will immediately be up when the program is running after the trap. On a real PDP-8, the flag comes up one character time later after it's actually sent, not immediately. This could affect some interrupt routines. Again, interrupt handling of the console is not recommended on the DECmate, especially on the output side. 6045 On the PDP-8/e, this is skip on input OR output flag raised AND interrupt enable in the device. Useful to cause interrupt polling routines that have to favor other devices to have less overhead. If the device actually has the flag raised, then you have to do a few extra instructions, but when the interrupt is elsewhere, it lowers the latency. On the 6120, this is replaced with load interrupt enable for device 04 only per AC[11]. Since this is an extension beyond the basic interface, this is a compatibility issue for interrupt-driven PDP-8/e and newer routines only. 6046 Output the character and clear the flag now, causing it to raise later. On the 6120, the instruction is trapped, so the net result is to raise the flag when the trap handling is over and execution resumes. Causes interrupt routines to always be entered and no background processing to occur during the simulated interrupt handling, which is not recommended. Non-interrupt programming is not affected by this aspect of compatibility however. 6047 NOP So, in summary, console handling is severely incompatible with regard to keyboard handling, and moderately incompatible for screen handling, most notably in regard to either flag initialization and/or interrupt handling. Yet, simple-minded examples from Introduction to Programming will more-or-less work; "live" OS routines cannot work. I am working on a replacement system to be known as OS/8 Version 5, which will work within the available subset and thus will run on all models. However, existing OS/8 cannot work on the DECmates, and OS/278 cannot perform many functions found in OS/8. Next time, more info on other compatibility issues. cjl