Richard Lary-influenced systems family tree
cjl
systems. Here's an attempt to sort them all out.
1) R-L Monitor System, aka MS/8. Written primarily and originally by
Richard Lary and Lenny Elekman. These two people wrote a stand-alone
system called Poly Basic on the R-L monitor system by a conventional
form of development [because by that time, R-L existed!]. Lenny
Elekman also wrote 4K PDP-8 Basic, a "digestive" interpreter wholely
contained in 4K, including all storage and the user program itself;
supports no O/S. 8K and Lab-8/e 8K versions also exist via source
modifications I believe made by Jack Burness, who in turned nearly
single-handedly developed Lap6-DIAL [and DIAL-MS] for the PDP-12,
vaguely inspired by, but sharing no code whatsoever with prior LINC-8
and PDP-12 LINC-only systems. There are compelling reasons that the
origins of Microsoft are based on "observations" of Elekman's 4K PDP-8
Basic.
R-L add-ons were written by various individuals, most notably Charles
Lasner, who wrote an adaptation of FOCAL, 69 for it. R-L was itself
used by many people who went on in the PDP-8 world and even other DEC
architectures later as DEC employees.to make really good use of an
extremely limited "straight" PDP-8 configuration that was the actual
machine that R-L was "born" on. This configuration consisted of:
a) 4K PDP-8
b) EAE [not used by any software described above, but heavily used by
various games, such as PDP-8 checkers and the famous Poly Spacewar.
[Note: PDP-8 EAE is not totally compatible with PDP-8/i and PDP-12 EAE
or the superset of those on the PDP-8/e.]
c) Oscilloscope connected to AA01A 3-channel D-A converter. [Note:
The third channel was programmed to intensify the oscilloscope.]
d) AF01A A-D converter with 16 channels.
e) Home-made dual-channel "music register" hardware; used by various
games, including PDP-8 checkers [which plays the song "Love is Blue"
as recorded by Paul Muriat, in two-channel stereo], and Poly Spacewar.
f) TC01 DECtape controller.
g) One TU55 DECtape drive.
h) PT08.
I) KSR-35 tty.
J) "Borrowable" ASR-33 tty:
This machine was housed in a pair or powder-blue-paint PDP-8-style
cabinets, separated with 4 cabinet sides. Charles Lasner did various
hardware work on this machine to accomplish various projects:
i) Make the machine work at all, solving the "photo-sensitive front
panel" problem that inevitably plagues most straight PDP-8s [but not
LINC-8s or newer models].
ii) Replacement of all of the front-panel slide switches. [Note: Do
not mention the word "Stackpole" near cjl; you have been warned!]
This was needed because R and L mentioned above literally wore out the
front panel by toggling into memory by hand the entire R-L system!
There never was any source code; some of it was typed up on itself
once it existed, but there never was a system created from source code
as we know it. Legends exist regarding hand-assembled code written out
on napkins, etc. The Decus submission of R-L was made by Mario De
Nobili, Emper0r of the P?S [there is no typo in this sentence].
[Note: It is arguable that the R-L system would be either difficult
or even impossible to develop itself from/on, but this only attests to
the fortitude of its [manually programming] authors. [When you only
have a 4K system, you lack a lot of software facility to develop for
the hardware; this is why many went to PAL10 and brought back paper-
tapes and printouts. P?S/8 was started in that very way, as was PS/
8.]
iii) Modified the AA01A modules to add in a proper PDP-8 buss daisy-
chain. In the process, the other "half" of the hardware was recycled
for other projects. Rack space was saved, but at the expense of the
considered-irrelevant ability to have the AA01A added onto a PDP-9
buss as an option in conjunction with a PDP-9-specific "half" of the
interface, not available. [Note: The PDP-9 buss is inherently
supported in the AF01A; you have to put in alternate buss cards.]
iv) Bolted the systems together, eliminating the overly long
improperly terminated negative buss cables, and as a result, the
system became far more reliable. [DEC never properly terminated the
buss!] Thus, the configuration was a PDP-8 table top machine on a
table, and two cabinets next to it, instead of the "symetrical" [and
space inefficient] system with a cabinet on either side of the table.
This also saved shoe leather walking between the non-adjacent
cabinets.
This system runs on any equivalent PDP-8 model with the same
configuration. No real facility is available for supporting other
devices, multiple DECtape drives, extended memory, line-printers,
paper-tape readers/punches, etc. It is literally limited to what it
was written for, specifically.
It is most notably device-dependent; there is no way to get a system
handler in memory because the R-L system handler was incapable of
loading a program. As such, the handler is kicked out of memory and
replaced by a rebooter and one-shot image program loader; thus, each
loaded program requires its own copy of an internal handler.
The principal development language is an adaptation of the paper-tape
PAL III assembler. Binaries are loaded by the famous "Slurp" loader
without requiring either a buffer or write-enable. Internally this is
used as the loader for Poly Basic.
2) Dibol-8. This is a thinly disguised version of the R-L monitor
system. It includes an early version of the original Dibol language
compiler and appropriate binary loader. Due to the way R-L works, by
patching an internal command table, you can map all of the commands
accordingly. It is not known at exactly what point the commands of
the Dibol branch of the tree changed the commands, but it is true that
early versions of these systems supported commands more like very
early Basic implementations:
LOad {filename}
Save [filename optional; uses prevailing if left out; same for LOad if
applicable}
Eventually these were changed [in command-name only] to
FEtch {filename]
WRite {filename}
largely in the interest of remapping commands such as LOad and SAve
for alternate purposes.
Dibol-8 was supported in theory, but was actually just an interim
system; all users were *strongly* encouraged to upgrade to COS-300 and
then COS-310.
3) PS/8 is a totally different system originally written alone by
RIchard Lary, but influenced by all sorts of other people, some of
whose ideas are not necessarily a good influence. Some of the
internal code and/or ideas rattling around in the head of Richard Lary
as used in the R-L system were "infused" into the design, which was
done in a quick-and-dirty manner initially. This system required 8K
and otherwise what hardware R-L did. Nothing about it is compatible
with the R-L system.
4) OS/8 is a somewhat more developed outgrowth of the original PS/8.
The name change was superfluous and forced by the marketeers. The
same goes for various descendents with names that include various "ver
x" versions where x is 2 or 3, sometimes followed by a letter.
Various bastardized subset/superset configurations were sold
needlessly confusing the product line. Some were called names such as
OS/78, etc. The name might suggest some connection to some hardware,
but that is misleading. In one case, the difference is to add a
"feature" to make the system do *less* instead of more,by setting a
"feature" that can be fatal if you accidentally turn it off. However,
it could have been associated with newer binary releases, all of which
could run on the original. Some of the programs are very hardware
specific, such as only running on a configuration equivalent to a
VT-78, but in reality, this is more likely a configuration requirement
such as having a VT50-family console terminal, having exactly 16K and
the like. Certain handlers are only meaningful on certain hardware
configurations, such as the ability to support a second pair of
RX01/02/03 drives, or certain serial printer ports, etc. Some of the
serial ports have extension IOT instructions to set baud rates to
override a default value that can be set by a rotary switch on
thecabinet of the hardware, etc.
Later versions are branded OS/278 and cannot run on any machine prior
to DECmate I; OS/78 is likely "land-locked" to the DM I also when it
is known as V4, but OS/278 should support that hardware as well. The
hallmark of all of these later systems is improperly understood
hardware-dependent changes made to attempt [poorly] to work on PDP-8-
incompatible hardware. Thus, you have releases systems that literally
don't completely work anywhere. [Looking at the source code, it is
clear that someone with an incorrect understanding of the actual
hardware was giving a table to blindly follow to less-qualified
programmers who believed this was actually true.] Only via a large
concerted user effort can this problem ever be solved by emulating a
work-around used currently exclusively within recent released versions
of P?S/8.
The principal development language of OS/8 is PAL8, a mediocre PDP-8
assembler with certain quirks making it less than expectedly
compatible with PAL10. By exercising a modicum of caution,source code
can be created that can be assembled by PAL8 and P?S/8, which in turn
share certain key features first suggested by Joseph R. Fischetti of
the P?S. Common conditional assembly features available in both
systems allow for divergent program source code if desited. These
features, and related issues are sore-point incompatibilities in the
now largely abandoned PAL10, now useless for program development in P?
S/8 and OS/8 due to these features not being available, although
correcting this situation in theory should not be a big deal for a
qualified PDP-10 programmer. Created binary files are loaded with a
virtual loader known to be of only a medium speed of loading, even on
fast disk devices, which is otherwise totally serviceable other than
dealing with loading over locations 7600-7777 which are specifically
ignored as opposed to being stored for possible user purposes beyond
initial program loading [a problem solved in P?S/8].
5) COS-300 and COS-310 are based internally in some part on OS/8
source code diverging from the original. The commands have been
updated as explained above regarding FEtch and WRite. It is possible
that the latest of these can run [only[ on DECmates, because this does
not have to be an OS/8 configuration with flexibility. Generally, it
is difficult to more generically configure COS systems as compared to
the OS/8 family, which has an adequate attempt at true device
independence in terms of the storage device handlers, etc. Printer
support is likely highly limited to models sold by DEC, and in this
aspect parallells the unrelated WPS software, all of which are
bootable application systems, with proprietary and minimal
configuration capability.
6) P?S/8 is the follow-on system to the R-L monitor original. It has
no code within it from the R-L monitor, but it does support many of
the concepts of R-L where useful. It is partially binary-file
compatible with R-L; a conversion program can convert R-L text files
to P?S/8 text files which support a larger set character format which
is a proper superset of the R-L format. The in-memory built-in line
editor and command processor is sufficiently compatible to allow
direct moving of the [converted text and unchanged binary] files from
an R-L DECtape to a P?S/8 system DECtape.
P?S/8 supports a minimum of 4K, just as in the original. However,
most utilities make great use of available additional memory up to
32K, and in general can be found to make better usage of all available
memory than the OS/8 analogous system. The system handler supports up
to 8 DECtapes without loading an additional handler [in 4K; no
additional memory is required to support this]. Notable features
include dead-reckoning in the system handler to palpably optimize tape
motion handling [taking advantage of situations analogous to where OS/
8 fails to exploit], and improved error handling.
All utilities of R-L were rewritten and improved, with no known
features left behind. Many additional utilities are included in P?S/
8, many with far more utility than the OS/8 analogous counterparts;
some are specifically unique to P?S/8; some are major supersets of
notions born in the R-L system, but taken to a far better level of
utility, by synergistically using P?S/8-specific features.
A notable design feature is the implementation of clearly superior
support for "problematic" devices where it is not possible to support
a device adequately in a 4K machine. Unlike OS/8's attempts to
support problem devices in a handler quite a bit smaller than 256
words total [actually about 3/4 or less than that!], P?S/8 allows for
an additional 1K words should it not be possible to support the device
in about the same space OS/8 does an analogous handler in the first
4K. [Note: In OS/8, the second field of memory is not available to
any handler! The only way to get additional meager handler space
requires 12K,] As a result, devices, which generally require three or
more pages of code space to properly support, do not have compromises
as is the norm in the OS/8 situation. [To my knowledge, there is not
a single OS/8 handler that is not compromised, other than the one I
wrote for the CESI SCSI adapter; it was a design feature of that
hardware to make that even possible! This applies to all hardware
sold by DEC; there are a small quantity of other third-party devices
that had better support, such as the DSD-240, which was in small part
an inspiration for the DMA command interface portion of the CESI SCSI
interface.] [Note to software emulator writers: The DSD-240 or the
CESI SCSI interface will create a better running emulator because the
actual "heavy lifting" is done by an external micro-CPU, this in
emulation, this means there is far less PDP-8 code to emulate, etc.
This is quite apparent in the case of the SCSI interface, which is
capable of defining a 32K read or write in a single command! Memory
can be anywhere in a 128K or 512K space depending on the extended
memory controller.]
Most notably, P?S/8 BATCH is supported on all configurations, and even
runs across system reboots. [Note: OS/8 BATCH requires 12K and is not
device-independent.] Unlike OS/8 BATCH, P?S/8 supports two different
abort keys, so the latest program only can be aborted or the entire
batch. DECmates are fully supported by P?S/8 BATCH due to the
implementation of logical abort control, something sorely needed, but
totally absent in OS/8's family "branch".
A unique feature is the notion of logical console support, allowing
PDP-8 configurations that do not strictly require the standard 03/04
console device. P?S/8 does not use a handler per se for the line-
printer, instead depending on the console overlay to be configured for
the hardware at hand. The overlay is easily reconfigured for the
hardware present in any reasonable system to support devices such as
serial printers, etc. A notable feature of the standard device 66
parallel printer support is a built-in printer buffer that allows P?S/
8 to support high-speed line-printers as much as four times as fast as
OS/8.
Devices such as the VK8A or VT8E can be supported by the overlay using
terminal emulation code configured for the overlay specifically. The
memory requirement for the console overlay is a 3K requirement, and
dovetails nicely with the 1K potential requirement of a "problematic"
system device handler.
Someone once suggested support for an IBM 2741 terminal as the
printer. This is not possible in OS/8 due to woefully inadequate
handler code space. Depending on other configuration elements,
perhaps as much as 2Kwords or more could be devoted to the support
which includes the need for translate tables, etc.
The console overlay also supports the notion of device-specific
critical error handling first seen in systems such as the ADSS DECtape
system for the PDP-9 [IOPS4] later still imitated by MS-DOS ["Abort,
Retry, Fail]. In some instances, optional handler enhancements can be
added for use with the console overlay. For example, if the console
overlay is utilitizing the VT8E, and the system device is TD8E,
interaction that would compromise the system handler and device
reliability is averted. Note that the minimal memory requirement for
a P?S/8 system with both a problematic system handler and the console
overlay simultaneously available matches the standard minimum of OS/8,
namely 8K.
P?S/8 is totally device-independent, actually to a larger level than
OS/8. All P?S/8 console input and output supports control-S/control-Q
protocol, while in OS/8, only when the "KL8E" handler is used, does
this apply. Many users attempt to miminize lost console output on
certain console terminals [VT-100, etc.] by lowering the console baud
rate for an imperfect solution; this is never necessary with P?S/8.
All DECmates are supported directly, thus there will never be a need
for a "balkanization" of P?S/8. All supported system devices must
include the system handler itself, and an optional address "fixup"
list in case the handler dynamically updates itself as the system
bootup process proceeds. [This only applies as necessary; this
applies to devices with "strange" bootup conventions such as the
RX01. In such a case, the code that must be written to the boot block
differs greatly from the code that must eventually be in 07600-onward
needed to write out the initial system itself,]
Options include the optional slurp loader [or a dummy entry to force
the use of a virtual loader where necessary]. For use with the
console overlay, optional code is to be written for enumeration of the
critical errors specific to the hardware [write-protect error, mark
error, read-parity error, etc.]; this is to be used by the overlay in
a manner determined within the overlay itself, but generally to give
detailed, specific error status reports before asking for some retry
options with reponse on the console input device, etc., and handler
"aid" code to give enhanced system handler performance if
applicable.
An example of the system handler "aid" code: On the PDP-12, it is not
possible in OS/8 in 8K or in P?S/8 in 4K to force the LINCtape
hardware to search the tape forwards. [This and this feature alone
requires a large code space beyond the capability of OS/8; it was felt
to be unjustified to force P?S/8 to require 8K minimum for merely this
reason; the one-page 4K-oriented system handler is otherwise fine as
is the OS/8 equivalent.] Within the environment of the console
overlay, PDP-12 LINCtape handling is enhanced to include a table of
current transfer blocks for up to 8 LINCtape drives, and the
additional code to force the hardware to perform the appropriate
initial search direction based upon "dead reckoning" for each
individual tape drive. Thus, performance is equivalent to the TC01/08
DECtape handler when using the appropriately configured console
overlay. [Note: PDP-12 enumerated errors also takes additional code,
a feature that will never be available within OS/8; just not enough
code space. However, available to the console overlay in P?S/8.]
All of the standard OS/8-supported disk devices are either written
for, or are known to be easily supported if the need ever arises by
the equivalent in P?S/8. In certain cases, better handlers can be
written to not waste device space in terms of "12-bit" versus "8-bit"
for specific devices. For the most part, the remaining unwritten ones
will of necessity benefit from the 9-page system handler
specification. Many of these problematic devices simply cannot be
defined within OS/8.
a specific system handler that is currently unfinished but planned, is
to support the RX50 on the DECmate II/III family in 8-bit mode. Such
a handler will allow a P?S/8 BLKCPY operation to copy an entire
diskette. [Note: OS/278 programs aren't really using OS/278's
handlers! The system handlers run in 12-bit mode.]
[Note: P?S/8 BLKCPY is a unique copying utility that takes advantage
of various P?S/8 features. It is not translatable to either stand-
alone or OS/8 operation; it can copy or compare various device blocks,
and supports the notion of device block cluster size, allowing support
for devices more "granularly" than OS/8 to as much as nearly an order
of magnitude larger than OS/8's theoretical maximum, depending only on
a table entry and the requisite handler code. Thus allows support for
various devices such as PDP-10 DECtapes and PDP-12 LINC-compatible
LINCtapes [not supported by OS/8 or P?S/8 normally.] BLKCPY takes
command-line input that can be passed through the contents of a file
including multiple operations. The entire batch of operations itself
can in turn be run optionally from P?S/8 BATCH. Most operations can
be performed in 4K depending on handler requirements. Worst case
memory requirement is 20K in extreme configurations; all current
existent handlers can be satisfied in 12K. Throughput is generally
attempting to be accomplished using 4096 word input and output [or
compare] buffers; comparing the destination to the source is standard,
but can be disabled by switch option [meaningless if comparing instead
of copying two devices!] A unique feature is focused error recovery:
If a 4K transfer cannot be accomplished after a reasonable number of
retries, the transfer is reduced to a series of one record at a time
transfers, to perhaps perform a better error recovery in marginal
circumstances. Once the error is recovered from the later transfers
resume using 4096 word transfers as before the error occurred, etc.
On various devices, this has proved to occasionally be the only
successful way to read marginal media, etc.
Early versions of P?S/8 used the older Basic-like LOad and SAve
commands, but all of the commands were made as close as possible
compatible with COS-310 syntax [FE and WR]. The command structure is
a vague analogue of CCL except there is no particular overhead
associated with the command usage, while in OS/8 it is necessary to
consider turning off the entire feature due to the large overhead,
especially recommended on tape-base systems. In certain marginal
cases, there is a one-to-one correspondance between OS/8 and P?S/8:
.PAL BFILE<FILE
would actually be meaningful to both systems. [Note: P?S PAL uses the
same format switch options as OS/8. However, P?S PAL has totally
different meaning for the passed switches, in large part because there
are far more of them! The organization is also of necessity totally
different because PAL internally handles cross-reference, similar to
PAL10, and can chain to BITMAP and/or the BIN loader program passing a
large assortment of options to the loading utility. In one command, a
program can be loaded after all of the assembler, cref, bitmap
options, saved to the disk, or alternatively, it can be directly
punched to the low or high speed punch in either BIN or RIM format.]
Most notably, all relevant P?S/8 commands that reference input and
output files embrace both conventions used in many other DEC systems.
As appropriate, the user can use the "<" or the ">" characters, which
ever is more intuitive, as both are supported. [Note: In some DEC
systems, the confusing "=" character is used as a command separator,
which is clearly confusing to users of other systems; P?S/8 uses the =
character in the same sense as OS/8, to set a parameter or starting
address, and not as a command separator.]
The principal development language of P?S/8 is P?S PAL, which supports
virtually every useful feature of PAL8 [other than contrivances that
do not translate to P?S/8 at the binary level]. which is totally
syntactically compatible with PAL10. Many PAL10-compatible superset
features not available in PAL8 are either supported or acknowledged by
P?S PAL. Assembly speed on comparable hardware is noticably faster
than PAL8 facilitating development of large PDP-8 programs. Binary
loading of assembled programs is accomplished via a conceptually-
analogous [and partial format compatible] R-L type "slurp" loader
where avalable or a virtual loader that is known to load programs
somewhat faster than OS/8's virtual loader. The slurp loader is
remarkably faster than either system's virtual loader and loads
without a buffer on a system tape that can be write-locked. By an
advanced adaptation of the original slurp loader, P?S/8 is capable of
reloading the system handler over the loader itself, again with write-
lock on.
All of the other systems in this list were at some point supported by
DEC. P?S/8 was offered to DEC -- twice! After the second rejection,
a limited royalty agreement was reached between Charles Lasner and
Intersil Corporation to support the Intercept I, a machine that was
similar to and better than a VT78. That specific version of P?S/8 was
sold as IFDOS. It could run on a suitably configured PDP-8 [RX01-
based with at least 8K]. Additional similar machines were sold by
Pacific CyberMetrix as the PCM-12 and PCM-12a [I believe the "a" may
have meant "assembled". the -12 was a semi-kit with a lot of
mechanicals, but little in the way of soldering.] All of these
machines used a full-speed [4 MHz] IM6100 instead of the slowed-down
DEC VT78. Memory was implemented in 4K memory cards, each with an
onboard battery to preserve the contents across power-downs. The buss
supports up to 32K. There is a front-panel switch to implement the
standard RX01 bootstrap. The front panel is implemented in Control-
Panel memory with a front-panel refresh clock control. Faster update
severely slows down execution, but is useful when hand-debugging; the
slowest update allows the CPU to devote nearly all cycles to normal
PDP-8 functions; interrupts are then totally functional and characters
are not dropped for all normal terminal configurations.
cjl [who did *not* create alt.fan.charles-lasner]
Tim Shoppa
> 2) Dibol-8. This is a thinly disguised version of the R-L monitor
> system. It includes an early version of the original Dibol language
> compiler and appropriate binary loader. Due to the way R-L works, by
> patching an internal command table, you can map all of the commands
> accordingly. It is not known at exactly what point the commands of
> the Dibol branch of the tree changed the commands, but it is true that
> early versions of these systems supported commands more like very
> early Basic implementations:
DIBOL, FOCAL, and most of the 70's mini/micro BASIC implementations
have a lot of common spirit. (There are certainly BASIC
implementations that lack the spirit.)
I don't know exactly what early DIBOL looked like, but by the time I
got to it, I was very impressed with the way it could do math with
numbers contained in strings. I understand that this was done largely
to support COBOL-type decimal math, but the result was far more useful
than the dictatorial COBOL mindset, and shines through into, for
example, modern Perl.
Tim.