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.
