CPS-4K for the LINC-8 and other hardware and related issues
cjl
because it was never written for any hardware except on the LINC-8.
Along the way, it shows partially why no "mainstream" PDP-8 software
ever occurred "naturally" on the LINC-8.
First, what is a LINC-8 besides the obvious?
The LINC-8 is a standard "Straight" -8 that got "modified" [to quote
one of the prints] for the express purpose of making a machine that
would satisfy what people who used the earlier 2K or more LINC
computer would want. Unfortunately, in the process as it was
implemented, key software compatibility with the rest of the "Family
of 8" was lost. [Note: Richard Lary and others demanded of the
hardware group modifications to the RK8E tentative design so that OS/8
could even run on it! Left to their original design, OS/8 would never
run on it, and even P?S/8 would have had more trouble, and it would
have been a poorer performer. Even at that, it was still necessary
for certain applications, to make further changes, thus begetting the
RKS8E. Thus, the original RK8E would be incompatible "for the want of
a nail", and in this case, perhaps 2-3 nails; the LINC-8 is about 4
nails shy of viable, as released by DEC; in the case of one specific
LINC-8, modifications were made to implement a long-way-around way to
be more viable. Third party modifications will be discussed here; the
point is that people were not satisfied with the machine as presented,
but there weren't back then any avenues to get useful modifications to
make the machine more useful beyond the somewhat misguided design that
was driving the show back then.]
Despite the fact that the machine comes standard with a dual LINCtape
drive [read/write/format compatible with all LINC models and PDP-12
later], the standard machine cannot run standard PDP-8 software; it
was not uncommon to find the pathetic situation where frustrated
people used paper-tape software [on a machine with an ASR-33] despite
all of this hardware!
The modifications are multiple: The DMA signals are captively
connected to another CPU [yes, this machine has three module racks!]
which is the [partially-implemented] LINC processor. [Good luck
adding a standard PDP-8 DMA peripheral that way!]. A lot of PDP-8
program transfer/interrupt interfaces are added for all sorts of
purposes, including a PDP--8 peripheral which is the faked front panel
of a real LINC; press any key and you get a PDP-8 interrupt.
When the LINC CPU is started up [through a series of PDP-8 IOT
instructions] the PDP-8 break light comes on so solidly that it is the
most likely front panel light bulb to burn out! The LINC CPU runs
until it cannot, in which case the PDP-8 is able to do normal CPU
cycles. All of the change-of-states of the LINC CPU cause interrupts
[as well as all of the switches on the fake LINC console and a
hardware instruction-speed timer and FETCH and EXEC stops]. The
system anticipates a program named PROGramOFOPeration is loaded into
00000-01777. LINC programming is allowed in 02000-03777, 04000-05777,
06000-07777. If any extended memory should exist, this would keep
going 1K segment at a time. [LINC addressing is always 10-bits, so
memory segments are always 1K. The extended memory is otherwise
handled similar to the PDP-8, thus, as a practical matter, the LINC-8
creates a 3K LINC environment since only the first 1K is reserved.
The LINC supports the notion of a data field in a like matter to the
PDP-8, other than the 1K size, and applies to only certain specific
instructions with an indirect addressing option. Locations 0001-0017
work as auto-index registers thus is a larger set than the PDP-8
equivalent; this addressing is a subset of that which uses the DF to
access memory; some instructions can only address the 1K instruction
space, such as JMP which has no indirect form. [It is a real kludge
to perform the equivalent of a JMP I something PDP-8 instruction:
There is no subroutine call! Instead, all JMP instructions store
another JMP {1 more than this JMP instruction's address] instruction
in location 0000 before JMPing to the desired location. The
"subroutine" "returns" by executing JMP 0000 because that address
inhibits the update of location 0000. Thus, it JMPs to 0000, executes
a JMP back to one more than where it came from; as an artifact,
location 0000 now contains JMP 0001, which is diabolically consistent,
albeit useless.]
The standard 4K LINC-8 actually can run with the standard cycle time
of 1.5 microseconds. When the machine is upgraded to 8K, a standard
PDP-8 "wing" 4K module is added, including all of the relevant
extended memory modules to drive the extended memory buss. However,
during the active lifetime of the LINC-8, the hardware engineering
group demanded the machine be slowed down to 1.6 microseconds because
the machine was unreliable due to the modifications. At that speed,
the machine is again reliable. [Ironically, this is similar to what
happened with most PDP-8/i systems, but for totally different
reasons.]
Due to this memory buss problem that was never solved [poor
implementation of the way the LINC CPU connects to the PDP-8 CPU using
too-slow multiplexor circuits using R-series modules instead of
something fancier [B-series modules?] it was recommended the machine
never be upgraded further to 12K or more. Thus, to my knowledge,
there never was a 12K LINC-8.
To make matters slightly worse, the standard PDP-8 buss was allowed to
be perverted, often leading to a signal-corrupting "forked" buss
configuration: The standard buss slots akin to the PDP-8 are
implemented conventionally. The problem associated with the 11th
cable doesn't happen because all three of the racks are on a massive
plenum door; thus, it is feasible to consider eliminating the 11th
cable as has been done in other machines [and buss level converters:
what is the model numbers for the pos->neg and neg->pos buss
converters? I believe they are DW08A and DW08B, but I don't remember
which is which way converter. If I had to guess, I think the A is
towards the negative buss, not from it.] However, the entire subject
is moot: There is no DMA available because the LINC CPU "stole" it
directly as well as poorly. [Note: There are many empty slots, so in
theory that's not per se a problem; there are far bigger problems to
solve!]
Physically, looking at the front of the machine, there is an openable
laboratory "door" hinged on the right. Mounted on the outside are the
A-D convertor analogue jacks for channels 8-15 [channels 0-7 are
potentiometers mounted on the two plug-ins of the modified Tektronix
oscilloscope in the center of the machine, 4 knobs each], and the SPDT
relay contacts brought out to 5-way binding posts.
On the back-side are some black blocks wired up to support optionally
plugging in optional A-D channels 16-23 and possibly 24-31. All of
the analog stuff is wired back to the main machine with a non-buss
cable, thus not a problem. The six relays associated with the front-
side contacts are mounted on a small subchassis mounted on the
miniature module rack, and similarly cabled independently. [Note: The
LINC CPU has AC <-> relay register instructions.] Thus, there are a
modest number of uncommitted slots, all prewired only for the normal
dual-power.
The machine is delivered with a standard set of six buss cables
plugged into "recommended" slots within the lab panel. The theory
would be to encourage home-brew small interfaces. However, not one of
these machines was ever implemented with a daisy-chain notion; they
literally never told anyone about buss termination! [Resistors might
be added by field circus if needed, but no real proper buss
handling.] I had to talk certain people out of abusing the buss with
dinky minor interfaces better implemented "legally" on external black
block racks, including daisy-chaining back to the data panel
silliness. While it still dead-ends the buss, at least adding on
properly-designed peripherals makes it [barely] viable. Actually, the
scope of a peripheral implemented on the meager few slots would be 6
slots smaller still if the buss were daisy-chained there!
The overall impression I want the reader to take away is that these
machines were of limited production, the official figure is 149 units,
but serial numbers go as high as 153, thus there is a small
discrapancy [it is also known that #1 would never work; it was
hopelessly incompatible and was the in-house prototype and test
machine; they just lived with known limitations unfixable without
making radical changes to the wrap, which were implemented in the
production machines; obviously this was a quick run or two for all
machines sold, etc.] As such, they were never to be considered
"production" machines not subject to some measure of wire-wrapping.
Few and far between are "pristine" machines as owners even drilled
holes in the front panel itself to add minor frills such as analogue
signals of their experimental gear routed to added-on banana jacks.
[Note: A reconstruction project would be akin to some auto body
repair and repainting!] Thus, a lot of these machines would get
"tinkered" with.
The main problem with the machine is that the interface to the
LINCtapes makes use of IOT instructions used for far too many
purposes. For example, one IOT condition [some are the same IOT with
different AC contents] can transfer the PDP-8 AC to the LINC "A"
register [read LINC AC register]; another is the "A" .OR. transfer to
the PDP-8 AC. The LINC "B" register [read MB register] also can be
transfered in either direction with a similar set of IOT transfers.
When the LINC displays on its oscilloscope, the A and B registers
define where the intensified dot [monochrome amber slow long-
persistance phosphor, what some know as "radar" scopes to avoid
flicker]. When the LINC executes the SAM instruction to read an A-D
channel, the same two registers are used in the classic A-D method
associated with such as the AF01 or the A-D of the AX08. And when the
machine restarts, the registers take on their usual purpose. [The SAM
instruction destroys the B register, and the sample value winds up in
the A register, as defined.]
When the LINC is not running, these same registers are appropriated to
also talk to the LINCtape! [Note: The LINC and the PDP-12 have
*REAL* hardware for the tape. There are dedicated instructions to
talk to the real tape hardware. However, on the LINC-8, all of the
tape-class instructions of the LINC stop it running, and control
returns to the PDP-8 including an interrupt. PROGOFOP then simulates
the intended tape operation; then the LINC CPU is restarted past the
trapped two-word simulated Tape-class instruction. Please note that
all of the simulated instructions only support 150 foot LINCtapes with
blocks 000-777; each block is 256 12-bit words long. We are not
obligated to use this, just that the clever illusion of what the
entire machine represents to users of LINC computers is quite complete
and totally limited. Only a scant amount of extensions are added to
the original LINC architecture by the simulator, most notably that the
unimplemented LINC instruction 0500 causes a special trap; PROGOFOP
allows this to be a limited amount of relevant PDP-8 programming to
perform some minor user-defined function to be written by someone
intimately familiar with the workings of PROGOFOP itself; not much can
be done. Most notably, the LINC's interrupt instruction is not
implemented, but many of the original LINCs didn't either, as it
wasn't well defined; each version was quite flakey; thus it really
wasn't missed all that much.]
Not much effort was made to streamline the IOT instructions associated
with the LINCtapes; PROGOFOP is 1K instructions long; it simply didn't
dawn on them this would be a consideration, after all, this isn't a
PDP-8, it's a [to borrow from some more recent usages for other
machines] a "LINC BOX" and that's all that mattered. Well, that may
have been shortsighted and fleetingly true when the machine was
purchasd, the shortcomings of a LINC invariably led to frustration
unless the PDP-8 hardware actually present was used!
Thus, a standard un-modified LINC-8 cannot run any software most
people here on alt.sys.pdp8 have ever heard of. Not OS/8, P?S/8, or
DMS can run here -- for the want of about a half-dozen "nails", i.e.,
the interface is just too complicated, and it didn't have to be that
way, but it hatched in a world of PDP-8 software ignorance. [Note: I
believe there may have eventually been a LINC-8 version of the DECtape
library system, but its system handler is far easier to implement
because of its far more limited scope than all of the other systems.]
A lot of early work on the LINC-8 was spearheaded by Kurt Metzger of
the Cooley Electronics Laboratory, Department of Electrical and
Computer Engineering, University of Michigan. His group was
responsible for an early set of hardware modifications that made it
possible to run various software [incomplete but a good start!]:
A small change to the hardware [literally, cut and add a wire and a
diode!] made the machine able to do a tad [or is it a dca?] more
functionality that allowed the following:
In 4K, P?S/8 could sort-of run; in 8K, OS/8 could sort-of run.
However, all of the tape operations were subject to the following
serious limitations:
1) No ability to retry an error; if there was a data error on the
first attempt, you are SOL. [In P?S/8, you could press continue to
attempt a retry; but no error retry counter possible; just not enough
space in the handler!]
2) Writing was totally "cross your fingers" because there was no room
to calculate a checksum during writing!
3) All tape searches always started forwards! Backwards by default
is far better; smart direction would be far better, thus the worst
choice of all on this.
[Note: P?S/8 on an unmodified LINC-8 with 8K is totally viable using
an alternate handler that fits in two pages of the available nine P?S?
8 design allows. This suggests that OS/8 could work, however it's
totally moot if you cannot raise the size of memory to 12K!]
One particular LINC-8 was heavily modified by DEC to add in a one-
channel DMA multiplexor using the large area of unimplemented modules
in the center rack of modules on the plenum door [the PDP-8 CPU rack;
all of the racks are standard PPD-8 except far larger both in height
and width; some of the slots are being used for other purposes. For
example, some are used for front-panel lamp driver modules; the
standard PDP-8 way of wiring up a front panel was not used
[fortunately!].
On this 8K machine, the peripheral chosen was a 32K total single
DF32. This allowed a baby OS/8 system to boot up, run at reasonable
speed, as long as you carefully chose what few components were loaded
there. Two-page non-system handlers were easily written for the
[otherwise unmodified] LINCtape hardware. [Again, it was not possible
to use 12K; that would have allowed OS/8 to run in 12K or P?S/8 to run
in 8K or 12K.] However, implementing these modifications made it
impossible to add in any of the other Cooley modifications [and follow-
ons].
Additional Cooley modifications allow the ability to read and write
[but not format] DECtapes. This is not meant to be the province of a
handler in the OS/8 sense; however, a P?S/8 non-system handler was
written in 4 pages to allow P?S/8 BLKCPY to transfer data between
DECtapes and LINCtapes. Cooley people weren't really that big on
software for their hardware changes, because all other software work
was geared to developing CPS-4K and CPS-8K. [Note: CPS-8K was demoed
to DEC personnel; its most notable feature was that it implemented the
Fortran modifications later used by OS/8 [not F4, this is the earlier
F II/SABR, which in turn DEC purchased from some others].] [Most
fortunately, CPS-8K was rejected by Richard Lary; part of the rush to
get out the original PS/8 was to convince some "suits" to not go in
that direction! Things would have been quite different if this
decision had been made the other way. I say this from my personal
vantage point of demoing P?S/8 not once, but twice, having DEC reject
it for arguably silly reasons, and then nearly having them sue me when
I sold a limited royalty license to Intersil for the Intercept. The
suit was called off only because certain key people associated with
Richard Lary pointed out that the work was not the property of DEC,
and DEC rejected it, twice.] The physical rack space associated with
these modification uses only a portion of what's there; this invites
additional modifications; DEC's DMA kludge is totally incompatible
with any of this [other than the diode patch].
Please note also that should a DF32 run on a LINC-8 while LINC-
oriented programming is running, the 3-cycle data break locations
[07750-07751] are possibly interacting with LINC operations! Thus, it
was conceptually impossible for such a machine to be running DF32 code
at all if LINC stuff is in use at the time. [Otherwise not a
problem.]
All of the rest of the Cooley contribution consisted of the software
of CPS-4K and CPS-8K. Both of these systems only run on unmodified
LINC-8 tape hardware, and have some ugly kludges, roughly analogous to
the limitations of the R-L monitor when compared to P?S/8 except
actually somewhat worse:
Due to a comedy of errors, CPS-4K [and perhaps CPS-8K?] wrote out well-
checksummed tape blocks on the LINC-8. However, due to a blunder, the
tape format is needlessly incompatible!!!
Just as in the R-L monitor, binary programs running under CPS-4K have
to include their own internal LINCtape subroutines. The source code
had two locations in it: Setting one to a CMA instruction and setting
the other to a NOP yields either normal tape compatibility or CPS-4K
compatibility. [Note: I wrote a CPS-4K to P?S/8 ASCII file conversion
program that ran on P?S/8 back in the days of having to accept the
cross-your-fingers tape checksum because it depended on only the
"diode" modification of the hardware. The program was an ugly kludge:
it patched the P?S/8 system handler to support the "wrong" checksum
convention of the CPS-4K reads [reads were properly checked for,
albeit without any capability to retry] and then restored the handler
to write out normal P?S/8 data, etc. It was deemed only transiently
important to use this utility and thus, while it could be developed
more elegantly [create a CPS-format LINCtape non-system handler for
express use with such as this utility], no one ever requested an
update. [Note: P?S/8 text files in turn can be bi-directionally
converted to/from OS/8 format. OS/8 standard LINCtapes would apply;
using P?S/8 BLKCPY on the modified LINC-8 would in turn allow
conversion to OS/8 non-system DECtape format, which was totally
appreciated by all of those requesting the conversions, etc. as they
left CPS-4K behind!]
CPS-4K requires two non-identical LINCtapes in CPS-4K format: 128
words/block, something like 3600 blocks [I can occasionally get 4000
on selected tapes!], using the incompatible checksum standard here.
The tape intended to be tape 1 checks ["TAPEMIX"] for accidental
attempts to boot to the "wrong" tape. [Note: A common LINCtape drive
modification is to add a small drilled hole on the LINCtape front
plate, and add in a subminiature C-K DPDT switch to implement a
reversal of tape drive select, so it's really easy to get the tapes
"backwards"!]
What is usually in 07600-07777 is amazingly similar to the R-L
monitor: a primitive handler that can read and write the system tape
only; few, if any optional information is available in the system page
because CPS-4K literally doesn't support any. [Note: The tape 1
handling need not be done by the system handler; the code can be
loaded in from tape 0 to access tape 1 when needed; the tapes are not
identical; each reserves different portions of the tape for system-
specifics.]
Additionally, no check is made for the usage of 07750-07756; CPS-4K
is incompatible with machines with 3-cycle data break should said DMA
device be used [such as that modified 8K LINC-8 and some others; see
below.] Since there are no parameter locations reserved, not even a
file list or switch option storage, date word, output file count,
etc., the limited design of the system made this primitive function
all that could be done; again, no hardware modifications required
here.
Any program that could get loaded needed its own tape handler
subroutine within itself, just as in the R-L monitor. Running any
program, be it a system program or a user program is quite an involved
process:
A binary program has to first be "built" into a core-image. [Note:
Building a core-image is not a requirement of either OS/8 or P?S/8;
they are optional. Worse, the image has to build all locations within
the entirety of field 0.] Special note has to be taken of any data
that must be loaded into 07400-07577: A "built" image from user-
binary or a CPS-4K system program, while nominally different,
internally have the same exact problem and ugly kludge implementation
of a "solution":
Options are available, and surprisingly similar to P?S/8, especially
all the stuff that the original R-L monitor never supported. [Note:
CPS-4K and R-L, P?S/8, OS/8 never "crossed paths". Any and all
superficial similarities are merely a coincidence; however, it is
obvious that all people were knowledgable of TOPS-10. In any case,
CPS-4K and CPS-8K require a pair of tapes, different from all of the
rest.] All of these options are loaded into 07600-07777. However,
what is loaded there for the main function is far less than in R-L:
R-L loads in a system loader to load the entirety of any core-image
from 00000-07577; error detection and tape handling are quite
servicable [but HLT on any error without a retry count; but it can
recover pressing continue, if possible].
CPS-4K only loads that portion of the core image that does not occupy
07400-07577! That's because a captive tape routine is loaded into
07400-07577 for the express purpose of reliably loading in the
majority of the intended image data. What happens next depends upon
whether or not there is a need to load over 07400-07577. Assuming the
answer is no, the program is started up at the intended starting
address. The program can access all of the option mechanisms located
within 07600-07777. A bootstrap to reload CPS-4K is available by
branching to 07600, just as in the R-L monitor.
Now to the other branch in the road: If a portion of the program has
to load into 07400-07577, the rest of what is in 07600 is a one-off
routine for the express purpose of loading in the rest of the core
image, which was pre-transferred to a dedicated scratch block for this
purpose, so that this routine could have implicit information. Due to
lack of space, this loading is accomplished on a "cross your fingers"
basis literally without any checksum protection or retry; certain tape
errors could cause it to hang!
Thus, the reliability and complications factor are inferior to the R-L
monitor, leaving you with an analogous environment, albeit less
reliably loaded depending on the need for the loading of 07400-07577.
Passed options are present, perhaps including file handles, but no
ability to access them unless you provide your own tape handler as
part of the program itself.
Thus, this system rates even worse than R-L in terms of device-
dependence!
Cooley even created a semi-commercial hardware project: A tape
controller for the PDP-8/l etc. positive buss, complete with proper
buss termination/daisy-chain. It used the Computer Operations
LINCtape drives and supported essentially just enough of the LINC-8
IOT interface to the "A" and "B" registers, but only for the tape
functions, i.e., enough to run CPS-4K or CPS-8K. Most notably, there
is still not enough hardware to run 4K P?S/8 or 8K OS/8 reliably; all
is compatible, including only the "diode" modification equivalent.
[This is clearly an example of "not invented here" syndrome. Why
reimplement so much hardware without asking what more would it take to
run software not developed at Cooley Labs!] [Note: P?S/8 can run on
an 8K machine with this hardware, and an OS/8 two-page non-system
handler can be written for it. I imagine that a 12K system could be
written for OS/8 via a two-page system handler; however, this is aimed
at machines where it was still difficult to get past 8K, just not as
difficult as in a LINC-8!]
The final resolve of the LINC-8 hardware debacle came from a project
developed by me and David Soerghel of Syracuse University, and
implemented on at least two LINC-8s, one with 8K. The net result is
capable of running 4K P?S/8 and 8K OS/8 if the memory is available.
Clearly, this project wa far more worthwhile that all of the half-
heared efforts it is a superset of. [In the main, my criticism is
directed at DEC for their short-sighted notion of adding a DF32
instead of making more useful changes; we thank the Cooley people for
implementing the DECtape modifications as a separate issue, and of
course the "diode" change!]
Using available slots beyond the Cooley hardware modifications, small
changes were made to the existing LINCtape interface to enable
"smarter" hardware, sufficiently that successful handlers could be
written without kludges.
I suggested a series of "wish-list" modificatiopns to Dave, and he
implemented a sufficient subset that was adequate to the mission. [In
some cases, I was surprised at the relative difficulty and relative
ease of some of them differing from my mental notion of what would be
the effort to get there!]
Once done, the final handlers have all of the following desirable
features:
1) Total LINC-8 compatibility; no known existing code is compromised
in any way; most notably SUDSY [LINC-8's famous Super Ultimate
Diagnostic SYstem] runs just fine [as long as the REST of the hardware
works! SUDSY is a torture test and often finds marginal problems
outside of the scope of everything discussed here. Additionally, it
makes very wierd groaning noises in the LINC-8 built-in speaker when
it is running!] [Note: the various "LAP" LINC systems that run on the
LINC-8 make the same sort of noises as LAP6-DIAL does on a PDP-12.]
2) Total compatibility with the built-in LINC-8 LOAD key hardware
bootstrap; the only PDP-8 model with this standard. [Note: Some
systems require manual intervention after a partial load, most notably
SUDSY!]
3) Excellent tape handling in terms of reads and writes, checksum
testing and a settable retry count. [Standard is to use the NL7775
instruction that works on the PPD-8 to set the error retry count to
-3, common in many handlers; a one-word patch could make it longer,
albeit not recommended.]
4) Sufficient space to implement the dead-reckoning trick as in P?S/8
for DECtape. Tapes occasionally start search forwards, but only when
appropriate. More importantly, the default is backwards! [Same in OS/
8 also!]
5) One free word [for the future].
6) Excellent implementation of the slurp loader and associated /I
handler reload code without writing. [Note: LINC-8 drives do not
have write-protect!]
In short, after this last set of modifications, the LINC-8 now
qualifies as a "full" member of the "Family of 8" and can run
virtually all relevant software, just like a "Straight" -8 suitably
configured. [Note: All LINC-8's should be able to use the DW8E-N.
Assuming an RX8E or DSD-210 Omnibus equivalent is inserted, RX01/02/03
support should be possible. Again, remember the LINC-8 cannot have
12K, so that RX01 OS/8 cannot be supported, just non-system handlers.
However, P?S/8 can run on RX01 with 8K. In 4K, P?S/8 could only
support RX drives via non-system handlers only available to select
system utilities, such as BLKCPY.]
Final note: The isolation of most of the LINC-8s from the rest of the
PDP-8 world can be partially blamed on the inability to run PDP-8
software; the prevailing LINC-oriented software either totally ignored
the PDP-8, or at best, treated it as a "second-class citizen". In
what is arguably the best of the "LAP" series of systems, the best
that could be offered was the ability to assemble source code written
in the primitive screen format associated with the primitive LINC code
assemblers of these systems, no two of which are exactly alike, but
all are quite inferior to PAL III etc. Except that this is a poor
implementation of a PDP-8 code assembler.
More importantly, the binary created by such as assembly, can only be
loaded with fatal restrictions:
1) Can only load into selective locations.
2) Only loads and causes the LINC to be no longer runnable. There is
no concept of mixed-mode programming as in the PDP-12 sense.
3) Uses a one-off "8B" loader that is totally incompatible with all
of the LINC utilities of the rest of the system. Clearly a poorly
implemented add-on, and that's in the best of these systems! Most
just truly ignore the -8!
Once I got P?S/8 to run on the LINC-8, it became feasible to create
BATCH files to automate user programs. Trivially, the entire contents
of memory could be loaded from P?S/8:
0000-1777 - PROGOFOP; possibly customized.
2000-3777 - Usual standard LINC program
4000-5777 - Usual standard LINC program data 1K "field"
6000-7577 - Available for whatever PDP-8 programming was needed as a
"subroutine" callable from the LINC CPU via the trapped 0500
instruction; more than enough.
7600-7777 - P?S/8 system handler
The entire application could access P?S/8 files via the usual method,
and was debuggable via P?S/8 ODT etc.
Some early adopters complained that it would be "too hard" to learn
another operating system. I totally debunked this:
P?S/8 supports BATCH with the ability to retain context across a
system reboot. The BATCH literally contines automatically unless you
press control-B [or control-C, but not in this case].
I just created a short BATCH file that looped infinitely by invoking
BATCH passing to it the same file repeatedly. If you had no knowledge
of P?S/8, the entire "documentation" to run the application was:]
1) Locate the P?S/8 tape instead of the more habitual "LAP" system
tape.
2) Mount the tape on drive 0. Same as if the "LAP" system were to be
used.
3) Press the hardware LOAD key. Also same as "LAP" systems.
The program started up at the standard PROGOFOP location, and the LINC
program automatically was run [a standard PROGOFOP feature]. From
their [quite ignorant, and understandably hard-headed!] point of view,
there was literally nothing to learn!
As more of the non-hard-liners [younger research people] came along],
I gave them the basics of how to use stuff we take for granted on the
PDP-8 [P?S/8 FOCAL for example, and of course P?S PAL; not all of
their needs were LINC-oriented at all; not they had the relative
luxury of some contact with what most of us take for granted is normal
PDP-8 stuff.] For the ones with the 8K machine, OS/8 played a role as
well.
However, it can not be understated that the LINC-8 is the "forgotten"
side of the PDP-8 world!
cjl [PDP-8 family "resurrections" 'R Us]