Descriptions of various PDP-8 operating systems and environments Excerpted from an email message from Charles Lasner ---------------------------------------------------------------------- paper-tape: Programs that use nothing more than the console terminal (device 03/04, generally a teletype), and possibly some specialized non-OS hardware such as lab peripherals. Elegible programs consist of LAB-8/E 8K BASIC, original FOCAL, 1969, etc. The main point is stuff free of any OS requirement, etc. Often this level of stuff becomes the starting point for a variant version, for example P?S/8 FOCAL, which retains as much as possible of the highly documented original's features and absolute compatibility, yet also includes features directly tied to the OS environment, such as the ability to execute FOCAL programs stored in P?S/8 ASCII files. The P?S/8 version does NOT belong in this category. DECUS theoretically has hundreds (not quite a 1000) of these. All that is needed is that the writeup be typed up into an ASCII file, and the program provided in a transcription of the original binary format, such as an ENCODEd file, or, if available, the source, possibly updated in terms of comments, etc. A side issue: years ago, the -8 didn't have an assembly-language "style" of its own, because of all of the clumsy and ugly teletype interaction, so people tended to type up the minimum that would work. Eventually, a major step backwards occurred: someone at DEC wrote the infamous "format generator" program that read paper tapes and punched out new ones based on the input. The problem is that the format was lame and inconsistent with the syntax. Further, it wound up as the example on one of the Introduction to Programming/Programming Languages handbooks using a short piece of code with an opening comment: "THIS IS AN EXAMPLE OF INPUT TO THE FORMAT GENERATING PROGRAM" followed by the incorrectly "standardized" coding of a short dummy program. This little mess was literally on the front cover! This created a whole generation of users with regimented bad habits :-(. Eventually, the "standard" format won out, so all "relevant" code has been upgraded to the modern consistency (such as found in KERMIT-12 source code written by me). But you occasionally find the old junk. So, a proper submission to the archive might be a DECUS writeup of say, 8-xxx where xxx is the original number in DECUS, said writeup in "nicely" formatted ASCII, and the source program with corrected source conventions, and possibly augmented comment fields. Some programs were binary only originally, but sources are now possible, by disassembly where necessary. This is no big deal; I have disassembled two complete 4K DECmate ROMs (DM II early and DM III) in the last three weeks. This is over 8000 lines of code. Most of these little programs are 1-3 PDP-8 pages long, not 32 pages. Some are only 50-100 lines of code altogether. All other files "belong" in some way to an operating system for the LINC, LINC-8, PDP-12, or PDP-8 or newer model, PDP-5, VT-78/IM6100, or DECmate/6120. These files have to organized in the appropriate way necessitated by the parent system. Here are most of the categories (there may be more): CPS An obscure system for LINC-8's; it was the original system slated for DEC to use as the prototype for OS/8. Fortunately, this never happened :-). In any case, pieces of this system have some relevance and are available. 4K-CPS An incompatible subset of CPS derived from it to run on 4K LINC-8's. This is a PDP-8-only system, and also runs on newer machines outfitted with user-constructed hardware, which is basically a user-created clone of the tape controller of the LINC-8 as a positive bus peripheral. All CPS-related work comes from Cooley Laboratories, hence the name Cooley Programming System (CPS). All known 4K-CPS files are very much available, but in poor shape because of source syntax format as discussed above. (Over the years, there have been several partially successful efforts to create TECO macros to mechanically fix the sources; what is needed is a replacement working off of a spec. I would be happy to write such a spec if anyone is interested in doing such a program in C or whatever.) LAPx The name for a family of systems where x=4 or 6 typically. Sometimes there is a suffix such as A or -3L. The fanciest of these is LAP6W, sometimes known as WISAL. (The name derivation is that the system is an automation of an assembler, so LAP stands for Linc Assembly Program. I agree that the motive of naming a system merely for its ability to assembly source files is somewhat misguided, but in any case that's what they did. The University of Wisconsin decided to call theirs Wisconsin Assembly Language or WISAL, but in keeping with the LAP convention, released it as LAP6W. Versions of these systems exist for the LINC, LINC-8, PDP-12, and even some non-DEC LINC versions (B. D. Spear's micro-LINC 100 and 300). They all use "standard" LINCtapes, but with different particulars in the formatting occasionally. DIAL This is the PDP-12 system, sometimes known as LAP6-DIAL. Display Interactive Assembly Language is how DEC derived it. There is also a compatible subset called 4K-DIAL, which is used to create the 8K "standard" version. When applied to more than just LINCtapes (or at least the CAPABILITY of doing it), the system is known as DIAL-MS (Mass Storage). COS This is the world of PDP-8 DIBOL, and is sometimes known as DIBOL-8 or COS-300 or COS-310. Some versions are for any -8, others for specific machines or hardware when so configured (such as DIBOL-12, which is merely a LINCtape bootable version of DIBOL-8). Newer versions are known for "burning their bridges behind them" and only running on the "latest" hardware of the time. The last versions are only usable on DECmates :-(. DM The so-called Disk Monitor system is the only DEC-official system for 4K. (4K-DIAL runs on 4K PDP-12's only; DM runs on any -8, even an 8/s.) It is known for efficiently using a DF-32, but also for being very cumbersome and quite slow. It was demonstrated that a high-speed papertape reader/punch in the hands of a skilled operator of PAL III, EDIT, and the BIN and RIM loader, can develop programs (not for mass storage systems, just cpu and incidental peripherals, such as lab stuff, etc.) FASTER on papertape than the Disk Monitor can on DECtape :-). TSS8 Some aspects of the Time Sharing System for the -8 are based on DM conventions. I understand that later versions supported not only DM DECtapes, but also various "foreign" tape formats from OS/8, -11, and also some TSS8-specific archive formats, etc. TSS8 basically simulates multiple 4K PDP-8 environments, but I understand there was some later activity to support more memory, and even run OS/8 under it. OS/8 This is the "family" where most activity occurs, because the largest group of users were/are exposed to it. Often, they were/are ignorant of the existence of any alternatives, especially because DEC actively marketed it for many years, while de-emphasizing other systems and avenues of usage. (DEC doesn't make money telling you to get a DECUS program for free :-).) There are several "layers" to OS/8, so there will be sub-categories. Part of the problem is that OS/8 eventually lost its discipline as programmers left DEC. Newer versions can't run on older hardware for stupid reasons. The last system relatively free of a) bugs, b) hardware-generated incompatibilities (inadvertant use of instructions incompatible with earlier models than the 8/e), c) management interference in the design, d) unwarranted cost was OS/8 V3D, which is the usual OS/8 system of choice on any -8. Later versions are either arbitrary subsets where features are excised, or ill-conceived frills are added (and in some cases still later were withdrawn) which detract from performance. Due to the "slight" hardware differences of the DECmate, OS/78 V4 and OS/278 are major steps sideways/backwards. The original system was known as PS/8, and there is a version 1 and a version 2 at least. Eventually, the name was changed to OS/8, and all of them are some variation on a version 3. Internal edits and external system names do not match. For example V3Q (of the keyboard monitor) is V3D, whereas "OS/78 Version 3" is V3T. I will digress at this point to provide the complete discussion of OS/8 versus OS/78. OS/78 is an asinine marketing concept implemented by Ron Jantzen, a programming manager at DEC circa 1978. (I don't know who dreamed up this horror, but Ron did it :-).) OS/8, as written includes a command called "SET SYS OS8" which does absolutely nothing other than cancel what happens when you use "SET SYS OS78." OS/78 offers you literally nothing, and further takes something away: In OS/8, image programs (.SV files) can be invoked via the R, RUN DEV commands, or you can use GET followed by START. Alternatively, it is conceivable that there exists an entry in CCL for invoking the program. But CCL is not open-ended (it must be upgraded each time a new program is added, and newer OS releases are "vanilla" again), and in turn CCL is an OPTION, not a permanent feature. (DEC always recommended that CCL be disabled on low-performance systems like RX01/DECtape because of the high overhead. Most users familiar with both styles would opt to use the command decode form to avoid the overhead on any system short of an RK8E or better.) As of V3D, a feature was added to OS/8 such that if a certain bit was set in memory, and another bit was set in the Job Status Word in the header of any .SV file, then it was illegal to run the program! Attempts to do so would get the error message "IMAGE ERROR" and abort back to the keyboard monitor prompt. CCL bypasses this problem because it doesn't run programs, instead it CHAINS to them (which makes them start at one higher than their stated starting address, presumably for useful CCL interaction, etc.). Indeed, CCL itself is chained to (when enabled) to create this form of execution. Setting the system to OS78 sets this bit in memory to prevent the non-CCL execution. There are NO OTHER FEATURES of OS/78! Eventually, a separate release of OS/78 (called V1) was created. It was merely OS/8 V3D with a few things deleted arbitrarily. Included with it was a small package of OS/8 programs known as the "symbiont process" which is a poor attempt at a print spooler. It is designed to function only in a specific environment: a) The CPU must be an 8/e or better. b) The machine must be EXACTLY 16K. c) There must be only NON-DMA peripherals present, preferably only RX01. Note that this description exactly describes a VT-78 :-). Clearly, this was a marketing attempt to create the illusion of custom software for the VT-78. Further, OS/78 was distributed only on RX01 media. An amusing footnote to Jantzen's folly: Ron demo'd this system at a DECUS symposium I and several friends attended in 1978. He scrupulously made sure that every system program .SV file had the JSW bit set, INCLUDING CCL.SV (this was his downfall :-)). After Ron explained how and what it did, my friend walked to the VT-78, and typed: .CCL The command to turn off all CCL processing is the CCL-form command "CCL" and the command to enable CCL processing is the run-form command "R CCL" which is specifically ILLEGAL in OS/78! So, once the "CCL" command is given (which is legal, and disables CCL), it is impossible to use ANY system program :-). Since even CCL.SV was "protected" this way, Ron's demo became the disaster it deserved to be. (I won't describe Ron's demeanor at this point in time :-).) Eventually there was a release called OS/78 V2. It was merely some handler upgrades, and a (yet another) re-release of OS/8 BASIC. There is no manual for V2, just a 2-page release note. The last thing Ron dreamed up was OS/78 V3, which is a major step backwards. They added a SET HANDLER command which is somewhat useful in contrived circumstances, but clearly not a replacement for OS/8 BUILD. At the same time, all support for anything that wasn't explicitly part of the current product line was dropped. This means Fortran II, all handlers for DECtape, LINCtape, DF32, RF08, etc., and BUILD itself. (In-house, programmers continued to use BUILD which still works.) The only things left for RX and RK and RL. They also proclaimed that there was no support for "pre-Omnibus" machines, and the code started having incompatible instructions inadvertantly sprinkled into it. None of this code is necessary, just that without discipline, novice programmers indiscriminately use extensions like BSW, etc. There is a clear and simple spec for non-violation of the classic PDP-8, yet no one was following it anymore: 1) Don't use IAC in combination with any rotate operation. 2) Don't use CAF. 3) Don't use BSW. 4) If using interrupts, don't use GTF or RTF. Violating rule one makes it incompatible with classic PDP-8 and LINC-8. Violating the other rules makes it incompatible with 8/i, 8/l, and PDP-12. Eventually, the DECmate I appeared, and OS/78 V4 was the first poor attempt to run on it. The problem is that device 03/04 are emulated on the DECmate, and not quite compatibly. There is no fix for this problem whatsoever. Instead of redesigning the software to work around the problem, they merely made it functional as an emasculated subset. When OS/78 is booted to an 8/E, it behaves identically to when booted on a DECmate I. Any PS/8, OS/8 or OS/78 prior system retains full functionality, but can't run on the DECmate I at all. OS/278 V2 (V1 was never released as a complete system; it only appears on test and install diskettes in incomplete form.) is an accodation to the slightly more incompatible hardware of the DECmate II, III, and III+. There are reports of portions of it being non-functional on the III, and I have included in KERMIT-12's .BWR file specific instances of general command failure regarding certain forms of the SAVE command which make no sense, yet are the case. Apparently, some aspects of either CCL or ABSLDR have been "mangled." There is a major gap in the release of the sources of OS/278 regarding support for the DECmate-specific peripherals and environment, which I am currently quite active in recovering "the hard way" meaning by disassembling the ROMs and other code to figure it all out. I will be releasing total disclosure sources and documentation as I learn it. Hopefully, several quite FATAL design errors of OS/278 can be rectified as a result. (P?S/8 already runs on the DECmate or PDP-8 without problems because it accomodates the DECmate "quirks" of the emulated device 03/04.) KERMIT-12 has some "defensive" code to prevent fatal file problems in OS/278 V2. One of my personal goal is spear-heading a movement to create OS/8 V5. This system will be slightly incompatible in a way that shouldn't affect any older program, as long as it is run on an -8. Newer programs which are aware of OS/8 V5 conventions will run equally well on DECmates or -8's. The goal is to rewrite all system components except hardware-specific programs such as PDP-8-only peripheral stuff like the RK8E formatting program, etc. Versions can be made available for anything from PDP-8 through DECmate III+, differing only in handler, not design. The "design creep" of the current OS/8 "family" versions is simply NOT acceptable and NOT necessary. MULTOS, ETOS, MULTI-8, OMNI-8 These are similar systems with a common goal: they are operating environments that use the time-share option to simulate multiple PDP-8 systems, each capable of running at least OS/8. Some aren't really an OS, rather a user program running under OS/8 that uses its facilities to create an interrupt-driven environment to simulate OS/8 from. Some support a few users, others quite a few, some only one or two. At least one requires some special hardware, which was added to help speed up the emulation. OMNI-8 is the most complete, and includes its own file system to keep track of all of the subordinate systems. MENU-8 is a proprietary system copyright CLA Systems (formerly Charles Lasner Associates). MENU-8 will NOT be provided in source form. This is an "umbrella" system used to help large devices (such as Winchester hard disks) parcel out disk partitions where multiple operating systems reside. When completed, MENU-8 will include its own utilities for volume maintenance, backup/restore, etc. It is currently is use to allow several independent copies of OS/8 and P?S/8 to reside on an 80 MB disk on an 8/e. (MENU-8 is really an operating system manager, not an operating system, but it does support its own utilities.) RTS8 is DEC's OS/8-based so-called "real-time" system which allows inter-task communication, but no "fixed" real-time events. (This is an example of what is sometimes referred to as "floating" real-time as opposed to "fixed" real-time. Events happen more in a proscribed order than in a fixed time interval.) RTS8 is merely a program run from OS/8, not a separate OS. P?S/8 is a proprietary system for any PDP-8 system with OS/8 capabilities, and represents an alternative operating system. It is an "expanding" system and as such has no fixed rules regarding compatibility. The original file structure is based on MS/8, aka the R-L monitor system, available from DECUS. The current system uses a completely different system structure, and there is a conversion program to move source files from MS/8 to P?S/8 (one-way only). MS/8 binary files are a compatible subset of P?S/8 binary files. (MS/8 binary files can't load extended memory whereas P?S/8 can.) Additional file structures are partially implemented currently, and include formats still in the planning stages. Appropriate hooks exist everywhere to add features as they are implemented. The longest stability of any one version is the current one, which hasn't changed since May, 1990 :-). P?S/8 development is along "vertical" lines whereas OS/8 is along "horizontal" ones. This means that OS/8 is more "complete" than P?S/8, but P?S/8 comparable features are often better implemented than OS/8 where they can be compared. An important feature of P?S/8 is the maintanence of programming discipline: all programs use classic PDP-8 instructions only, except for handlers that are hardware-dependent. (For example, the PDP-12 LINCtape handler uses PDP-8/i instructions incompatible with the PDP-8. Since all PDP-12's are also PDP-8/i's, this is not a problem.) As an example, a P?S/8 system on RX01 media will boot on ANY of the following systems (suitably configured with RX01 or RX02 and RX8E if necessary): 1) Classic PDP-8 with 8K and DW8EN bus convertor. 2) LINC-8 configured as 1) above. 3) PDP-8/i configured as 1) above unless the bus is positive in which case it needs DW8EP. 4) PDP-8/l configured as in 3) above. 5) PDP-12 configured as in 3) above. 6) PDP-8/e,f,m,a. 7) VT-78. 8) DECmate I. 9) DECmate II with RX78 option. (Must have ROM change or be indirectly booted from RX50 or hard disk.) This means that the literal 8" floppy diskette can be brought to any of these systems originating from 1965-1990. There is no parallel in the entire industry for such a level of compatibilty (Note: OS/8 V5 could also do this, except each machine would require 12K, not 8K :-(.) Special purpose operating systems have been written over the years for custom application requirements (such as real-time) where DEC's standard systems were unsuitable. I personally have written 4-5 of these. Most of these are ultimately self-generating when assembled by another system such as P?S/8 or OS/8. They are designed to run truly independently of the other systems however. Much basic programming technique is incorporated into these systems which is of great use to serious programmers. One such system includes a package of "large-system" resources usually found only in systems like TOPS-10/20, etc. to implement a 40-task shared-resource communications system. Formal buffer allocation/deallocation, disk queueing with priorities, balanced b-tree directories, are handled, etc. These systems may be the only example of PDP-8 programming for these techniques and should be shared with others as examples of technique for use elsewhere, etc.