[Reasonably] Authoritative documentation about PDP-8 time-sharing and related systems
cjl
without factual basis, off-topic and other defective posts on this
subject has faded away, I was able to find this independent round-up
of all of the relevant systems most of us have heard of in the
collective sense. [I don't know of all of them and I learned a few
things!]
I will comment freely with my take on them as relevant. Please note
some portion of my general position:
1) Just about every system has something to offer; to forget that is
to invite ignorance. In some cases, it could be rather minimal. In
others, it could merely be examples of what *not* to do.
2) Some systems just became obsoleted by others. In some cases, only
grasping at straws prevented universal abandonment, while most users
in the relevant time-frame moved on to something else. Depending on
circumstances, it would be in the "better mousetrap" sense, in others
it was merely a matter of clever and more effective marketing.
Those curious to figure out the details of obsolete systems are
welcome to walk the same path and find out why the designers of better
systems abandoned them. In one case, the principal author of one of
them abandoned his own work because it was too limited, and instead
became the principal programmer at another company he helped form, but
was not the principal owner, since all of these companies are
corporate-model-driven, etc.
3) In some instances, the software and requisite hardware was rather
expensive, especially when you factor in the inflation factors since
the relevant years to the present. [For reference, I believe the
brand-new cost of a basic LINC-8 in today's terms is likely in excess
of $500,000.00 2009 US dollars.] Thus, the inherent risk aspect of
investing in such a system was no trivial matter.
4) The PDP-8 has been around long enough that some of the limitations
were overcome as the years went by; older software became irrelevant
as newer software took advantage of newer hardware, or the ability to
support more machines in tandem cooperating in the implementation of a
more complex system. Some software simply became outclassed and
obsolete because more effective packages simply did a better job, and
perhaps for less up-front cost, certainly attractive to commercial
operators of such systems.
5) The user connection to the time-sharing system often was nothing
more than a 110 baud dialup modem and teletype, and likely remotely
located for dozens of miles of travel, often without the ability to
get there readily by public transportation. If the user was a young
student, this also meant a committment by the parents to take the
student to the "computer center" where the machine was if a line-
printer listing or files on private DECTape or other media was ever
involved, and usually not encouraged. As time passed, the dial-up
speed improved slightly, all the way up to a mightly 1200 baud during
the hey-day of most of the newer systems in the collection; this was
literally years before viability of what today is taken for granted
[and commented on by truly ignorant people on these forums who don't
read about what years this stuff applies to!]. Lucky students might
hang around after school if the machine was located there, but their
parents would not like kids doing other than their parents' plans for
them [such as playing soccer]. Computers and parents often don't mix!
Commercial ventures drove the advancement of the market for time-share-
type PDP-8 systems because of the extreme cost. There needed to be a
customer base to offset the cost and risk, only hoping to first break
even and them hopefully profit from the effort. As such, most of them
had a quite small customer base. Each customer had quite a lot of
"pull" in terms of features they felt were either necessary or
desirable [or just customized for their personal preferenced needs].
6) Some of these systems have nothing to do with time-sharing as a
concept per se. However, some aspects of them contributed to other
systems. for example, the principle system simulated on some of them
is a kludged-for-efficiency-in-a-shared-environment version of OS/8
using virtualized drivers that cannot run on the "real" underlying
hardware. Also, for support purposes, the overall system could
dictate any particular O/S as a loading-only system that then is
dismissed as the time-share system runs in memory. OS/8 functions can
be performed by work-alike subsystems of the in-memory operating
system to maintain OS/8 file structure compatibility, etc. By nature,
it would be easy to run other systems as long as certain overall
hardware and software specifications of these other systems could be
adapted. [For example, P?S/8 runs on just about any hardware that OS/
8 can, and often less!
It would be a straight-forward thing to implement it "virtually" as
well, while the DMS would likely be totally locked out due to
excessive dependence on hardware that cannot comply with the
requirements of running under the shared environment, etc.
The basic document can be accessed here:
http://www.faqs.org/faqs/dec-faq/pdp8/section-10.html
Where relevant, I will add in comments clearly indicated.
What operating systems were written for the PDP-8?
[**cjl: One would hope this list is complete. Anyone want to add
anything they believe was accidentally left out?**]
--------------------------------------------------------------------------------
A punched paper-tape library of stand-alone programs was commonly used
with the smallest (diskless and tapeless) configurations from the
beginning up through the mid 1970's. This included a paper-tape based
text editor, the PAL III and MACRO-8 assembler, and a FORTRAN
compiler,
as well as a library of support routines. Many paper tapes from this
library survive to the present at various sites!
[**cjl: Visit my archive on sunsite.unc.edu also accessible from
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-8/
.**]
The minimum configuration expected by these tapes is a CPU with 4K
memory and a
teletype ASR 33 with paper tape reader and punch. Note that much of
this
paper-tape-based software is based on memory-use and I/O conventions
that
are incompatible with later disk-based systems.
[**cjl: This bears some explanation; the problem is both less than
implied in part and also larger than implied in part.
The paper-tape software is not incompatible with PDP-8 terminal
conventions used in prevailing operating systems.
Please note that many PDP-8 systems run with interrupts off, and that
is the only way on all models prior to the PDP-8/e KL8E extended
instructions to be able to program the device 03 interface to prevent
paper-tape from advancing in the reader and also clear the flag,
absolutely mandatory for interrupts-on operation; the standard
instruction, by clearing the flag, also advances the reader, causing
the next character to appear in essentially 1/10 of a second.
Thus, the only interrupt-driven systems that can actually deal with
ASR 33-based paper-tape must of necessity run from an -8/e or -8/a
with that console terminal. No other terminal is supported for paper-
tape beyond the DEC-modified ASR 33. For all newer systems, there is
no actual paper-tape reader available due to console terminals lacking
paper-tape capability. This would also apply to modified older
machines such as LA30-P added to a PDP-8/i as a faster console device.
For all relevant systems up to and including PDP-8/a, the high-speed
reader/punch is always a viable option, and this problem does not
exist in that configuration.
Most of the paper-tape software should run on all models that are not
DECmates, assuming a viable way to get the software loaded, which
could be problematic depending on exact configuration. I don't know
if was sold, but DEC field service used a medium-speed paper-tape
reader that was not totally software compatible. However, it was
close enough for loading paper-tapes into memory via an adaptation of
the BIN loader for the relevant device. [Other paper-tape software
could not run on this configuration. It depended on the fact that the
BIN loader can be hoped to always be faster than the reader, thus
always waiting for it. If the machine ignored the reader, it would
continue to run anyway, not as it would work on an ASR-33.]
Just about all of the paper-tape software cannot run on a DECmate due
to the incompatibility of the device 03/04 interface itself as
implemented on the DECmates.**]
The DECtape Library System was a DECtape oriented save and restore
system
that was available from the start. The resident portion of this
system
occupies only 17 words of memory (7600-7625 octal), and it allowed
saving
and restoring absolute core images as named files on a reel of
DECtape.
Initially, program development was still done with paper tape, and
only
executable memory images were stored on DECtape, but eventually, a
limited
DECtape-based text editor was introduced, along with a DECtape based
assembler.
[**cjl: This needs to be firmed up: The DECtape Library System is
compatible with the original version of the standard TC01/08 DECtape
bootstrap, and also most more clever smaller subsets of it. [Note:
Some versions load all of the first DECtape block into any page of
memory, destroying the former contents. Then, the machine is
restarted manually somewhere within the just-read-in code. An
alternate way is to place the code within the memory area where the
boot code will overlay it. The convention for this aspect of things
is to have the final two words of the
manually-entered code be a DTSF; JMP .-1 pair that must be explicitly
located at relative 0016, 0017 of the page.
When the code from the tape overlays that code, the read-in code takes
over and performs the rest of the system bootstrap.
This is often taken a step further: Specifically, this loop must be
located at 7616 and 7617. When this is the method chosen, the
operating system loads its code over 07600 onward. Of special note is
that the locations 07754 and 07755, the word-count and current-address
register locations for the three-cycle data break, get overlaid by
data from the tape itself. Thus, the operating system can modify the
former contents to serve the specific requirements of the
specific operating system itself. In some cases, this also means that
the value of 07754 can be a wide range of acceptable values, as
opposed to a precise value. [The contents of 07755 must be accurate,
as that is what starts the transfer itself, and as such must be set to
7577, so that the first transferred word winds up in 07600 [the
hardware pre-increments the location before using it as a data pointer
for the DMA.]
There are even shorter versions of this bootstrap; not all operating
systems are compatible with the shortest toggle-in version, but it is
known to work with P?S/8 and OS/8.
To store a program on the DECtape Library System, the user must ensure
the contents of the words specified in the FAQ document; I am not sure
if the initial contents that would be required to toggle in is as
large as implied above; a subset should apply. However, once the
Dectape Library System is up, the point is that if only those few
locations are not destroyed, restarting the computer at 07600 will
succeed in saving "all" of memory.
However, the word "all" as implied needs to be defined: In general,
all programmers are encouraged to totally avoid loading into *any*
portion of 07600-07777. However, some paper-tape programmers assigned
the task of writing diagnostics delivered on paper-tape exceeded the
requirement. They in some cases only preserved 07756-07776 to
preserve the RIM loader only. The theory was that the RIM loader
formatted BIN loader would be loaded in by the preserved RIM loader,
and thus their "system" was restored. This is of course ignorant of
all O/S conventions from the DECtape Library System onward.
Thus, a better explanation is that as long as those locations are
preserved, or can have some proper subset manually enterred, or a
suitable shorter-still bootstrap procedure performed, the DECtape
Library System is capable of saving locations 00000-07577 only. The
locations 07600-07777 are off-limits as they are a portion of the
Library System itself; newer operating systems also require at least
this memory area as well, including the Disk Monitor System and P?S/8
and the field 0 section of OS/8 [which also requires field 1 to exist;
extended memory is beyond the scope of the DECtape Library System.]
The numbers stated are clearly wrong, as 17 is an odd number, yet an
even number of locations in memory is stated, which doesn't add up to
17 in either octal or decimal. I don't know the exact numbers, but I
believe it could eventually be derived if no one has concrete
information.
An obscure variation of the Library System was known in some circles
as the Josephson modifications. As I understand it, a modification
was made to the paper-tape editor program and an assembler, presumably
either PAL III or MACRO-8.
The idea was that when you saved a copy of the editor, you were also
saving a "file" which was actually the editor and the editing buffer
within which was what you were typing up. By loading it into memory,
you could do further editing. Note that the more you have editing of
projects, the more copies of the editing program's binary is
redundantly stored!
Then the modified assembler is invoked after some method of
communicating to the assembler where the source code is located,
presumably by saving a redundant copy of the relevant source file into
a tape "slot" of a designated name the assembler will look for in a
"hard-wired" way. Binary output was created into some analogous area
reserved for binary, thus was likely a pre-allocated image of
00000-07577. Once the assembler essentially dynamically "patched" the
designated image area, it could be run just like any other image, and
could be deleted or saved/copied to another "slot" on the tape, a
standard feature of the original system.
I had a confrontation with a DEC senior employee [who shall remain
nameless as this point] at a DECUS symposium, who, in his ignorance,
thought this system was the "cat's meow". I guess from his viewpoint,
it really was better than anything that had come before. However, he
was blind to any rational explanation of just how much the R-L monitor
or anything like that could possibly be so much better! Suffice to
say his software capability evaluation skills were quite limited.**]
The 4K Disk Monitor System provided slightly better facilities. This
supported on-line program development and it worked with any device
that
supported 129 word blocks (DECtape, the DF32 disk, or the RF08 disk).
It was quite slow, but it also used very little of the available
memory.
[**cjl: The sloth of the 4K Disk Monitor System on DECtape is quite
much. On the fixed-head disks, things are better. However, it was
proven by an angry user that he had "misspent his money" buying the
expensive DECtape hardware, because he, as a skilled user of the paper-
tape software and armed with a high-speed reader/punch, could develop
programs faster on the paper-tape!
MS/8 and later P?S/8 made the point made by the angry user moot,
assuming he was ever instead given either system to use instead of
paper-tape!
With the exception of PDP-12 LINCtape supporting 129 words/block, no
other DEC peripheral was ever developed that the Disk Monitor System
can run on. [I will entertain theories with regard to the RK08
positive buss peripheral.]
It is conceivable that the Disk Monitor System could be made to run
[even slower than on DECtape!] on the 4K LINC-8 with hardware
modifications that allow P?S/8 to run on that hardware.**]
MS/8 or the RL Monitor System, was developed starting in 1966 by
Richard F. Lary; it was submitted to DECUS in 1970. This was a disk
oriented system, faster than the above, with tricks to make it run
quickly on DECtape based systems.
[**cjl: The R-L Monitor System [the correct name!] is limited to a
single TC01/08 DECtape drive only. Other than by switching unit
select, it is ignorant of any additional tape drives. The entire
system is device-dependent; system programs need to include their own
copy of DECtape software because there is no central device handler,
just one used by the keyboard monitor. The famous no-buffer/no-write
"slurp" loader originated here. That also doesn't provide a system
handler, thus the same problem for user programs as well.
The entire development of the basic R-L system was accomplished
totally by hand: hand assembly on "napkins" while eating chinese
food, then toggled into memory in binary form on the front panel.
After the original tape routines were placed in memory, they could be
used to write out each page of code as it was developed, etc.
I personally had to repair the front panel of this machine due to
their utterly ruining the switches by overuse beyond design
expectations.
Certain individuals experimentally made provisional copies of the R-L
Monitor System run on a DF32, but everything had to be patched up;
additionally the 32K DF32 was too small to contain much of use.**]
POLY BASIC was a BASIC only system submitted to DECUS and later sold
by
DEC as part of its EduSystem marketing program. EduSystem 25 Basic
is available from:
ftp://russ.ucs.indiana.edu/pub/DEC/PDP8/Langs/Edu25Basic/Ascii/
[**cjl: There is a screw-up here: EduSystem 25 is not relevant to
Poly Basic.
Poly Basic was developed by normal editing means on the then-existent
R-L Monitor. It is written in PAL III assembler and was developed on
and for the same machine described above. It is a standalone
implementation of Basic, and uses the typical built-in line number
editor. In Basic, the line numbers are significent; a standard
feature is to resequence all of the lines and not lose the proper
references.
Poly Basic is a true compiler, and produces binary compatibile
internally with the R-L Monitor System [and P?S/8].
There is no filesystem presence of the binary. Instead, a Basic run-
time system is image-loaded along with a "Slurp" loader. The user's
binary program overlays the rest of memory, and thus can directly
setup parameters to the run-time system as well as general loading
considerations. The file system is not compatible with any other
system. [Note: R-L and P?S/8 do not use permanent line numbers as is
practiced in Basic.]
Poly Basic was "lifted" by DEC and converted into a profit-making [for
DEC] program called EduSytem 30 and later Edusystem 15-30. The only
differences from the original is minimal support for a mark-sense card
reader to avoid the need to have people typing in their Basic programs
one at a time, and additional support for a 4K PDP-8/e with KM8E
extended memory control, the MR8E-C TD8E-oriented ROM, and a singe
TD8E TU56H drive.
Poly Basic supports the usual TC01/08 bootstrap convention, and can be
restarted at 07600 to reboot itself. However, depending on what state
the system is in, the code in 07600 may not be compatible [for reboot
purposes] with other systems. By properly exiting Poly Basic, the
standard bootstrap can be restored to allow booting any other
compatible system. Other than when slurp-loading the compiled user
program binary, the internal system handler resides in
07600-07777 as in most PDP-8 operating systems.
When the TD8E configuration is used, the system handler still fits
into 07600-07777, but actually calls code in field 7 7400-7777 within
the ROM to carry out the actual I/O. This configuration is also
supported by P?S/8 and also OS/8 if the memory requirement is raised
to 8K.
The "ownership" of Edusystem 30 was the subject of a period of
dissatisfaction between Brooklyn Polytechnic Institute, which is where
the name Poly Basic came from, and DEC. An opportunistic academic,
totally without proper authorization, made a deal to give unwarranted
endorsement claiming the school was a "satisfied user" of another DEC
product [I believe TSS/8], when in fact, he had a private project that
had no actual connection to the school; his project, and not anything
within the school, was the actual user; the physical location of his
project was over 40 miles away from the campus, actually located
apparently within his own hometown, thus justifying his spending even
less time at his actual academic job he was being paid for at the
school itself. In exchange for this, he got some form of "deep
discount" on some other system that was totally off-limits to the bulk
of students or faculty of the school. His actions were totally
unethical, but unfortunately, things of this sort seem to happen a
lot. [School officials are often naive and inept with regard to
controlling their employees and their abuses.]
Eventually, largely due to the efforts of former Poly students who had
become DEC employees, DEC loaned a PDP-12 system to the school, but
only for a single year. DEC, not really capable at dealing with
outside opportunists also seeking freebies, succumbed to overloading
their budget giving away, completely without charge, far more
equipment to other agencies [some of which were not even academic
institutions] essentially freezing out any further cooperative
arrangements; this was to the mutual detriment of all parties in the
end, but the people dealing with the other outsiders were not
accountable to those dealing with this school; this unfortunate
sequence of events, perhaps early on, shows the tendancy of being a
too-large corporate entity that later would be their entire undoing;
history bears this out.**]
P?S/8 was developed starting in 1971 from an MS/8 foundation. It runs
on minimal PDP-8 configurations, supports somewhat device independant
I/O and requires a random-access device for the file system (DECtape
is
random-access!). P?S/8 runs compatibly on most PDP-8 machines
including
DECmates, excepting only the PDP-8/S and PDP-5. P?S/8 is still being
developed!
[**cjl: There is a definition for most of the PDP-8 models, and is
generally known as the "Family of 8" which includes all models from
the straight PDP-8 through the PDP-8/a. Most notably, the PDP-5 and
PDP-8/s are specifically excluded. Systems known to only run on the
entire "Family of 8" configured with TC01/08 DECtape include the R-L
Monitor System, P?S/8, Poly Basic, PS/8, OS/8, and the DECtape Library
System. It is rumored that there may be a PDP-5 and/or LINC-8 version
of the Library System. There is definitely not one for the PDP-8/s.
The paper-tape version of FOCAL, 69 runs on all of these models by
self-discovery of the PDP-5 interrupt structure and self-modifies to
accomodate the different hardware. For the PDP-8/s, certain timing
constants are also self-modified dynamically.
Overall, FOCAL avoids the set of instructions that represents all
operations that cannot run on the PDP-8/s or the PDP-5. O/S-specific
versions of FOCAL, 69 are known to use additional instructions that
cannot work on the two problematic models, since the operating systems
themselves wouldn't either.
P?S/8 can run on the same exact configuration as the R-L Monitor, but
supports up to 8 TU55/56 tape units. All of the tape-motion-saving
tricks inherent in the R-L Monitor System are contained within P?S/8,
as well as many more, including dead-reckoning tape search thus
allowing the occasional search-first-forward situations to be time-
saving.
Versions of P?S/8 can be built for a variety of standard devices as
well as common third-party peripherals. Common versions include
TC01/08 DECtape, PDP-12 LINCtape, LINC-8 LINCtape, RX01/DSD-210, RK8E/
RK05, DSD-240, CESI MDC8 SCSI interface, 12-bit bi-directional
Interprocessor Buffer [designed and implemented by students of
Syracuse University], TD8E/TU56 DECtape, etc.
A unique feature of P?S/8 is: Should a device not be implementable in
the standard handler space of 07600-07777, the handler is extended to
also occupy x6000-x7777, where x is the highest physical field of
extended memory [field 1 through 7]. Most notably, only locations
7600-7777 are off-limits to any program in field 0, and any locations
within all fields 1 through but not including the higest field
available. There is no special restriction of the use of 7600-7777 in
any field other than 0. The disposition of x0000-x5777 can be
determined by a system program to
optionally obtain the use of 3/4 additional field of memory, if
relevant.
Another unique feature is the concept of the logical console overlay.
When enabled, aware components of P?S/8 [which is just about all of
it] are prepared to redirect all input and output to the 4 non-disk-
device data streams: Console Input, Console Output, Line-printer
Output, and Line-Printer Reverse Input Channel Input [which is
required on DEC-compatible serially-interfaced printers].
No program is normally required to service the reverse channel of the
line-printer [which may not even exist]. However, throughput may
increase if the channel is polled. [Internally, the overlay checks
input while attempting output.] Additionally, there is a logical
interrupt hook that should be enterred before checking for physical
devices which will work with the logical calls to the devices
themselves; the P?S/8 version of FOCAL, 69 runs with logical and
physical interrupts enabled. When enabled, the console overlay
occupies x0000-x5777 where x is the highest physical field, and thus
works seemlessly with a system handler that would require the rest of
that highest field of memory.
Thus, the minimum memory requirement of P?S/8 is never more than 8K
even if the handler requires extended memory and the console overlay
is enabled.
The console overlay can be configured for a variety of devices ranging
from the standard device 03/04 console to an alternate IOT pair of
devices for an alternate console device, to pseudo-devices such as the
VT8E which is actually a memory-based screen via DMA and has no actual
I/O associated with it other than enabling the DMA support.
Without the console overlay, all P?S/8 line-printer-aware programs can
only use the device 66 standard line-printer. When the console
overlay is enabled, any appropriate printing device can be used;
standard support exists for serial printers such as the LS-120
[actually a modified LA36 speeded up to print at least four times as
fast]. It is a straight-forward task to support another computer
acting as a print-spooler as a logical printer. When the actual
printer hardware is the standard device 66 printer, the console
support includes internal buffering allowing P?S/8 to print on high-
speed printers at full speed, at least as fast as 1200 lines/minutes
[which is 4 times as fast as what OS/8 can do!].
With regard to the "somewhat" device independence: Certain users
define total device independence as their [somewhat mistaken]
understanding of how OS/8 works. The easiest way to explain the true
nature of this situation is to compare and contrast all of the issues.
OS/8 allows input definitions to be from any form of input device, and
any form of output device on an output definition. Most system
programs allow multiple such specifications. Especially noticeable is
the overhead in implementing all of this, especially on devices such
as DECtapes.
In P?S/8, reading of ASCII paper-tapes is possibly directly into the
system embedded line editor if the tape is read into the standard
ASR-33 teletype console. Via a trivial utility, the high-speed reader
can be accomodated for the same purpose. It is possible to write a
more general utility if anyone cares, but the accomodation of source
paper-tapes is just not a priority, and no overhead in general will be
allowed to accomodate text-based paper-tapes.
Similarly, punching on the ASR-33 is merely a matter of choosing the
output format, and enabling the simultaneous punching on the
teletype. A trivial high-speed punch routine could be written if
anyone actually cared.
For binary paper-tape support, the P?S/8 BIN program provides all
conceivable forms of paper-tape input and output in BIN and RIM format
for the teletype and the high-speed reader and punch as relevant.
Thus, the notion of generalizing the system to accomodate paper-tapes
for general purposes has been eliminated and instead relegated to
either existent or easily-written utilities based solely on demand for
writing the trivial utilities if and when relevant.
With regard to line-printer support, the 4K basic system only supports
the standard device 66 line-printer. If the console overlay is
enabled [requiring at least 8K], the configuration can handle any
reasonable device as a line-printer; sufficient code space exists to
support "exotic" devices such as IBM 2741 terminals [which require
code conversion, something not planned for in other systems such as OS/
8, which has inadequate printer support code space to handle such a
problem.]
Thus, the only actual meaningful difference is as follows:
OS/8 can only handle a single device via the system handler. To
access another device, the system must perform many overhead-ridden
operations to transiently load in a non-system device handler, which
in turn must fit within one or at most two pages. In P?S/8, the
system device handler supports all of the relevant logical units. In
the case of the TC01/08 system handler, this means 8 logical tape
units 0-7; the same applies for PDP-12 LINCtape. For RX01 this means
drive 0 and drive 1; for the DSD-210 superset of RX01, this means
drives 0,1,2,3. On the VT78 or DECmate I, the same support is
available [despite the actual hardware being slightly different. The
handler supports both variants.] On the standard RK8E/RK05, P?S/8
supports 4 logical units on each of 2 RK05 drives.
Thus, the only actual weakness of P?S/8 is if the user expects to be
able to support a "mixed" set of devices, such as passing for instance
DECtape file specifications at the same time as RK05-based file
specifications. OS/8 can be configured to handle this situation with
high-overhead while P?S/8 is low-overhead but cannot do this one
instance of configuration difference [while running totally in 4K].
P?S/8 supports an embryonic set of superior non-system handlers, but
the only program that uses it is the BLKCPY program, which supports
excellent copying with optional verify, and comparing of two totally
different disk-type devices. The intention is for a future
implementation of an additional file-structure that will support more
general disk-type device operations. In exchange for requiring more
memory [perhaps 16K minimum], much larger devices will be supported.
A key feature [already supported by BLKCPY] is the notion of cluster
size.
In terms of the common system block size, P?S/8 current support is a
cluster size of 1; OS/8 records represent a cluster size of 2. The
maximum device size that can be contemplated is a cluster size of 32,
which means the scope of such a system is 16 times as large as the
maximum addressibility of OS/8. This roughly corresponds to about 25
MB of storage per logical device. The specifications for this upgrade
may change over time, perhaps allowing even larger
devices. The current P?S/8 system device always supports a cluster-
size of 1, and all blocks up to 4096 assuming the physical hardware
exists. Thus, for any one P?S/8 system device, this is exactly half
the space that the OS/8 system handler addresses. However, this also
means that programs are not required to allocate two-page input and
two-page output buffers for writing, although the larger the buffer,
generally the faster an application might run. In any case, the
inherent granularity is based on a singe-page-sized block/record, not
a two-page one. Thus, a P?S/8 system could choose a three-page
buffer, while OS/8 would require allocation in pairs of pages for any
input or output buffer. This is the "price" of a compromise of
accessing up to 4096 logical records each of which are twice the size
of what P?S/8 addresses. However, OS/8 also needs to load a non-
system handler or handlers to gain access to "sister" devices such as
additional DECtape drives, while the P?S/8 system handler can access
any and all of them that physically exist [and again, this is in 4K
for the TC01/08 DECtape and several other devices such as TD8E/ROM,
PDP-12 LINCtape, modified LINC-8 LINCtape's two drives, SCSI systems 8
mappped drives, DSD-240 8 mapped drives, etc.] as well as other
devices requiring 8K or more such as RK08, RK8E, TD8E/non-ROM, RX01,
etc.]. Assuming a P?S/8 system handler can handle 8 logical drives
such as physical TC01/08 tape drives, the scope of the P?S/8 system
handler is to address 4 times as much as the OS/8 system handler.
[Each of 8 are 1/2 of what OS/8 does for a total of 4x. On the RK05,
the P?S/8 system handler addresses two entire RK05 drives. OS/8's
system handler addresses in one unit two P?S/8 equivalent units, but
needs additional non-system handlers to get at the other three [P?S/8
equivalent six] disk areas, etc.]
Most notably, P?S/8 totally supports all DECmates with no
modifications whatsoever. This is accomplished by a logical-abort
mechanism. [Note: This feature is unrelated to and compatible with
the logical console overlay.] No special features of DECmates need be
considered, except for the system device itself. Most notably, the
RX01 version of P?S/8 works on DECmates with no modifications; thus a
single suitably-configured P?S/8 8" diskette can be booted on a
straight PDP-8 through a DECmate II.]
P?S/8 was offered to DEC, twice, and turned down for arguably
frivolous or worse reasons. The only thing in return demanded was
free support to the school where Poly Basic was written, and many of
the relevant people both inside and out of DEC met each other as
students. Some basic support documentation for the original proposal
was created by the very same people who supported OS/8, all of whom
were very familiar with the internals of the original system. Thus,
you had an eager staff, already familiar with the product, demanding
no salary increases or other overhead. The only "cost" to DEC would
have been:
1) Writing off existent hardware loaned/transferred to the school.
Write-offs often are actually profitable [such as was the case with
some LSI-11 systems].
2) Encurring internal costs of labor of tech writers to take the
notes of the programmers [including me] and turn it into acceptable
documentation manuals; DEC's standard for a manual wasn't really all
that high typically, and this represents a quite low cost. Anything
else would involve marketing's estimate of just how much they wanted
to push the system, and the costs to print manuals and advertising
materials.
3) Dealing with a largely already-existing product, with expected low-
overhead ongoing maintenance costs. Compare that to the problems
associated with what they developed from scratch later, often at the
hands of far-less-competent programmers.
4) A lot of DEC software is essentially free for customers with the
purchase of the machine. It would not be clear if any specific charge
was intended, but in any case, due to the low costs, it would be
really easy to sell it rather inexpensively, and thus could clearly
become a profit center.
Admittedly, if they had to support the entire project from scratch,
they probably couldn't have afforded it. However, it was always made
abundantly clear that the actual software development level of P?S/8
far exceeds ANYTHING that DEC ever produced; the internal
documentation standard exceeds the quality [slightly!] of the source
code of KERMIT-12, a free project I also wrote, and anyone can look at
the source code if they need to confirm this. [Note: The reason
this is the case is that I inherited the code for Kermit-12 from an
earlier, largely non-functional effort by many other well-meaning but
ultimately not very clever programmers, one of which freely admitting
the true nature of this.
It is often easier to 100% rewrite bad code than merely "fixing" it,
etc. But I wanted this project to remain a shared "effort" when in
fact, after a certain date, I was responsible for virtually all of the
updates, complete with a complete history/audit trail and comments on
each and every line relevant to the edit history, etc. Thus, the
quality of this code is merely, by my personal standards, pretty good;
when I write my own code from scratch, things are somewhat different.
For an example of something closer to P?S/8 internals, consult the
source code of my disassembly from scratch of the DECmate II firmware/
ROMs. In this case I didn't have to "undo" the works of others, other
than notice certain poor programming techniques I couldn't change,
because the mission was to produce the source code compatible with the
binary of the ROM, not "improve" it, etc.]
Certain ignorant individuals make reference to a "company" I
suppposedly worked for. That company consists of my brain, eyes, and
hands. I did a lot of consulting work on applications for many
organizations. Where relevant, P?S/8 was given to them free. The
only exception was a situation forced by various corporate "suits" who
wanted to play the game of "what if I were run over by a truck" which
clearly never applied to this day. Eventually, they insisted on
obsoleting their need for P?S/8 causing me to charge them additional
money to rape the source code so it could be assembled by PAL8 [the
application is stand-alone; neither P?S/8 or OS/8 plays a role beyond
development.]. However, dynamic optimizations within the source code
were lost and became static; future development would cause the code
efficiency to drift away as a result. I told them the downsides, but
they insisted on paying me to ruin the code somewhat.
Eventually, after DEC had its two chances to figure it out, I sold a
limited royalty license to Intersil with them fully aware that the
unmodified system was still being given away to qualified individuals.
The only actual "customizations" was a set of trivial patches
replacing the string "P?S/8" with "IFDOS" and that they would have to
pay for system upgrades at their option, while the free version was
rapidly making their stagnant version obsolete.
This also includes a non-disclosure agreement of the source code,
which I only gave them listings of, not source files. [The price was
right for what they got; they didn't want to pay more, and that was
their decision; I offered reasonable rates for whatever they wanted,
other than giving them exclusive ownership which I refused.]
Due to my personal circumstances, P?S/8 is not currently available,
and I hope to overcome my various personal hardships to again make it
available on some basis. Clearly there is no current commercial
impact here, but I do insist on maintaining overall control of the
release, unless and until someone else come forth with proof [to me]
that they fully understand how the code works sufficiently to work
independently in a way that will not dis-improve the quality of the
system. Newbies need not apply. However, documenters, not code-
writers are largely welcome, and some of the documentation is under
the control of others. I am good at providing a lot of raw
information, but I don't claim to be a proper manual writer! **]
Richard F. Lary developed a system called the Fully Upward Compatible
Keyboard Monitor; and between a Wednesday and the following Friday, a
prototype was up and running from DECtape. The original intention of
this project was to build a programming environment for the PDP-8 that
looked like TOPS-10 on the PDP-10. A year later, this was released as
Programming System/8 (or PS/8), and then renamed OS/8 in 1971 because
Eli Glaser (a salesman from Long Island) said he could sell more
systems
with an operating system than with a programming system, and because,
by
renaming the system, DEC could increase the price despite Nixon's
wage-price freeze.
[**cjl: A correction: There is nothing, beyond the obvious result of
the unstated acronym, in any aspect of PS/8.
However, it was actually known as the "First" such, not "Fully" and as
the joke progressed, there was the notion that if another system were
ever postulated, it should be the Second Upward Compatible Keyboard
Monitor. According to certain individuals claiming to have a modicum
of contact with the relevant time period, there may or may not have
been the word "Editor" [followed without emphasis by "and"] after the
word "Keyboard". Given the improvement in the resulting acronym, this
perhaps is plausible. [I personally was "there" before and "after"
but not "during" the few days in question.]
At that early stage of development, the resemblance to TOPS-10 would
be rather tenuous. Far later into its development, OS/8 added CCL
which ran with so much overhead, it was recommended to be disabled on
DECtape and similar systems. Admittedly, the CCL implementation did
somewhat improve the resemblance all the way up from tenuous to
minimal. **]
OS/8, developed in parallel with P?S/8, became the main PDP-8
programming
environment sold by DEC. The minimum configuration required was 8K
words
and a random-access device to hold the system. For some devices, OS/8
requires 12K. There are a large number of OS/8 versions that are not
quite portable across various subsets of the PDP-8 family. RX01
images of
OS/8 Version 3Q are available, with DEC's free non-commercial use
licence,
from:
ftp://ftp.cs.uiowa.edu/public/jones/pdp8/os8distr.txt.Z
ftp://ftp.digital.com/pub/DEC/sim/software/os8swre.tar.Z
The second site above also includes an incomplete but useful RK05
image
of OS/8 Version 3R. Parts of the OS/8 source can be found in:
ftp://russ.ucs.indiana.edu/pub/DEC/PDP8/OS8/
OS/8 V3D was renamed OS/78 (to match the VT78), and in followups to
this
distribution, support for Omnibus machines was no longer important.
OS/78
V4 was developed for the DECmate I, and the name OS/278 used for the
versions released with later DECmate machines. These have unnecessary
incompatabilities with earlier versions of OS/8. OS/278 and related
material is available from DECUS as catalog item 800941, or from:
ftp://ftp.update.uu.se/pub/pdp8
ftp://metalab.unc.edu/pub/academic/computer-science/history/pdp-8/os8
[**cjl: I am not sure exactly what the relationship between a V3D and
OS/78 exactly means, but it is quite true that this was a time when
officially, support for "pre-Omnibus" machines was officially ended.
As a practical matter, all it ever meant was that the programming
department was forced to give up their PDP-12 machine, which also had
implications with regard to program debugging, because the PDP-8/e
machines of the time are inferior programming environments to a
properly configured PDP-12. At the time, DEC had no proper hardware
to support the "Straight" PDP-8 and in fact made some mistakes with
regard to the PDP-8/l that were highly complained about and largely
ignored until I personally stepped in and pointed out their mistakes.
On the PDP-8/l alone, certain operations regarding unimplemented
memory behave differently from just about all other models. Moving
around core-sizing code instructions eliminated the problem, but
because there were no valid test machines for this hardware, support
could not be accomplished on an official basis.
As newbie programmers arrived, the situation in fact got worse, as
certain source lines appeared that could not run on some of all of the
"pre-Omnibus machines". However, good PDP-8 programmers can correct
these obvious mistakes by a quick perusal of the source code. By and
large, the mistakes are glaringly obvious and merely stem from
attempts at combining group I operates that are not compatible with
the older machines, especially the Straight -8.
The support was important for these earlier machines, but was deemed
obsolete by managers. It is an interesting twist of fate that the
decision to get rid of the PDP-12 was given to a person whose
obligation was to make a choice of either getting rid of the PDP-12 or
firing himself. Many people believe the wrong choice was made.
OS/78 was not a new O/S, but rather a small few new releases of
programs totally compatible with the previous edition, coupled with a
few new features that, while associated with the VT78, actually were
merely restricted to certain configurations. For example, a printer
spooler that supported certain specific printers was added. It
actually required, not a VT78 at all, but rather, it needed exactly
16K as written [the standard memory of the VT78], and that all system
devices not use DMA, such as the RX01 which was standard on the VT78
or on similarly configured other machines going all the way back to
the original Straight -8. The 16K portion could be rewritten for more
memory if required [such as on a 32K PDP-8/e], but the DMA restriction
could not be gotten around because OS/8 cannot in general run every
aspect of itself while interrupts are on [which was how the spooler
worked]. [The problem is that no program understand the requirement
to never overlay location 00000 while interrupts are on. As long as
DMA is off, this can be sufficiently inhibited by turning interrupts
off if requird, call the handler, then turn interrupts on, etc.
The rest of OS/78 was actually a useless step backwards that was left
in all newer versions. In essence, a status word bit was created that
meant the associated program could not be run, other than from CCL,
should the system be set to "OS78" mode that monitored the bit. Thus,
by releasing all system programs with the bit set, none of them could
be run in that mode.
In an embarassing episode, I witnessed [and acted somewhat as a co-
conspirator] in turning a system totally useless at a DECUS demo, as
the only copy of a demo version of the system with this "feature" was
ruined in seconds: The CCL.SV program itself also had the bit set!
Thus, by turning off CCL itself, no program could run at all! To re-
enable CCL requires running CCL.SV, but that was disallowed! Thus the
notion of living and dying by swords.
The incompatibilities mentioned are *not* unnecessary! Rather, they
are the consequences of feeble and misguided attempts, hopelessly
impossible, to make the system even work on incompatible hardware.
None of the systems that were modified for DECmate usage actually
work; they are riddled with bugs. It is literally impossible to make
OS/8 work on DECmates because of the incompatible hardware. The only
way to solve this requires redesign of all of the console I/O
throughout the system [and this code is NOT device-independent in the
slightest!] and redesigning the system-resident portion to support a
logical abort condition as I have described elsewhere, and already
implemented on P?S/8. **]
A growing collection of OS/8 documentation, including the OS/8
software
support manual on the internals of the system is available on line
from:
OS8 (no slash) may still be viable. It requires 8K of main memory, an
extended arithmetic unit, and DECtape hardware. Unlike most PDP-8
operating systems, it uses a directory structure on DECtape compatible
with that used on the PDP-10.
[**cjl: Russell Hamm's OS8 is a unique system. It runs on a PDP-8
but requires a normal PDP-10 DECtape, and uses the reserved boot area
for the PDP-8 instead of what would be present for the PDP-10. PDP-8
EAE is required, but not the slightly larger EAE instruction set of
the PDP-8/i and PDP-12 or the even larger EAE set of the PDP-8/e. The
assembler for this system is a modified version of MACRO-8. [A small
tidbit: Hamm did not like "page" numbers and instead preferred to
call each one a "leaf".]
Hamm conceived of his system as a way to develop programs using PAL10
when the system tape was brought to a PDP-10 and to use its own
utilities when booted to a PDP-8.
Most notably, the editor for this system is an incompatible version of
TECO, which was in turn stolen from Hamm totally without his
permission and at his expressed objection. It was converted into a
version for OS/8, retaining all of its incompatibilities with the
standard TECO. Eventually, the code was largely rewritten, originally
by Richard Lary, and is the basis for the compatible version of TECO
used on OS/8.**]
The timesharing system TSS-8 was developed by Don Witcraft and John
Everett
at DEC, starting in late 1967, and with the first beta sites up and
running
in the fall of 1968. This was based on a protection architecture
proposed by
Adrian Van Der Goor, a grad student of Gordon Bell's at Carnegie-
Mellon.
It requires a minimum of 12K words of memory and a swapping device; on
a
24K word machine, it could give good support for 17 users. It was
the standard operating system on the EduSystem 50 which was sold to
many
small colleges and large public school systems. The first
installation was
at Lexington High School in Massachusetts, and the second was at
Northern
Arizona University. Each user gets a virtual 4K PDP-8; many of the
utilities users ran on these virtual machines were only slightly
modified
versions of utilities from the Disk Monitor System or paper-tape
environments. Internally, TSS8 consists of RMON, the resident
monitor, DMON,
the disk monitor (file system), and KMON, the keyboard monitor
(command shell).
BASIC was well supported, while restricted (4K) versions of FORTRAN D
and
Algol were available.
Significant parts of TSS-8 have been found, but at this time, nobody
has
managed to recover a complete working system. Much of the available
TSS/8
code can be found at:
http://www.spies.com/aek/12bit
[cjl** Statements about how many users on a TSS/8 system can be highly
subjective. In any case, the user-level of a 4K-only PDP-8 system was
a limitation that would become intolerable as third-party competitors
to TSS/8 appeared, especially in commercial situations.
Please note that the model of a user remains the same for all systems
of this type: The user is on a dial-up connection to a computer miles
away. All that the user likely has is a dial-up modem and a
teletype. Still later, perhaps a slightly faster terminal, running
not at a mere 110 baud, but at the crisp rate of 300 baud!
TSS/8 would be the last attempt on the part of DEC to have a foray
into the commercial world of time-sharing PDP-8s.
The competition was far better, and could take advantage of newer-
still PDP-8 hardware, some of which came from third-party hardware
vendors. **]
Jim Dempsey, an alum of the OS/8 group at DEC, developed ETOS for
Educomp
(later Quodata) for the PDP-8/E;
[**cjl When it first appeared, Educomp was a somewhat sleazy
operation, sending out salesmen to land contracts with naive educators
in various places, most notably certain school districts within a few
hundred miles of DEC's headquarters in Maynard, Mass. Instead of
discounting the systems, EDucomp provided questional enhancements and
charged the institutions above DEC list price. The principle of value-
added was not being practiced here. The obfuscation of DEC products
with Educomp identities was done to limit the ability of the customer
to find out just how
badly they were hoodwinked. We can only speculate on the significence
of the corporate name change. **]
;this was a true virtual machine operating
system in the spirit of IBM's VM/370,
[**cjl: I think the writer of this document does not have a good
understanding of the PDP-8 time-share trap. So far, this is a
description shared with TSS/8. **]
and a special board was required
to optionally trap JMP and JMS instructions; this was enabled after an
emulated CIF instruction so that the actual change of instruction
field
could be emulated when the JMP or JMS was attempted.
[**cjl: The distinction of ETOS was that, while it ran on a 32K PDP-8/
e, it attempts to only allocate at most 8K to any one user. The
theory is that at any one moment, a PDP-8 program has its own
instruction field, and perhaps a different data field for indirect
data references. Thus, as long as this environment is obeyed, only 2
4K memory fields are in use. [This does not mean 8K, but rather two
4K segments, sometime 8K, but the data field could be a still higher
field for instance; the scope of the program could be 32K, but at any
particular moment, the program is in one field, and the data is in
either the same field as the program, or in one specific of the 8
choices available on a 32K machine. To handle this situation requires
getting around a lot of overhead, because the PDP-8 inhibits
instruction-field changes until just after the next JMP or JMS
instruction is executed. An alternate way of doing this, used by
other systems, is to instead emulate every one of the hopefully few
such instructions between the CIF instruction and the next JMP or JMS,
although there are no fixed rules. Because of all of the overhead of
this
system, which includes the likelihood of also having to page in 4K at
a time after likely swapping out [by writing] a former field now
dormant, it was felt that such hardware would make the system work
somewhat faster, but only minimally. Note also that since ETOS
requires it, this is also a lock-in mechanism. Most notably, I was
present when this system was announced at a DECUS symposium. Various
members of the then-current DEC PDP-8 programming staff were also
present, and the consensus there was that the required hardware
couldn't be justified because decent programming techniqes should
produce a comparable result in performance. Other systems also exist
without this hardware requirement, etc. **]
After leaving Quodata
and founding Network-Systems Design in 1976, Dempsey went on to
develop
OMNI-8, first installed at Ripon College; initially it was priced at
$4900,
several hundred copies were sold.
[[cjl: NSD was a corporation, and not founded by any one individual;
Jim Dempsey was not that much of a contributor to OS/8 itself, but was
quite familiar with how it works, as are many of us. He is very good
at making such a system work, and knows how to properly exploit
additional hardware, when available. I was personally involved in the
development of some of the key components that made OMNI-8 more
successful; this does not imply that only OMNI-8 takes advantage of
them! **]
The OMNI-8 operating system supported
the enlarged PDP-8 address space of the CESI (Computer Extension
Systems
Inc) memory cards, and when CESI began making PDP-8 clones, OMNI-8 was
extended to support asymmetric multiprocessors (one CPU handled the I/
O).
The end of OMNI-8 development came around 1990. Dumps of the ETOS
kernel
and drivers survive in various places, and Jim Dempsey still has the
full
source for OMNI-8.
[**cjl: The key design goal in OMNI-8 was elimination of overhead. By
always allocating 32K to all users both logically and physically, the
overhead of ETOS was totally eliminated. This became a practical way
to make a much more effective system because DEC developed the KT8A
and support for up to 128K of memory. Thus, swapping out users became
less of a problem, and less seldom would be resorted to.
Even better, CESI developed 128K memory boards that were far more cost-
effective than DEC's products, and better than totally compatible:
They were as fast as the bulkier core memory, and were more efficient
of slots than the inferior DEC dynamic memory, which was incompatible
with the PDP-8/e processor, and took 4 times as many slots [the core
memory took 8 times as many slots!] Thus, using the CESI memory gave
the fastest CPU and memory at largest DEC-supported size in a PDP-8/a
hex-board CPU box.
Additionally, CESI created a replacement board for the KT8A that could
address as much as 4 128K boards for a total of 512K words. On such a
system, many more users could be supported with far less disk-swap
overhead unless a far larger collection of users were on-line at the
same time.
To make the system perform that much faster, I was part of the CESI
project to develop a SCSI-based DMA peripheral with low PDP-8 overhead
which seriously makes OMNI-8 run even better [MDC8]. The overhead on
the PDP-8 is minimized because not only is the data performed via DMA,
the operation is initiated by DMA also, from the image of a SCSI
command in
PDP-8 memory. Thus, there are typically two phases of DMA, one to
obtain the command, and then later to carry out the DMA for the data
read or write. Additionally, transfers were allowed to be as large as
32K in a single command!
I am unaware of a complete PDP-8 replacement from CESI, but they did
announce various components: A 6120-micro-based CPU replacement for
the Omnibus; I assume it would have its own 32K on the system board,
and perhaps some other interfaces. There was also a CESI RX-type
board that allegedly could support drives that could support some form
of media compatibility with RX50 and perhaps RX01/02/03 as well.
[Note: DEC never marketed the dual-sided RX03; however there are OS/8
and P?S/8 drivers for the diskettes, so there is a foundation for a
two-sided diskette. Data Systems Design marketed a PDP-11 interface
and drives that took advantage of the RT-11 support for these drives
that was inherent in the software.]
Clearly, a smaller "front-end" machine could off-load some of the
overhead in a dual-machine OMNI-8 system for even more enhanced
performance with many users.
Thus, a fully implemented OMNI-8 system was far more powerful than any
of its competitors, something all of them realized as they all quickly
went out of business because they simply could not compete with such a
more powerful system that represented such a major step up for the
commercial operators of such systems. **]
Other timesharing systems developed for the PDP-8 include MULTI-8
and MULTOS. The source for MULTOS is available from:
ftp://ftp.update.uu.se/pub/pdp8/multos8
[**cjl: I know little of MULTI-8, other than it apparently couldn't
compete with the more expensive MULTOS, which was always sold with an
attitude of superiority, whether justified or not. What is known is
that it is far more low-performance when compared to OMNI-8, and its
reign as "king of the PDP-8 time-share systems" was cutoff completely
by OMNI-8. It does represent a way to write a minimal time-share trap
system for anyone interested in getting a superficial understanding of
how to perhaps write such a system. However, the difference between
something that merely functions at all and functions far more
efficiently is apparent here. Only those who really understand the
internal differences between at least OMNI-8 and any other potential
competitor can appreciate the profound difference between these
various systems. An important design criterion is the notion of space
versus speed. In this case, having a lot of memory trumps a lot of
other considerations. As the principle author of a system capable of
running in minimal memory, yet efficiently dynamically taking
advantage of all memory available, I can appreciate the design goals
on these systems.
However, I personally have little interest in time-sharing PDP-8s, and
am not likely to write software that would depend on the standard time-
share trap hardware. Part of this is because the VT78 and related
micro-systems, and all DECmates are incompatible at the hardware level
with such a system. Because of the orphaned situation, it makes more
sense to devote development resources to something that can run on any
DECmate, and also on suitably-configured similar PDP-8 systems, not
something that cannot run on anything newer than a PDP-8/a. **]
CAPS-8 was a cassette based operating system supporting PAL and BASIC.
There are OS/8 utilities to manipulate CAPS-8 cassettes, and the file
format on cassette is compatible with a PDP-11 based system called
CAPS-11.
[cjl: CAPS-8 is rather primitive and quite slow; OS/8 utilities have
to be aware of the private format of the cassette files that are
tailored for easier usage on PDP-11s, but it did work [slowly].**]
RTS/8 was a real-time system developed by DEC, developed from an
earlier
system, SRT8, dating back to at least 1974. Curiously, even the last
versions of RTS/8 continued to support paper-tape and DECtape. RTS/8
also
offered a virtual PDP-8 for background processing, unlike ETOS, this
did
not require special hardware; instead, software emulation was used to
retain
control of the machine between the CIF instruction and a following
JMP or JMS. Source code for most of the versions of RTS and SRT is
available from:
ftp://metalab.unc.edu/pub/academic/computer-science/history/pdp-8/rts8
[**cjl: I manage the referenced archive.
RTS/8 is not an operating system per se, rather it's a memory-based
complex application that can easily be launched from any loader-type
system such as OS/8, which does not participate in what RTS/8 does.
This is not a time-sharing system in any sense of the word. It
includes the ability to support interrupt-driven tasks that can
support writing out files compatible with certain devices also
supported by OS/8.
However, the components accessing the devices is not OS/8, just obeys
the file conventions on the device. There is also support for a
single virtualized CPU which can work with the OS/8 file task to give
the notion of a single OS/8-style user under RTS/8. The scope of this
virtualized PDP-8 is for a fixed smaller size of memory, since all
tasks together must fit into available memory, maximum 32K total.
Thus, the virtualized machine may be 8K for practical reasons.
Nothing about the virtualized machine, or anything else for that
matter, is swappable. Just as in
all of the time-share PDP-8 systems, the instructions between CIF and
JMP or JMS must be emulated. As in all systems other than ETOS, there
is no additional hardware required beyond the standard time-share
trap, as there is no attempt being made to give the illusion of more
memory than physically available with much reserved for RTS-8 tasks,
not virtualized OS/8-related operations. **]
WPS was DEC's word processing system, developed for the 8/E with a
VT50
terminal with special WPS keycaps replacing the standard keycaps, and
widely used on the 1980's vintage machines. It was heavily promoted
on
the VT-78, and when the DECmates came out, DEC began to suppress
knowledge
that DECmates could run anything else. WPS-11 was a curious
distributed
system using a PDP-11 as a file server for a cluster of VT-78 WPS
systems.
DECmate/WPS Version 2.3 is available from DECUS for the DECmate II and
DECmate III under the catalog entry DM0114.
[**cjl: The DECmates came standard with WPS keycaps, not the usual
VT-220 versions. **]
COS-310, DEC's commercial operating system for the PDP-8, supported
the
DIBOL language. COS-310 was a derivative of MS/8 and OS/8, but with a
new text file format. The file system is almost the same as OS/8, but
dates are recorded differently, and a few applications can even run
under
both COS and OS/8. COS was the last operating system other than WPS
promoted by DEC for the DECmates.
[cjl: Dibol-8 predates COS-300 and the later COS-310. It was
actually a thinly-disguised version of the R-L monitor, but was
replaced by the COS versions, which are mostly based on OS/8.
Since COS-310 for DECmates didn't have to be compatible with OS/8, the
incompatible console hardware of the DECmates was handled
appropriately for a "land-locked" system that didn't have to support
any other programs the way OS/8 had to. Whatever internal conventions
apply in COS-310, there is no need to support OS/8 internal features
whatsoever. In any case, COS is not a general operating system and
does not replace OS/8 in any sense. It is apparently also
somewhat needlessly divergent due to an apparent lack of caring on the
part of the later developers. **]
SCPSYS, developed by D. C. Amoss prior to 1974 at Clemson University,
is
a system that copies most of the features of LAP (the LINC Assembly
Program) for a pure PDP-8 based system. A DECtape of this system has
recently come to light, with one known application, Spacewar.
[cjl: I am unfamiliar with this system. However, I have been involved
in many attempts to draw figures on an oscilloscope, including the
legendary VOPITA debugging program developed on the R-L monitor. The
oscilloscope is a tedious device to perform editing on; output must be
minimal to be effective; it would be helpful to obtain a "long"
phosphor 'scope such as is used on the LINC-8, where additionally
there is more hardware to help draw sequences of dots with fewer
instructions. Assuming an upper-case character is a 4x6 dot pattern,
the LINC-8 and PDP-12 include instructions to draw a "half" of a
character with a single instruction, but on a PDP-8 this is much more
inefficient.
The use of the oscilloscope as an output device for the P?S/8 console
overlay was considered, but abandoned because all of the effective
machines obtained far faster hardware to accomplish a more powerful
result.
It is also possible this system supported a storage oscilloscope,
which would include some form of screen erase and single paint,
instead of an unaided generic refreshed oscilloscope display tube.
Such a device would be far easier to support in P?S/8. **]
AMOS, an operating system for the PDP-8/E with TD8E DECtape interface,
was a very small system developed in Australia or New Zealand and
supporting
assembly and text editing on a 4K machine.
[**cjl: This is the system we were originally discussing. Not much of
it was ever developed; it is still not clear why this little hardware
was to be considered viable, since supported hardware requires either
8K [12K for OS/8] or the MR8E-C field 7 ROM [and 8K for OS/8]. By
adding in that upgrade, the hardware could then support P?S/8 or
EduSystem 15-30 or OS/8 if more memory was also added.]
[cjl: Apparently I have to answer my own first question above: There
is no mention of CPS-4K, CPS-8K, or any LINC-8 or PDP-12-specific
operating systems at all, including the DEC-supported LAP6-DIAL/DIAL-
MS for the PDP-12.
CPS-4K runs on unmodified 4K LINC-8 machines or certain newer PDP-8s
outfitted with proprietary hardware from Cooley Laboratories and
Computer Operations. There are system feebilities caused by the
limitations of the tape interface as implemented in the unmodified
LINC-8, which were lock-step copied into the PDP-8 positive buss
version. It shares a lot of the limitations of the R-L monitor.
However, it requires two tapes to run in an asymetrical manner.
CPS-8K is an outgrowth of this system and requires 8K. It was one of
the first systems to support a modified version of the SABR/Fort II
Fortran [as purchased by DEC from a third-party software outfit], and
was at one point considered to be what would have been marketed in
lieu of OS/8 had it not been written. It's existence is part of the
reason why the original PS/8 implementation was so quick-and-dirty.
It is not known what if any improvement was made in the tape handling
in the 8K version over the 4K version. Due to a blunder, the 4K
version is needlessly incompatible with all other LINCtape
implementations;
Standard source-code subroutines widely used within CPS-4K actually
contain two patchable words to allow fully compatible operations, but
the main system was never patched to be compatible. It is not known
if the 8K version also had this needless incompatibility [it could
have been fixed in either version.]
All of the other systems I mentioned are in the style of various older
systems for the 2K LINC that run on the "standard" smaller, yet
clumsier, LINCtape that is the only media that is LINC-compatible,
while the LINC-8 and PDP-12 are more flexible. Other than P?S/8, and
unfortunately poorly OS/8 and PDP-12 DIAL, none of the systems
mentioned here support the notion of mixed PDP-8 and LINC programming
on any of these machines despite the vital pairing at the hardware
level. In most of them, the PDP-8 is actually ignored; on a small
few, it can only be handled separately, not in consort with the LINC
CPU.
The OS/8 problem has to do with the modifications made to PAL8 to
become a user-provided PAL12 apply to a too-old version of PAL8 that
was updated years after the PAL-12 modifications were added to the
then-obsolete version. Additionally, OS/8 can only be run on either a
modified LINC-8 or in one unusual configuration, a differently
modified LINC-8 made to support a DF32. DIAL only runs on PDP-12
systems.
Anyone else have any other -8 systems in mind?
cjl **]
Serious followups only, please.
Trolls and other worthless off-topic posts should be directed to
alt.null.
Me
news:d66a1533-b34d-48f1...@g6g2000vbr.googlegroups.com...
> Now that all of the noise of the ignorant, clueless, opinionated
> without factual basis, off-topic and other defective posts on this
> subject has faded away,
Who was it told you that negative pomposity was not a personality defect?
jmfbahciv
> Now that all of the noise of the ignorant, clueless, opinionated
> without factual basis, off-topic and other defective posts on this
> subject has faded away, I was able to find this independent round-up
> of all of the relevant systems most of us have heard of in the
> collective sense. [I don't know of all of them and I learned a few
> things!]
>
> Serious followups only, please.
>
> Trolls and other worthless off-topic posts should be directed to
> alt.null.
>
Since you consider me to be clueless, I won't comment. You do
know that you've also considered one of the original developers
to be clueless?
/BAH
cjl
> "cjl" <clasyst...@gmail.com> wrote in message
See if you more understanding people in a.d.h can help this disturbed
individual, who suffers from drug-induced paranoid delusions and the
need to act out, etc.
cjl
cjl
For someone demonstrating paranoid delusions, you obviously can't
count, since your 25-word long non-comment is 25 words longer than a
non-comment in real-world terms. Please followup to alt.math where
they can perhaps direct you to some remedial math courses for
kindergardners; it might be a little advanced for you, but perhaps
they'll speak real slow and in short sentences so you might understand
it a little.
I'm also sure that people you claim to speak for appreciate your
unauthorized outburst. Unlike you, they can speak for themselves if
they have a problem.
And I'm sure you have a theory about posts from non-existent
addresses.
cjl
Charles Richmond
And they also forgot to tell you that pontification should be left to
the Pope. ;-)
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
TrailingEdgeTechnologies
> Me wrote:
> > "cjl" <clasyst...@gmail.com> wrote in message
> >news:d66a1533-b34d-48f1...@g6g2000vbr.googlegroups.com...
> >> Now that all of the noise of the ignorant, clueless, opinionated
> >> without factual basis, off-topic and other defective posts on this
> >> subject has faded away,
>
> > Who was it told you that negative pomposity was not a personality defect?
>
> And they also forgot to tell you that pontification should be left to
> the Pope. � ;-)
If the Pope can only pontificate <ex cathedra>, what about
statements made while he's in the Popemobile: are they
only valid pontifications whilst the Popemobile is crossing
a bridge?
Just thinking out loud again.
BBR
Quadibloc
> Now that all of the noise of the ignorant, clueless, opinionated
> without factual basis, off-topic and other defective posts on this
> subject has faded away,
Unless we know which posts you are referring to, the angry emotional
tone of your post will guarantee that it is going to be the one that
is considered nonserious, however factually correct the rest of the
post may be.
As it happens, there is a lot of factual information about the PDP-8
and the timesharing systems available for it on the web. The manuals
on Al Kossow's site, for example.
I know that you could indeed have a nice timesharing system on a PDP-8/
I, and that it let you use DECtape as a random-access device. And the
timesharing system, OS/8, would seem very familiar to people today,
because CP/M looked a lot like it (except that filenames were 8.3
instead of 6.2).
Other than that, I'm no expert; I wasn't sure what point your post was
trying to make.
John Savard
Charles Richmond
"If a tree falls on the Popemobile and there is *no* one there to hear
it, does the Pope still get a headache???"
cjl
> On Jul 12, 3:32 am, cjl <clasyst...@gmail.com> wrote:
>
> > Now that all of the noise of the ignorant, clueless, opinionated
> > without factual basis, off-topic and other defective posts on this
> > subject has faded away,
>
> Unless we know which posts you are referring to, the angry emotional
> tone of your post will guarantee that it is going to be the one that
> is considered nonserious, however factually correct the rest of the
> post may be.
Actuallly neither angry or emotional. Blunt and dismissive of
kiddies, and written from a position of deserved authority of actual
knowledge, gained the usual way, through actual relevant experience,
and not through spare-time reading of Internet forums. It's not my
problem that there is a current generation of people who think
everyone is as ignorant as they are, and every topic is therefore a
target to ridicule anyone who is materially different from them.
Nonsensical attempts to inject off-topic items such as network-
presumption in an era where all the user had was a 110 baud teletype
and a modem, nothing else, for example.
>
> As it happens, there is a lot of factual information about the PDP-8
> and the timesharing systems available for it on the web. The manuals
> on Al Kossow's site, for example.
True, and helpful up to a point, but not to obtain a top-level
perspective on what was what back then. I haven't checked there, but
perhaps some of it I personally wrote over twenty years ago; there is
a lot of stuff I did floating around; I don't bother keeping up with
who has what merely because my name might be in it. I do run an FTP
archive of some of it though; incidentally the author of that FAQ
document referenced it as well as others.
>
> I know that you could indeed have a nice timesharing system on a PDP-8/
> I, and that it let you use DECtape as a random-access device. And the
> timesharing system, OS/8, would seem very familiar to people today,
> because CP/M looked a lot like it (except that filenames were 8.3
> instead of 6.2).
I am slightly reading between the lines of what you say here, but you
cannot dismiss the topic from a hardware-only point of view. What
specific support "matters".
OS/8 is not, never was, never will be a time-sharing system. However,
it was often the targetted emulated system running under the T/S
system, complete with support for its DECtape format, unlike some of
the former systems; this simple fact alone separates all of the third-
party systems from TSS/8 which didn't do that. Supporting DMS
DECtapes is not the same thing.
>
> Other than that, I'm no expert; I wasn't sure what point your post was
> trying to make.
Part of the problem is caused by the inadvertent and/or inappropriate
cross-posting started by others; I am admitting to being "guilty" of
merely replying in same cases; this is not confined to me only.
For example, there was a thread on other than alt.sys.pdp8 about a
system named "AMOS" which coincidentally [as the FAQ I quoted] is the
same name of an obscure O/S for a small PDP-8 system from somewhere
"down under". Inappropriately or inadvertently, some people were
posting issues not germain to the PDP-8 AMOS, and only the "other"
AMOS, in essence "wasting" the bandwidth of alt.sys.pdp8. This wasn't
a big deal, but it does point out that cross-posting can lead to
perhaps unintended consequences.
There were several points, some of them lost on people who are
incapable of reading more than sound-bites. The more they prove their
inability to read, the more it inspires me to write fully detailed
discussions as it just separates them further from the subject they
have clueless opinions on, but feel compelled to act like 5 year olds
to gain pointless attention on in their lame attempts to "get off" on
me, confined only to their little kiddy klatch.
Some others, in their ignorance only, not an otherwise agenda,
expressed opinions of an era that they only know about from reading,
as opposed to some others, such as me, who were actually part of it in
an active role.
I have no personal interest in time-sharing PDP-8s, and have made it
abundantly clear that my interests lie within the area of more
personal systems, which I feel was the forte of the PDP-8 and what led
it arguably to become the fore-runner of later systems [such as CP/
M-80, as you mentioned] that are all part of the continuum of systems
going in that direction, and away from the "iron mentality" of
computer centers, etc.
All that said, it is also true that I was a more-than-passive-observer
in some of them, because I had personal contact with some of the
authors, and in particular my path crossed with Jim Dempsey, who is in
turn responsible for arguably one of the worst of them, and arguably
the best of them, as he learned from his own mistakes [or rather the
mistakes of his [former] employer].
A general observation is that all those too closely associated with
their own TS for -8 systems probably didn't see what the "competition"
was doing, or even that there was any competition; the latter comment
apparently applies largely to anyone or anything associated with TSS/
8, which was inevitably to die because it was not only too-limited but
also too-tightly tied to hardware that was not in the then-and-future
directions the industry of PDP-8 et al peripherals were going. I
believe we even had a post from one of its implementers agreeing that
what he did was probably short-sighted, but I will welcome him to
comment and confirm that if he so wishes.
In any case, the minority of PDP-8 systems became a competitive tiny
market fueled by the needs of attracted commercial operators; the
performance of all of these systems varies over a rather wide range.
The difference between a commercial success and a dud boiled down to
how many users per system. Capabilities increased with the pace of
then newly-available hardware coupled with savvy software exploiting
it.
My only connection to any of this is that I am one of the developers
of the MDC8 high-performance SCSI host adapter for the PDP-8/a sold by
CESI. I contributed to the design spec to ensure that it could be OS/
8 compatible. [When I first arrived, they were scratching their heads
as to why it didn't work as they expected; I spec's the missing
requirements and worked with the programmers of the microcontroller to
come up with what was required, etc.] I also wrote the P?S/8 and OS/8
drivers and diagnostic utilities, and nothing else that would concern
T/S systems' code writers. However, Jim Dempsey worked directly with
my spec as to how to program the hardware, which is actually quite
elegant for use on a variety of applications, and is an integral
reason why OMNI-8 is as "industrial-strength" as it is. By design,
this was real easy for him or others to apply to their variant real-
time disk support needs. Successful systems do not use OS/8, but
rather OS/8 file-structure-compatible tasks to handle trapped
operations from the user-s image of OS/8 that do not directly create I/
O, since that's all trapped, and works best if simple to emulate, etc.
[As a side topic, I posted on alt.sys.pdp8 my recommendations for
using the MDC8 as the perferred device for writing a comprehensive
PDP-8 simulator, as the details of the I/O are so much easier to
emulate; the PDP-8 has no "cycles" for most of it; you simulate the
DMA by the innards of the emulation itself, etc.]
Simply put, the MDC8 is the highest performance disk subsystem I
believe ever was applied to a PDP-8, and since it could read or write
32K at a time, made it ideal for the needs of Omni-8, especially when
it ran in 512K. [For P?S/8 and OS/8, the largest operation possible is
limited to 4K or less at a time, measured in groups of 128 words 1 to
32 in count.]
Thus, OMNI-8 made all of the forebear systems virtually obsolete; they
simply couldn't be configured for the number of effective users OMNI-8
could easily handled, which for a commercial operator meant more money/
per hour of users on the same hardware, and less parallel systems to
setup, etc. In one low-overhead PDP-8 operation, a SCSI command is
DMA-read to an onboard intelligent micro-controller, the command is
issued to the SCSI controller[s] and then if DMA is involved, it does
DMA back to/from the PDP-8 memory. After all of that, the PDP-8 can
be interrupted to acknowledge the command was done; as low an overhead
as one could imagine for a PDP-8, and can be likened to the notion of
channel processors on System 360, etc. Omni-8 further could be made
even better by having a comm-oriented front-end machine to handle the
user's terminals, as opposed to their share of CPU operations, thus as
terminals got faster, there was no effective degradation.
I personally wrote a 40-task cooperative multi-tasking system for a
32K PDP-8/e including support for 32 comm ports/terminals/printers/
paper-tape readers/punches, etc. and it took a machine to keep up with
all of that "front end" stuff. However, my application has no time-
share or other overhead because nothing is virtual; this is brought up
merely to point out that it would be true that overhead could creep in
should a machine be big enough to have that many terminals as well as
supporting the 32K CPU tasks, infrequently swapping out the job
images, etc. Two machines would be the exact right solution, and only
OMNI-8 ever went there, etc.
Thus, it makes perfect sense for an OMNI-8 system to actually need two
machines in a really large configuration, which is what it aspired to
if the customer wanted, etc.
To completely dismiss anyone's doubts or merely ill-informed opinions,
I quoted verbatim a document I found on the net claiming to be
authoritative about just about all of the systems for the PDP-8,
whether T/S-oriented or not. Also, it is necessary to pursue the OS/8
connection to this because many of them chose to emulate OS/8 on each
user's terminal, a decision they made, but not an intrinsic
requirement of such a system; however, many other choices [other than
P?S/8] would have been problematic for a variety of reasons. I chose
to detail each and every one of them, heaping both praise and disdain
where appropriate, including my own system P?S/8 which is incomplete
by my own personal standards, but still represents a viable
alternative for some at the time; it was tentatively slated to be sold
by DEC, but never was, and it was the system of choice for some, in
other cases, both systems, OS/8 and P?S/8 were used; I myself fall
into that latter category, and since I have some expertise in both,
can accurately criticize both for their short-comings, etc.
It should also be noted that TSS/8 was not a system that emulated
anything else, arguably yet another limitation it had, while most of
the newer ones chose to emulate OS/8; further I point out that it need
not necessarily be OS/8, and as well, need not be uniquely OS/8; the
scope of a T/S system is that you can have multiple O/Ses supported,
as long as you are clever enough to support whatever you want. The
support level of code required is nowhere near an overload on the
underlying system; the system-resident task code space isn't that
much; most of these systems ran in less than 12K of total code for the
purpose of supporting 32K systems virtually for the load of the end-
users; the rest is data space for the user images. this is especially
true on a 512K machine, and only OMNI-8 supported that much available
RAM, etc. [That means that you can have as many as 15 users running
virtual machines with no swapping whatsoever. High-performance disks
meant that swapping was more efficient that any other way to do that
when/if necessary.]
Thus, what I quoted, and greatly elaborated and explained, and in a
few instances debunked, makes it clear what was going on back then.
My vantage point is not merely one of a reader after-the-fact; most of
the systems described I have had personal contact with and in the
relevant time frame, not as a newcomer, which is the vantage point of
most of those wasting bandwidth, or worst case, I have a personal
connection to someone who had a vested interest in doing so at the
relevant time.
It amused me that one of the founders of the forerunner of
alt.sys.pdp8 [which I personally created, a factoid I only offer up to
the small percentage of people who don't already know that] [it was
known back then as the PDP-8 Lover's mailing list] was proud of the
fact that he was born the same year the PDP-8/l was released, while in
fact that was one of the first 8K systems I ever worked on back when
it was brand new. Additionally, I believe the writer of the FAQ
document I referenced claims he never used any form of PDP-8 prior to
some time in the 90's. As such, he can be "forgiven" for any
inadequacy of his otherwise nice set of FAQ/documents. Perhaps some
of what I added can be used to produce a more accurate version of it.
cjl
>
> John Savard
cjl
>
> - Show quoted text -
Please stop cross-posting this to all of the groups!
cjl [and keep it out of alt.sys.pdp8]
Tim Shoppa
1. Go look up the term "Lasnerian".
2. Go look at the author's name.
3. Realize this is not a coincidence.
Charles feels very strongly on a lot of subjects on which he is an
expert. The usual net-definition of Lasnerian ignores the aspect that
in every important respect except for the most mundane, the Lasnerian
viewpoint is actually more useful.
Tim.
jmfbahciv
Thanks for the heads up. I won't waste my time anymore.
It's a damn shame, though...
While I've got you here...
I have pictures on my computer of JMF's grave marker. Where is the
best place to these? I wanted to put them on Joe Smith's PDP-10
web site, but he seems to have gone away.
I don't think it belongs on trailing-edge but I'm out of ideas
of where to put them. Help?
/BAH
Tim Shoppa
> A general observation is that all those too closely associated with
> their own TS for -8 systems probably didn't see what the "competition"
> was doing, or even that there was any competition;
The speed at which a good innovative solution or application spreads
across users, academia, and the industry can be staggeringly fast.
Sometimes the code is actually ported, other times the spirit of the
application is re-invented, other times only mundane parts of the user
interface are replicated. Just knowing something can be done well
causes many imitators - some exact, a few better, many worse - to pop
up.
> OS/8 is not, never was, never will be a time-sharing system. However,
> it was often the targetted emulated system running under the T/S
> system, complete with support for its DECtape format, unlike some of
> the former systems; this simple fact alone separates all of the third-
> party systems from TSS/8 which didn't do that.
I think the fact that so many of the good TS systems replicated the
non-timesharing user and storage interface of OS/8 speaks well for OS/
8's usability. The pattern has been repeated many times inside DEC and
across the industry.
Tim.
Charles Richmond
> On Jul 12, 11:37 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
>> On Jul 12, 3:32 am, cjl <clasyst...@gmail.com> wrote:
>>
>>> Now that all of the noise of the ignorant, clueless, opinionated
>>> without factual basis, off-topic and other defective posts on this
>>> subject has faded away,
>> Unless we know which posts you are referring to, the angry emotional
>> tone of your post will guarantee that it is going to be the one that
>> is considered nonserious, however factually correct the rest of the
>> post may be.
>
> Actuallly neither angry or emotional. Blunt and dismissive of
> kiddies, and written from a position of deserved authority of actual
> knowledge, gained the usual way, through actual relevant experience,
> and not through spare-time reading of Internet forums. It's not my
> problem that there is a current generation of people who think
> everyone is as ignorant as they are, and every topic is therefore a
> target to ridicule anyone who is materially different from them.
> Nonsensical attempts to inject off-topic items such as network-
> presumption in an era where all the user had was a 110 baud teletype
> and a modem, nothing else, for example.
>
If intellectually you are so far above the other posters here, then why
do you bother posting to <a.f.c.>??? You need to be posting on another
level of reality.
Charles Richmond
I'll make you a deal: *You* stay out of <a.f.c.> and I'll stop posting
to the other groups. Deal or no deal???
cjl
>
> - Show quoted text -
I'm not sure if this is a complement, a putdown, a parody, a ridicule,
or an undefined something else.
However, I will state for the record:
I looked up the reference as suggested. It took me to someone who
decided to take a comic view of an online feud I was a participant
in. I take offense to being the butt of his joke, so I will correct
what he posted to debunk it soundly. [And note: The referenced tale
was on alt.folklore.urban, how ironic to have to debunk something
emanating from it!]
Yes, there was a feud, and it did have something to do with a time
era, but not at all what this joker turned it into. In essence, it
had to do with a notion of someone wanting to make nitpick definitions
of "eras" as lock-step with the calendar, yet the subject matter was a
reference to popular music style of various times.
The specific subject of the debacle was the song "The Battle of New
Orleans" recorded by Johnny Horton at sometime not relevant to the
subject. In point of fact, it was released and starting to get air-
play around the USA no earlier than late summer, 1959. [I apologize if
my information is off by some weeks; it also mattered where in the
world you lived, even which portion of the USA, etc.] No one at the
time would find it appropriate to get into an unrelated nitpick
argument about the "sloth" of the music business as to additional
delay before commercial airplay even commenced overcoming various
promotion issues [perhaps payola for example, a scandal that hit the
industry a few years earlier]. Thus, you may find the recording
occured somewhat earlier, but that's irrelevant to the argument.
[After all, did it matter if it wasn't being publically played?]
The song was I believe chosen as "song of the year" in December, 1959
or early January 1960 whenever Billboard and co. make these decisions
for various reasons. And if that isn't quite accurate, certainly one
of the top 100 of the year. [And yes, the latter does mean calendar
year, but bucks the specifics of my argument about eras, not hits of
any particular year within.] Thus, the worst-case "error" in my claim
of it being part of "the '60s" is at most about 6 months, and
certainly not the silly reference to post-WWII through 1964 posted by
that joker. I wouldn't expect anyone to have any credibility who made
such a claim, and I resent the claim that I ever made it, etc.
Now, all of that said, and remember, various denizens of a.f.u are
known for their jokes and thus ridiculing others, I never claimed
anything about the time frame of the song other than the [admittedly
quick-and-dirty] short response to someone's off-hand question about
what musical period the song belonged to in my memory as "the '60s"
which I contend is accurate when referring to musical eras, not
calendars.
I don't remember the exact question's verbiage, but it certainly
wasn't when the recording studio and time/date recorded in the studio
log of when Johhny Horton made the first track recordings or any other
excessively nuanced question; it was merely something resembling "when
did the song come out; I heard it had been recorded in 1955" and that
year is likely wrong, and in any case irrelevant. One can presume the
non-asked info would be "a few months before" and in any case, it led
to quick folllowup hits for Johnny Horton [North to Alaska, Sink the
Bismark]. Had it been recorded in 1955, it would be truly remarkable
that there were followup hits so quickly, especially since one was for
a then-released movie of the same name [or is it both of them?].
In any case, my answer was in a few words: "The '60s" [perhaps my
shortest post ever!]
Anyone following the previous threads on a.f.u that framed context
[something your enemies will use against you, conveniently quoting you
out of context, claiming to quote you in responses to you, except they
corrupted what you actually said, and then railed at you for what you
"posted" and various other cowardly dirty tricks, etc.] understood
what my quick comment meant:
The era known as "the '60s" is musically speaking actually two
adjacent eras, framed by the "doo-wop" era before and disco on the
other. There had been posts by others regarding books willing to
define "the '60s" as 1960-1972 or so due to the various cultural
influences, especially music. My personal position only differed from
one such book on minor points:
The era is actually, musically speaking a pair of sub-eras. Many
people will have their specific turning points as to how to sub-divide
the two. Some want to make it the time when the VietNam conflict
started heating up. [One could argue it started in 1954.] Some were
actually back-peddling the time because they felt socially conscious
and therefore *should* have been anti-VietNam in say 1963-64, but only
got involved because that's when they started smoking pot in say,
1966-68 and felt they wanted to revise their own personal history. To
support their flakey notions, one could find reference to music of the
time, i.e., songs in keeping with what was quite topical in say
1967-70, and then backtrack to the earliest occurrence of something
that suggested what became commonplace later.
For myself, I didn't want to chose an arbitrary line in the sand, just
that there was one, and depending on what "mattered" to you, you set
the line wherever you wanted. Thus, my take on it is that there is an
"early '60s" and a "late '60s" and let the reader decide the exact
dividing line, etc.
The early 60s music can simply be defined as pop and other songs
"without a message" other than happy stuff, cars, surfing, mommas and
the poppas, early Beatles, etc. The heyday of groups such as the
Beach Boys, Franki Valli and the Four Seasons, and countless others.
The late '60s music has a more radical and often druggy or anti-war
[or both] tone to it. If you follow my definitions, tracing each to
the earliest it apparently started, and out until it tailed off, you
get almost what that author stated. However, my correction becomes
June/July 1959 through sometime in 1973. It is left as an exercise to
determine the inter-period dividing line.
Neither the dividing line nor the upper time end was ever discussed
with respect to anything I said, thus the "controversy" was simply
over the fact of whether or not I was "wrong" for claiming a song that
was first starting to get air-play in the Summer of 1959 was therefore
not part of "the '60s" and thus numerically should be forced into "the
'50s" which musically speaking is also inaccurate. The song is
clearly an early sixties pop song; it is not part of the doo-wop era
that was already winding down by 1959; yes, you can find overlap
forward; there is always evidence of that; Little Star by the Elegants
came out I believe in summer 1963, but you would want to classify it
as a song of "the '50s" or at least a retro or throwback song. But
pioneering songs like Horton's deserve to be part of the era that uses
numbers to approximate the era name by sloppily using the dominant
years' number group. [I don't think that standards from 1951 qualify
as "the '50s" since that style is best described as late thirties
through earliy fifties and is usually known as "the '40s" etc. A good
definition of "the '50s" according to my process would be something
like 1954 with early songs by the Midnighters such as the eventually
banned "Work with me, Annie" and ending somewhere in late 1958 or so,
or it perhaps wanes rapidly and has minimal overlap into no later than
1963 by any stretch. Using the notion of exponential decay, the 50's
was certainly dead before 1964 and a lot earlier unless you are
looking for "stagglers" etc.
So, in short:
a) I am wrong by at most six months, not more, and only if you use
the bogus numerical year argument which clearly didn't apply.
b) I am merely sloppy because I didn't indicate "early" or "late".
However, at the time no one would argue that leaving it out is wrong,
in fact, some refused to acknowledge I had the right to use it at all!
Thus, it is not useful to allow as gospel something from someone who
distorted the relevant facts to form a joke as an adjective taken from
my name. [An alternate explanation is there was a prank on the entire
newsgroup where all individuals were having their names "Armenianized"
which probably gave him the idea in the first place.]
cjl
cjl
The first useful thing you've posted here. You do waste your time
arguing against an expert, or do you feel that shooting your mouth off
for comic relief isn't wasteful of *others'* time.
It's rather telling that you decided I was referring to you, since I
was decent enough not to mention who did what; clueless people respond
to what they think was posted, as opposed to actually reading it and
determing what was actually posted and the implications thereof.
Apparently you still don't get the point that your comments were
inapplicable and were non-responsive to what was posted, despite your
insistence it was. By contrast, all of my posts are self-sufficent to
prevent anyone from distorting what I posted whatever their agenda,
whether clever, stupid, misinformed, or merely lazy. [See my previous
post about what others once did to me, and you will realize why I
won't risk being misinterpreted other than if some coward chooses to
quote me out of context.]
cjl
>
> It's a damn shame, though...
>
> While I've got you here...
>
> I have pictures on my computer of JMF's grave marker. Where is the
> best place to these? I wanted to put them on Joe Smith's PDP-10
> web site, but he seems to have gone away.
>
> I don't think it belongs on trailing-edge but I'm out of ideas
> of where to put them. Help?
>
> /BAH- Hide quoted text -
cjl
> On Jul 13, 2:51 am, cjl <clasyst...@gmail.com> wrote:
>
> > A general observation is that all those too closely associated with
> > their own TS for -8 systems probably didn't see what the "competition"
> > was doing, or even that there was any competition;
>
> The speed at which a good innovative solution or application spreads
> across users, academia, and the industry can be staggeringly fast.
Indeed, and since the PDP-8 has been around so long, you have to
factor that in. To the users of OMNI-8 in its heyday, TSS/8 was a
dinosaur. And so was Jim's prior work ETOS, despite the fact that
this could be perhaps two years from a commercial customer's point of
view.
>
> Sometimes the code is actually ported, other times the spirit of the
> application is re-invented, other times only mundane parts of the user
> interface are replicated. Just knowing something can be done well
> causes many imitators - some exact, a few better, many worse - to pop
> up.
In this case, what to do is fairly obvious to an expert of that era.
The distinctions came from various attempts to speed up the overall
result, taking advantage of various hardware projects, etc. If all
you want to do is have one emulated user system, you can use RTS8, as
long as you don't mind the memory size being fixed. The commercial
people wanted fast and lots of users to make lots of revenue.
>
> > OS/8 is not, never was, never will be a time-sharing system. However,
> > it was often the targetted emulated system running under the T/S
> > system, complete with support for its DECtape format, unlike some of
> > the former systems; this simple fact alone separates all of the third-
> > party systems from TSS/8 which didn't do that.
>
> I think the fact that so many of the good TS systems replicated the
> non-timesharing user and storage interface of OS/8 speaks well for OS/
> 8's usability. The pattern has been repeated many times inside DEC and
> across the industry.
Agreed. And it does have flexibility factors that lend it to be
emulatable efficiently under an "umbrella system like OMNI-8. As long
as you use the efficiency of pseudo-devices that eliminate onesy
execution faking largely.
However, it still has many problems, and there is room for
improvement. The work I did both on it and on an alternate system
puts me in a good position to be critical of it where appropriate. As
I have posted before, there needs to be a project to make it not
usable today merely for a few want-of-a-nail issues, all of which I
have addressed, at least in theory, and compared it where appropriate
to what I did in P?S/8 which solved just about all of the mentioned
problems, etc.
>
> Tim.
cjl
cjl
> cjl wrote:
> > On Jul 12, 11:37 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
> >> On Jul 12, 3:32 am, cjl <clasyst...@gmail.com> wrote:
>
> >>> Now that all of the noise of the ignorant, clueless, opinionated
> >>> without factual basis, off-topic and other defective posts on this
> >>> subject has faded away,
> >> Unless we know which posts you are referring to, the angry emotional
> >> tone of your post will guarantee that it is going to be the one that
> >> is considered nonserious, however factually correct the rest of the
> >> post may be.
>
> > Actuallly neither angry or emotional. Blunt and dismissive of
> > kiddies, and written from a position of deserved authority of actual
> > knowledge, gained the usual way, through actual relevant experience,
> > and not through spare-time reading of Internet forums. It's not my
> > problem that there is a current generation of people who think
> > everyone is as ignorant as they are, and every topic is therefore a
> > target to ridicule anyone who is materially different from them.
> > Nonsensical attempts to inject off-topic items such as network-
> > presumption in an era where all the user had was a 110 baud teletype
> > and a modem, nothing else, for example.
>
> If intellectually you are so far above the other posters here, then why
> do you bother posting to <a.f.c.>??? You need to be posting on another
> level of reality.
Perhaps you need to be reading on another level of reality.
This is an issue on alt.sys.pdp8; the cross-posting is not a product
of my doing; we have some people who feel moved to respond to arguably
only an improper subset of what I posted to, leading to waste of
bandwidth on their part, not mine.
In essence, if you don't know anything about a nuanced argument posted
by an acknowledged expert, don't waste everyone's time with
presumptive guesswork that doesn't apply to te time context of the
post; learn some discression and do the world a favor and move on.
Others who are following the thread aren't to be categorized either.
cjl
>
> --
> +----------------------------------------------------------------+
> | Charles and Francis Richmond richmond at plano dot net |
> +----------------------------------------------------------------+- Hide quoted text -
cjl
Take it up with the others who started the problem, not me.
I already called for a halt to what you are complaining about; go read
my prior complaints about it.
cjl
jmfbahciv
<snort> You are no timesharing OS expert.
<snip>
> It's rather telling that you decided I was referring to you,
It doesn't take an IQ of 1 to have figured that out.
> Apparently you still don't get the point that your comments were
> inapplicable and were non-responsive to what was posted, despite your
> insistence it was.
My comment about you blowing off one of the original OS people was
inapplicable?
> cjl
>
>
>> It's a damn shame, though...
What is really interesting is that you (cji) completely ignored this
comment.
>>
>> While I've got you here...
>>
>> I have pictures on my computer of JMF's grave marker. Where is the
>> best place to these? I wanted to put them on Joe Smith's PDP-10
>> web site, but he seems to have gone away.
>>
>> I don't think it belongs on trailing-edge but I'm out of ideas
>> of where to put them. Help?
I've sent the pics to Phil Budne. I don't know when he'll put them
on his web site, but I expect he'll post a pointer when this job
is done.
Tick. Another todo completed.
/BAH
cjl
On the contrary, you are a total asshole; the subject is and never has
been about time-sharing systems per se. If you weren't a cretin who
never read what the subject actually was, you might actually graduate
from kindergarden and find out what the subject was, namely comparing
specifically implemented PDP-8 time-share systems and their respective
limitations in an era when the only communications were at 110 baud
and sneakernet.
But that all happened before you were born, before 2003.
>
> <snip>
>
> > It's rather telling that you decided I was referring to you,
>
> It doesn't take an IQ of 1 to have figured that out.
That's correct, it's a wonder you finally figured it out at all, since
that's above yours.
>
> > Apparently you still don't get the point that your comments were
> > inapplicable and were non-responsive to what was posted, despite your
> > insistence it was.
>
> My comment about you blowing off one of the original OS people was
> inapplicable?
Since that never happened, enjoy your fantasy, kiddie!
>
> > cjl
>
> >> It's a damn shame, though...
>
> What is really interesting is that you (cji) completely ignored this
> comment.
Yes, I ignored a comment not present; unlike you I don't excise out
content whether intended or not; I ensure there is a reference to
comment on.
And the rest of this post is arrogantly on yet another totally
unrelated topic, but mr arrogant kiddie doesn't care about wasting
anyone's bandwidth while he puts bodily excrement all over all of
these newsgroups.
cjl
>
>
>
> >> While I've got you here...
>
> >> I have pictures on my computer of JMF's grave marker. Where is the
> >> best place to these? I wanted to put them on Joe Smith's PDP-10
> >> web site, but he seems to have gone away.
>
> >> I don't think it belongs on trailing-edge but I'm out of ideas
> >> of where to put them. Help?
>
> I've sent the pics to Phil Budne. I don't know when he'll put them
> on his web site, but I expect he'll post a pointer when this job
> is done.
>
> Tick. Another todo completed.
>
Quadibloc
> And the rest of this post is arrogantly on yet another totally
> unrelated topic, but mr arrogant kiddie doesn't care about wasting
> anyone's bandwidth while he puts bodily excrement all over all of
> these newsgroups.
The minute you, or anyone else, posts in a rude or insulting manner to
any other person, it BECOMES on-topic, in any and all newsgroups in
which that post appeared, to refute that post.
It may be noted that BAH is a former DEC employee, having worked
extensively on software for the PDP-10, if you haven't followed her
posts enough to realize that.
John Savard
Mike Ross
<snip>
>And the rest of this post is arrogantly on yet another totally
>unrelated topic, but mr arrogant kiddie doesn't care about wasting
>anyone's bandwidth while he puts bodily excrement all over all of
>these newsgroups.
1. It's 'Ms arrogant kiddie'.
2. Don't speak like that to a lady when I'm around. Ever.
Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'
John Francis
Mike Ross <mi...@corestore.org> wrote:
>On Sat, 18 Jul 2009 15:39:36 -0700 (PDT), cjl <clasy...@gmail.com> wrote:
>
><snip>
>
>>And the rest of this post is arrogantly on yet another totally
>>unrelated topic, but mr arrogant kiddie doesn't care about wasting
>>anyone's bandwidth while he puts bodily excrement all over all of
>>these newsgroups.
>
>1. It's 'Ms arrogant kiddie'.
>2. Don't speak like that to a lady when I'm around. Ever.
Do you really think that someone who is so egocentric that he
fails to see the irony in his accusations of arrogant spewage
is going to pay attention to suggestions that he change his ways?