Subject: PDP-8 spare parts/systems.

From: [email-masked]
Date: 20 Jan 1995 06:34:35 GMT

I was in the last class year at the University of Michigan
Engin School to have logic lab/assembly programming class
on an old LINC/8 machine.  They switched to Z80s the next
semester.

I also did work study programming on various PDP-8s at the
Cooley Laboratory on the U of M's North Campus.  I recall
now that they had lots of those pesky plug-in circuit cards,
just enough to keep their systems in repair.  You might look
up Ted Birdsall or Kurt Metzger at the U of M to see whatever
became of their PDP-8 systems.  They might be long surplused,
but it's worth a try.

-Alexander Stoll, U of M class of 1980.

---

From: "J Russ" <[email-masked]>
Date: Mon, 23 Jan 1995 19:45:43 -0500

>became of their PDP-8 systems.  They might be long surplused,

I bought all the PDP8/LINC8 stuff at the Cooley Laboratory back in 1987.  It
was an interesting collection of stuff.  One of the machines was an old LINC8
down in the basement buried away in a back room.  Near the machine was a copy
of a radical newspaper from the late 1960's so the machine may have been
there for a long time.  The LINC8 was missing the core memory and various odds
& ends but eventually I was able to rebuild the machine and run the SUDSY
diagnostics and demo programs.  Another interesting artifact was a box of smoke
damaged A series modules that were out of a LINC8 in Florida that had caught on
fire.  I also got a couple of the cloned DECTAPE drives (I can't remember the
name of the manufacturer) but haven't tried firing them up yet.

U of M and Ann Arbor are interesting places to visit.  If you're ever up there
stop in at the university surplus building and check out all of the interesting
junk they have for sale.  When I was there in November I picked up a couple of
junked Apollo workstations for use as parts in my Apollo workstation collection.
I didn't see any PDP8 stuff but it may pass through occassionly.  Before you
head out of town be sure to check out the new and used book stores in downtown
Ann Arbor. 
					Jeff Russ
					Bloomington, IN

---

From: [email-masked] (Charles Lasner)
Date: 28 Jan 1995 19:15:59 GMT

In article <[email-masked]>,

>name of the manufacturer) but haven't tried firing them up yet.

The Cooley Labs LINC-8 collection is the original source of quite a few 
LINC8-specific things.

The unmodified 4-K LINC-8 cannot support running P?S/8 due to the 
complexity of the LINCtape control.  (Similarly, you cannot run OS/8 on 
an unmodified 8K LINC-8.)

By making a few hardware changes, it's possible to run a kludgy P?S/8 
and/or (if you have 8K!) OS/8 system with some limitations:

1)	Inadequate error recovery (sorely needed on a tape system)

2)	Always searches forwards first, even though statistically, 99.99% 
of the time backwards search is best.  (Quite pessimized :-).)

(Note: there is the possibility of a P?S/8 handler for an 8K 
*un-modified* machine and an OS/8 system handler for a 12K unmodified 
machine.  Also, one LINC-8 was definitely used with a DF32 using the 
standard system handler for the DF32 and two-page non-system handlers for 
the LINCtapes, etc.  An item being sought towards this and related ends 
is the modifications to the LINC-8 so that you could have DMA devices 
past 4K.  The stock LINC-8 doesn't support this!  Yet, apparently DEC 
came up with ECO's to the machine to support it for at least this very 
site.  (LINCtape isn't DMA, and the buss is taken over for DMA purposes 
by the LINC CPU, etc. so there isn't available a DMA channel for extended 
memory, etc.)  Anyone with any info about these hardware mod's?  I 
suspect the machine was installed at WVU at one point, etc.)

Several individuals at Syracuse University and I participated in an 
"upgrade" to the Cooley-defined changes.  As a requirement of our spec, 
we incorporate other changes from Cooley that allow DECtape to be 
read/written on the LINC-8 (as well as NOVA LINCtapes.  BTW, NOVA 
LINCtapes also use the strange drives Jeff mentioned; they were made by 
Computer Operations in Beltsville, MD.)

The DECtape changes are useful, but are somewhat unreliable for the 
purpose.  We expanded on both sets of changes to add additional features:

i)	Faster access to the registers that mattered, such as a direct 
skip-on-flag-up set instead of the longer ICON interface that multiplexes 
several registers with sense bits, etc.

ii)	One instruction to force tape searching mode directly.

iii)	Coupled with ii, a means of forcing an initial tape search 
direction "guess" where it self-clears when a transfer is initiated thus 
all subsequent transfers are forwards, but the search ls (likely) backwards.

The DECtape-oriented changes involve adding a device selector to get 
three IOT's.  We added 4 extra instructions using full decoding to get 
all of the above improvements.  Thus, the net result is compatible with 
the un-modified machine, the slightly modified machine with or without 
the DECtape-oriented enhancements, and of course itself.

Using all of the improvements, the following have been successfully written:

1)	A 4K P?S/8 system handler which I use on my 4K LINC-8.  It can 
handle up to 8 drives (if you implement them!  I have heard of machines 
with drives 4,5 added, but never the other 4 drives!), and can search 
with an intelligent guess ala the P?S/8 DECtape TC01/08 system handler.  
Additionally, no compromise is needed regarding DMA devices such as 
DF32.  (Note: when the minimal change version was used, we compromised 
the handler such that if the DF32 were also present, it would destroy the 
tape handler!  Both P?S/8 and OS/8 share a common rule that had been 
broken in this case: Always use locations 07750-07755 as temporaries only 
since these could be DMA locations for TC01/08 or TC58 or DF32/RF08.  
That older handler stuck code and/or constants into this area and thus 
was in jeopardy, etc.  This newer handler that depends on all of the 
hardware mods now obeys this rule, etc.)

2)	A similarly equipped OS/8 handler for 8K machines.

The mods have been applied to both my 4K LINC-8 and also an 8K LINC-8 now 
residing in my basement.

3)	one-page non-system handlers without compromise are now possible 
for both systems.  (Note: even without hardware mods, it's possible to 
produce a slightly compromised one-page handler, and no problem in 
two-pages.)

4)	Much more reliable DECtape <-> LINCtape transfers.  I wrote a 
block-oriented utility (a fore-runner of the more generic P?S/8 utility 
BLKCPY) to move DECtape blocks around on the modified LINC-8.  The 
following commands are typical of usage: (Note: the "*" is the prompt char!)

.R BLKCPY
*DTA1:0-2701>LTA0:0		{transfer an entire DECtape to a LINCtape}
*LTA0:0-2701<DTA1:0		{same}
*LTA0:0<DTA1:0=2702		{same}
*LTA0:0=2702!DTA1:0		{same blocks, but compare only}

The handler convention is a three-leter named device followed by a 
mandatory digit 0-7 used as a unit number.  Handlers handle unit numbers 
in a device-dependent way.  (Such as complaining of illegal values or 
partially ignoring unit numbers on a bit basis.  For example, on a 
two-drive LINC-8, the high-order bits of the unit number are ignored, 
essentially meaning you merely have an "odd" and an "even" unit, simply 
expressed as 1 and 0 respectively.)

Commands with "!" as an interdevice separator mean to perform a read-only 
block-by-block compare.  Using "<" and ">" imply a read then write 
operation to perform a copy.  The direction is "pointed" to by the arrow 
key used.  Either an input or output range must be specified, or 
alternatively an explicit block count using "=".  A command line option 
exists to specify whether to verify the write with a readback-compare 
after the write, etc.

The LINC-8 version of this program can run on the 4K LINC-8.  The 
LINCtape handlers can be one page if the hardware mods are used, else are 
two pages.  The DECtape handler is 6 pages including lookup tables for 
the data conversion.  (Note: DECtape bit directions are "sideways" 
compared to LINCtape conventions!  Invariably, this means that some sort 
of lookup table is required.)  All P?S/8 non-system handlers are page and 
field relocatable, and can be up to an entire field long unlke the OS/8 
two-page max restriction, etc.  As a practical consideration, since the 
hardware mods are required for the DECtape conversion, the modified 
LINC-8 LINCtape handler appies as a likely system device to run the 
program from, etc.  (But it could also be something else such as a DF32, 
RF08, or an IPB such as on my home machine.  In that case, the "boot 
device" is actually a disk or real TC01/08 DECtape on the "other" side of 
the IPB on my -8/e, etc.  This allows both drives of the LINC-8 to be 
available to the program without changing tapes, etc.)

Cooley Labs is also responsible for CPS and CPS-4K.  These are systems 
that run on LINCtape as usually found on the LINC-8.  However, the LINC-8 
tape hardware is actually a PDP-8 peripheral!  (PROGOFOP is a trap 
simulator that helps to "fool" LINC programs into believing they are 
running on complete LINC hardware, which is actually partially simulated, 
especially the tape portion, etc.)

The actual mechanism for the tape is to appropriate the LINC CPU 
registers as tape registers during the time the LINC CPU is shut down 
(during normal PDP-8 operations, which in LINC mode are only true during 
interrupts, such as interrupts generated from trapping LINC instructions, 
etc.).  Kurt Metzger and company defined an interface for the Posibus (on 
an -8/l) that essentially is the LINC-8 register sequence for tape only.  
Thus, LINc-8 software for the PDP-8 such as the Library System, CPS 
(-4K), P?S/8 for LINC-8, OS/8 for LINC-8, etc. can run on LINCtapes on 
PDP-8's.  (Of course you cannot run systems for LINC such as LAP6, since 
these run primarily in LINC mode, although you can write file conversion 
utilities for these machines, etc.)

These "transplanted" drives were actually Computer Operations tape drives 
with a Cooley-designed interface.  Undoubtedly, this is what Jeff has 
recovered, etc.

Note to Jeff:  I have sent you e-mail months ago but you never responded 
regarding archive site "synchronization" etc.  If you are reading this, 
please e-mail me at [email-masked] etc.

Further note to Jeff:  The smoked LINC-8 in Florida: was it at the 
Miami-based Mt Sinai Medical Center?  (They also had a research division, 
but I don't remember their title, etc.)  I have the "other" machine from 
there, etc.  Please contact me about that as well, etc.

Sorry to use the a.s.p group for private correspondance, but there 
doesn't seem any other way (why?) etc.

cjl