Subject: Hardware needs a home!
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Date: Mon, 6 Jul 92 13:35:57 CDT

Date: Mon, 6 Jul 92 13:35:57 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: Hardware needs a home!

I just visited with Keith Miller of the University of Iowa Psychology
Department Shops.  He took me on a tour of the PDP-8 equipment that
the Psych department still has.  Among the machines he showed me were:

-- A PDP-8/L, sitting idle but running.  It has been in a tight loop
   waiting for console input for a few years, but the run light is still
   on.

-- A PDP-8, purchased by the Psych department in 1966, complete with
   documentation, paper tape software, and analog to digital converter.
   This is a real museum piece, and it's been gathering dust for years.
   The CPU fills most of one relay rack, and the second rack has paper
   tape hardware and the analog to digital converter.

-- A PDP-8/I, powered down.

These machines need homes, and particularly for the 1966 model, they'd like
to see the machines fall into loving hands.  My personal feeling is that
the old PDP-8 is the kind of thing that museums really ought to be seeking.

They also have an Interdata Model 4 computer (some kind of 16 bit machine,
with a good bit of documentation).

				Doug Jones
				[email-masked]

Date: Mon, 6 Jul 92 17:42:29 CDT
From: [email-masked] (Ed McGuire)
To: [email-masked]
Cc: [email-masked]
Subject: Hardware needs a home!

Date: Mon, 6 Jul 92 17:42:29 CDT
From: [email-masked] (Ed McGuire)
To: [email-masked]
Cc: [email-masked]
In-Reply-To: Douglas W. Jones's message of Mon, 6 Jul 92 13:35:57 CDT <[email-masked]>
Subject: Hardware needs a home!

Dave Lacey, president of ISCA, is a PDP collector.  I've forwarded
your note to him.  It would be nice to keep those systems in the
family, so to speak.

peace. -- Ed

Date: Tue, 7 Jul 92 14:47:09 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: ILLIAC III was a PDP-8?

Date: Tue, 7 Jul 92 14:47:09 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: ILLIAC III was a PDP-8?

When I came to the University of Illinois in 1973, there was a large room
in the center of DCL devoted to ILLIAC III, an array processor being built
by McCormack with AEC (Atomic Energy Commission) funding, with the target
use being processing of bubble chamber photographs.

There was a large area devoted to graphics input output workstations,
flying spot scanners, and similar devices.  They had a high speed
electrostatic printer-plotter, and a number of other interesting
peripherals.  When I came to Illinois in 1973, many of the peripherals
were in running condition, but work on the CPU had ground to a halt.

As I understood the problem, numerous deadlines had been missed because
of redesign work to incorporate newer technology than the originally
intended technology, and a fire in the CPU had set things back even
farther.

Anyway, testing of peripherals and subassemblies had to be done somehow,
so there was a PDP-8 in the machine room.  The PDP-8 was pretty well
stuffed with memory (I think it might have had all 32K 12 bit words), and
I think it had an RF08 fixed head disk for another 256K.

Oh yes, I seem to remember that it also had the high speed paper tape
reader from ILLIAC II.  This was a great thing, a home made photoelectric
affair.  It couldn't stop between characters, and it tended to spit tape
out on the floor, but it was fast.

Counting all the ILLIAC III peripherals that it controlled, this may have
been one of the largest PDP-8 configurations ever.

I got to play with it a bit when I took R. Michalski's database course,
the machine was otherwise idle, and he decided to let students try to do
database things on it.

Does anyone out there have better knowledge of the last days of ILLIAC III
and this PDP-8?

                                Doug Jones
                                [email-masked]

Date: Wed, 8 Jul 92 16:58:08 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: Documentation needed

Date: Wed, 8 Jul 92 16:58:08 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: Documentation needed

I just posted the following to various newsgroups, but I thought I'd ask
here as well, although I doubt most of the people on this list want to
give up their copies of anything.  I should note that my Introduction to
Programming is in bad enough shape that I'm considering sacrificing my copy
by cutting off the spine so I can photocopy it onto new paper.  If I do
that, I could make extra copies.  Has anyone done this to other hard to
get PDP-8 documentation?  If so, I'll buy a copy.

---- original posting ----

I'm in the process of trying to restore a pair of old Omnibus PDP-8 machines,
and I need documentation.  I have contemporaneous copies of the following:

   Digital Logic Handbook
   Introduction to Programming
   PDP-8/E -8/F -8/M Processor Maintenance Manual, Volume I
   RX01 Maintenance Manual

If anyone has other PDP-8 documentation for omnibus machines, I'd like to
get my hands on it.  I'm particularly intereste in getting:

   Digital Small Computer Handbook
   PDP-8/E Processor Maintenance Manual, Volume II and III
   Engineering Drawings
   Digital Programming Languages (the sequel to the Intro to Programming)

I got my copy of Volume I of the Maintenance Manual from someone who was about
to send it to the dump, but I'm willing to pay freight and a bit more if you
need some inducement to search your bookshelves for such stuff.

					Doug Jones
					816 Park Road
					Iowa City, IA  52246

					[email-masked]

Date: Wed, 8 Jul 92 17:46:46 -0500
From: "Lawrence T. LeMay" <[email-masked]>
To: [email-masked]
Subject: Back door of 1/2 hight PDP8/E cabinet
Cc: [email-masked]

Date: Wed, 8 Jul 92 17:46:46 -0500
From: "Lawrence T. LeMay" <[email-masked]>
To: [email-masked]
Subject: Back door of 1/2 hight PDP8/E cabinet
Cc: [email-masked]

Well, i have this nice pdp8/e cabinet. No pdp8, no power supply, just a
large cabinet thats taller than I am....

However, i also have the back-door to a pdp8/e cabinet thats 1/2 as tall
as this one (it has a sticker inside which identifies it as comming from 
a pdp8/E)... SO, does anyone want this back-door? Its here in Minneapolis,
i guess we can figure out some way of shipping it....

-Larry (What shall i do with an empty cabinet and spare back door...) LeMay
[email-masked]

Date: Thu, 9 Jul 92 15:45:45 +0200
From: [email-masked] (Ignatios Souvatzis)
To: [email-masked], [email-masked]
Subject: looking for RX02 cabling information
Reply-To: [email-masked]

Date: Thu, 9 Jul 92 15:45:45 +0200
From: [email-masked] (Ignatios Souvatzis)
To: [email-masked], [email-masked]
Subject: looking for RX02 cabling information
Reply-To: [email-masked]
X-Mailer: GNU Emacs 18.57.11
X-Face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a<zYep+xKF
 #bT*3R^y:c[\`nu#xM!i{rBU4aDa5rjv{gYpG}Ia/%nEQ)#k`%i+5=<BUNMyI@ZJ99=(t<D`cNq8{7
 _2c{-MG7.mD[47~'BmMl-duJ3?oiTogca-c:dNgOZUEM@-$'5ZwAXe
X-Planation: X-Face can be viewed with "faces". Contact [email-masked]
        for details or ftp iuvax.cs.indiana.edu, directory pub/faces

Hi,

I saved a box with 2 8" floppy disk drives from the garbage. They
were (once) connected to a VAX 11/780, and (as far as I remember) the
VAX thought they were a RX02. 

On the back side is a connector for the power cord and a 50 pin
connector for the computer/controler.

1) Can anybody imagine if this one should have some standard pinout,
   e.g. 50 pin "Shugart bus"?

2) Does anybody have RX02 documentation to err... give away, photo
   copy, lend to me ...?

3) Does anybody have a controler for this beast and an Omnibus PDP8?

   Paper mail: Ignatios Souvatzis, Radioastronomisches Institut der 
            Universitaet Bonn, Auf dem Huegel 71, D-5300 Bonn 1, FRG
Internet:   [email-masked]

Date: Sat, 11 Jul 92 22:53:59 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Cc: [email-masked]

Date: Sat, 11 Jul 92 22:53:59 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Cc: [email-masked]

Date:   7/11/92 15:00 EDT
From:   Charles Lasner ([email-masked])
To:     [email-masked]
Subj:   Announcement of new Kermit-12 utilities

    Currently available at watsun.cc.columbia.edu via ftp in
/pub/ftp/kermit/d/k12*.* are two new files: k12enc.pal and k12dec.pal.
The new files have internal dates of 8-Jul-92.  Several other
documentation files with similar dates are also available.  Anyone who
last retrieved Kermit-12 files prior to Feb, 1992 should retrieve much
of the current collection which has changed since then.

    These are the newly updated ENCODE and DECODE programs for moving
around OS/8 binary files in a reliable manner.  There is several new
feature added to both:  the ability to deal with "raw" image data sent
as a single file, and also sent split into two files.  Consider the
following usage:

.R ENCODE
*BIGGY.EN<RXA1:/I=756

When the input specification is a device only AND the /I switch is given
AND a non-zero equals parameter is given (and neither /1 nor /2 are
given; see below), then the ENCODEd file is created containing the
entire logical device for the length specified in the equals parameter.
In the example, the length of an RX01 in OS/8 terms is used.

    Note that the device need not be an OS/8 "legal" structure, and
there is no individual input file significence either.  The user must
set the length to whatever is appropriate.  Too large a number could
result in program abort due to handler-reported input error.  The
minimum length is 1; a zero-value is the same as leaving out the
parameter.  (This is a restriction of OS/8 itself.)  Input data always
starts at OS/8 logical record 0000.

    Note that the device must be definable within the scope of the
selected OS/8 handler itself, since it is used for all input I/O using
"raw" sequential calls.

    For example, an OS/8 bootable RX01 standard-format diskette would be
acceptable for encoding here, while a WPS document disk would not be.
The reason is that the handler does not access track zero (not a WPS
issue) and also does all reads in 12-bit mode, while WPS documents are
written in 8-bit mode, portions of which are lost when using a 12-bit
mode handler.

    By using another (user-written) handler that supplies 8-bit
transfers, the WPS document disk CAN be successfully transferred to
ENCODE format intact.  (Note: there are no current 8-bit mode handlers
for RX02 and RX50, just RX01; this is a separate problem being addressed
elsewhere.)

    Output DECODing is accomplished in a symmetrical manner:

.R DECODE
*RXA1:<BIGGY.EN/I=756

When used in this manner, the equals parameter need not be exact, but
must be at least as large as the parameter used when encoding.  A
smaller value can be used to limit the transfer deliberately where
appropriate.  For example, using =7 will only transfer the first seven
records of the ENCODEd file onto the target device.  If the ENCODEd file
contains a valid OS/8 device in complete image form, this amount will
suffice to transfer only the directory to the target device.  This
effectively aborts the transfer, so the user can look at the directory
with DIR, etc., to determine suitability of the larger transfer, etc.

    Warning:

    This usage writes over the output device starting at logical record
0000 (or higher; see below).  The (possibly present) previous OS/8
structure will be destroyed.  This is the intended function of this
usage as the new data is meant to be moved to the beginning of an empty
device.

    Image splitting:

    As pointed out by a user, if the only device available on a PDP-8
system is being used to acquire an image copy of the media, then this is
likely to be impossible to carry out.  This is the case in some systems
whose only disk device is a pair of RX01, or RX02, or RX50 in the case
of the DECmates.

    The reason is that the image of a device is likely to be larger (as
an ENCODEd file) than the OS/8 capacity of the device itself!  Since the
repeat-compression of the encoding process isn't a reliable phenomena
(it's data-dependent), it is likely that some disk-image files will be
too large.  Of course, if less than an entire device need be
transferred, the equals parameter could be set to a shorter value where
appropriate, but this prevents a complete transfer.  (Alternatively, the
data should be placed on a disk where the unused space has a repetitive
pattern, such as that left after a format operation, or all zeroes, etc.
This would allow the repeat-compression of the ENCODE process to reduce
these areas to insignificent quantities in the ENCODEd file.)  Of
course, this still doesn't address the problem of sending an entire
device, such as a fully-loaded diskette.

    To solve this problem, an additional option has been implemented to
split the data into two nearly equal parts before encoding.  Assuming
the worst case of no repeat compression optimization, the ENCODEd image
file representing half of the target disk data should fit on a bootable
OS/8 disk.  This disk would only contain the system head, the DECODE.SV
program, and the ENCODEd data file.  From this minimal system, the data
can be written to another drive.  Then the entire process can be
repeated using a similar disk containing instead the second-half ENCODEd
file.  (There is no hope for a machine with only one disk!)

    Assuming our original RX01 example again:

.R ENCODE
*BIGGY1.EN<RXA1:/I/1=756
*BIGGY2.EN<RXA1:/I/2=756

This creates two image encoding files, each containing half of the
device image.  (In the case of an odd size, the second half is one
longer than the first half.)  Note that the size must be stated exactly
so that the proper split occurs.

.R DECODE
*RXA1:<BIGGY1.EN/I/1=756
*RXA1:<BIGGY2.EN/I/2=756

This creates the disk image from the ENCODEd files.  Note that the size
must be stated exactly as it was when the original files were created so
that both the length and position of the files (especially the
second-half file) are correct.

    To aid in restoration of the disk, the (FILE statement within the
ENCODEd file indicates that it is a block-image file, not an individual
file with a file name.  Additionally, the =xxxx value used to create the
file is given to guide the decoding process.  If the ENCODEd files are
split files, then it is further indicated that the file is a first-half
or second-half of an image file as necessary.

    As of this version (2.1), the ENCODE program also inserts a (REMARK
indicating the program version and other useful information.

    Overall program operation for all other operations remains
unchanged.  As before, program documentation is contained in the source
files.  Except for the new image transfer features, the programs are
totally compatible with their previous respective versions.  (Note, the
latest and previous versions are NOT compatible with the original
"ancient" version which was "provisionally" released while the encoding
format was still being formulated!  Thus, there is one incompatible
original version, and all following versions are compatible except for
added features.)

cjl

Date:    Mon, 13 Jul 92 09:05 PDT
To: [email-masked]
From: BUDDY                                <[email-masked]>
Subject: mysterious code:anybody recognize it as PDP assembly??

Date:    Mon, 13 Jul 92 09:05 PDT
To: [email-masked]
From: BUDDY                                <[email-masked]>
Subject: mysterious code:anybody recognize it as PDP assembly??

Dear pdp8-lovers,

  I have this piece of code from a fortran program which has put the brakes
on one of our projects here at the Center for the Sudy of Evaluation (UCLA).
Here is the story (a good one):  Last year a Russian Mathematican taught a
course to some graduate students here at the Graduate School od Education
on advanced Mathematical modeling and computer methodologies.  A couple of
us got really excited with some of the ideas which came out of this course
and consequently got invloved with this immigrant scientist.  When he came
to this country he brought a printout of the source code to a fortran
program which computes all important parameters and dynamic operators of
interactive processes (in units of information). Well only one of his
notebooks got by immigrantion officers (read KGB), so some documentation
was lost.  To compound this, aparently all of his research colleagues, like
many scientists in Russia now, are lving out of suitcases and are unreachable.
Although this Professor was the coordinating director in charge of this
project and the development of this program, he is not strictly speaking
a programmer and thus uncertain on some of the finer points of the program.
He seems relatively sure that the computer on which this ran was in most
respects a clone of a PDP-?.
   This project is not a breach of national security or a boon for old
cold warriors;  It is however important to us.  If anybody can help with
even just a lead worth following we would be in your debt.
   The following is the mystery code:

         .ROOT GOLKKK-L*(KOK, PRIV1,PRIV2,GRAD)
KOK:     .FCTR KOKILK-INV-LAMB-PEREK-FUN1-L
PRIV1:   .FCTR PRIVX1-MULT-PEREK-L
PRIVS:   .FCTR PRIVX2-ALNFAS-INV-ZEROIN-FUN1-L
GRAD:    .FCTR GRADTK-FUN1-DLINN-DLN1-L
INV:     .FCTR INVAR-KRTR-F-TLXV-MULT-FUNF-DLINN-DLN1
L:       .FCTR LB:(1,1)FOROTS/LB
         .END

All except L, LB, FOROTS are either functions or subroutines.  The words
on the left, ie, KOK:, PRIV1:, etc, seem to be defining sequences of
subroutine and function calls-- those which follow after the word .FCTR on
the same line.  Our best guess is that this is assembler code. But what does
it mean?    Does anyone recognize this as being something??  How about
being definitely NOT something??   Thanks for being there!

                                          Buddy
                                          Network manager
                                          Center for the Study of Evaluation
                                          UCLA

Date: Mon, 13 Jul 92 15:54:01 EDT
From: History shows that the Red Sox always win the World Series in the year after a Russian revolution.  13-Jul-1992 1554 <[email-masked]>
To: [email-masked]
Apparently-To: [email-masked]
Subject: RE: mysterious code:anybody recognize it as PDP assembly??

Date: Mon, 13 Jul 92 15:54:01 EDT
From: History shows that the Red Sox always win the World Series in the year after a Russian revolution.  13-Jul-1992 1554 <[email-masked]>
To: [email-masked]
Apparently-To: [email-masked]
Subject: RE: mysterious code:anybody recognize it as PDP assembly??

It looks like instructions to an overlaying linker.

The package was probably WAY too big for core, and so they used overlays to
specify what collections of routines were "related", and therefore should be on 
a "leaf" of the overlay structure.

This kind of file is very commonly found with Fortran applications running on
small-memory systems.  OS/8 had it, various PDP-11 operating systems had them,
so did the DECsystem-10/20 linker.

Overlaid program linking was done by specifying a "tree" consisting of a root
node (containing the main program and commonly-used subroutines) and a
collection of "leaf" or "branch" nodes, each containing several subroutines.

The subroutines of one leaf would be overlayed with the subroutines of another 
as execution progressed through the program.

.ROOT specifies the root node of the "tree"

.FCTR lines specify the leaves  Each is named with the name at the left-hand
side.

.END indicates the end of the tree specification.

The LB:[1,1] is standard OS/8ish for the library area, I think.

FOROTS is the Fortran Object-Time system (a collection of subroutines to
interface program subroutine calls to the OS and the math libraries).

I've never used overlays on OS/8 Fortran; this is based on my memory of PDP-10
Fortran, but most disk-based DEC FORTRANs of that era were similar in design,
though some of the specifics may be different.

Hope this helps,

John Francini
Digital Equipment Corporation

Date: Mon, 13 Jul 92 21:56:59 MET DST
From: Johnny Billquist <[email-masked]>
Reply-To: [email-masked]
To: BUDDY <[email-masked]>
Cc: [email-masked]
Subject: Re: mysterious code:anybody recognize it as PDP assembly??

Date: Mon, 13 Jul 92 21:56:59 MET DST
From: Johnny Billquist <[email-masked]>
Reply-To: [email-masked]
To: BUDDY <[email-masked]>
Cc: [email-masked]
Subject: Re: mysterious code:anybody recognize it as PDP assembly??
In-Reply-To: Your message of Mon, 13 Jul 92 09:05 PDT

>Dear pdp8-lovers,

[some stuff deleted...]
>He seems relatively sure that the computer on which this ran was in most
>respects a clone of a PDP-?.
>   This project is not a breach of national security or a boon for old
>cold warriors;  It is however important to us.  If anybody can help with
>even just a lead worth following we would be in your debt.
>   The following is the mystery code:
>
>         .ROOT GOLKKK-L*(KOK, PRIV1,PRIV2,GRAD)
>KOK:     .FCTR KOKILK-INV-LAMB-PEREK-FUN1-L
>PRIV1:   .FCTR PRIVX1-MULT-PEREK-L
>PRIVS:   .FCTR PRIVX2-ALNFAS-INV-ZEROIN-FUN1-L
>GRAD:    .FCTR GRADTK-FUN1-DLINN-DLN1-L
>INV:     .FCTR INVAR-KRTR-F-TLXV-MULT-FUNF-DLINN-DLN1
>L:       .FCTR LB:(1,1)FOROTS/LB
>         .END
>
>All except L, LB, FOROTS are either functions or subroutines.  The words
>on the left, ie, KOK:, PRIV1:, etc, seem to be defining sequences of
>subroutine and function calls-- those which follow after the word .FCTR on
>the same line.  Our best guess is that this is assembler code. But what does
>it mean?    Does anyone recognize this as being something??  How about
>being definitely NOT something??   Thanks for being there!

Well, just a shortie... The file you gave us is an overlay description
file, or ODL file for short. It is used by the linker to produce the
executable file. The machine is very probably some variant of the
pdp-11. The operating system is most probably some variant of RSX. (By
the looks of the filespec for the FORTAN library.)

The ODL file is input to the linker, called TKB (TasK Builder), which
understands that garbage... :-)

Hope this will help you.

(If you're going to compile the programs on a 32-bit architecture, you
can skip all the overlay stuff, and just link it flat.)

Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Date: Mon, 13 Jul 92 16:12:23 -0400
From: [email-masked] (Jan Brittenson)
To: [email-masked], [email-masked]
Subject: Re:  mysterious code:anybody recognize it as PDP assembly??

Date: Mon, 13 Jul 92 16:12:23 -0400
From: [email-masked] (Jan Brittenson)
To: [email-masked], [email-masked]
Subject: Re:  mysterious code:anybody recognize it as PDP assembly??

IZZYCT4:

 >          .ROOT GOLKKK-L*(KOK, PRIV1,PRIV2,GRAD)
 > KOK:     .FCTR KOKILK-INV-LAMB-PEREK-FUN1-L
 > PRIV1:   .FCTR PRIVX1-MULT-PEREK-L
 > PRIVS:   .FCTR PRIVX2-ALNFAS-INV-ZEROIN-FUN1-L
 > GRAD:    .FCTR GRADTK-FUN1-DLINN-DLN1-L
 > INV:     .FCTR INVAR-KRTR-F-TLXV-MULT-FUNF-DLINN-DLN1
 > L:       .FCTR LB:(1,1)FOROTS/LB
 >          .END

   This is a TKB overlay description for PDP-11. Looks like RSTS/E in
particular, since I don't believe RSX accepts parentheses in directory
specifications (PPN/UIC). .ROOT is the top of the overlay hierarchy,
and I believe the file specifies that GOLKKK is the top of it all, and
it calls the modules KOK, PRIV1, PRIV2, GRAD, which are to be
automatically loaded (TKB can automatically emit code to load
overlays, this is why the description is necessary) as required. These
four guys never call each other. Below, the .FCTR directives specify
exactly which files are part of each module. `L' is declared as a
pseudonym for the FORTRAN library (LB:[1,1]FOROTS/LB).

   You can probably discard this file if you're building the program
on a machine with a larger virtual address space (say a Unix box, IBM
PC clone, or a 370 compatible).

Good luck!

						-- Jan Brittenson
						   [email-masked]

Date: Mon, 13 Jul 92 13:42:09 PDT
From: History shows that the Red Sox always win the World Series in the year after a Russian revolution.  13-Jul-1992 1641 <[email-masked]>
To: [email-masked]
Apparently-To: [email-masked]
Subject: Re:  mysterious code:anybody recognize it as PDP assembly??

Date: Mon, 13 Jul 92 13:42:09 PDT
From: History shows that the Red Sox always win the World Series in the year after a Russian revolution.  13-Jul-1992 1641 <[email-masked]>
To: [email-masked]
Apparently-To: [email-masked]
Subject: Re:  mysterious code:anybody recognize it as PDP assembly??

Oops.

I should have realised that two-character devices (LB:) were 11s.

I'm glad the rest of what I said was reasonably on-target..

I've been away from ALL of the small dec hardware for far too long....

John Francini

Date: Mon, 13 Jul 92 15:39:39 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: Available hardware

Date: Mon, 13 Jul 92 15:39:39 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: Available hardware

I'm on vacation in michigan right now, so I took the time to look through
the  o
the U of Michigan surplus outlet (on Baxter Rpoad on the UM North Campus).
The place is open afternoons from 1 to 4.

In addition to new stuff like vaxes, they had a few RX02 drives (I think
I saw three), and a few other like machines, including LSI/11 kinds of
hjardware.  It's obviously a place to keep an eye on.  All I found that
I could use were a number of 8 inch diskettes and a few rack-mount slides.

				Doug Jones
(pardon the typos, my telnet host here in michigan seems confused about
it's terminal type and backspace doesn't work)

Date: Mon, 13 Jul 92 23:46:48 MET DST
From: Johnny Billquist <[email-masked]>
Reply-To: [email-masked]
To: History shows that the Red Sox always win the World Series in the year after a Russian revolution. 13-Jul-1992 1641 <[email-masked]>
Cc: [email-masked]
Subject: Re: mysterious code:anybody recognize it as PDP assembly??

Date: Mon, 13 Jul 92 23:46:48 MET DST
From: Johnny Billquist <[email-masked]>
Reply-To: [email-masked]
To: History shows that the Red Sox always win the World Series in the year after a Russian revolution. 13-Jul-1992 1641 <[email-masked]>
Cc: [email-masked]
Subject: Re: mysterious code:anybody recognize it as PDP assembly??
In-Reply-To: Your message of Mon, 13 Jul 92 13:42:09 PDT

>Oops.
>
>I should have realised that two-character devices (LB:) were 11s.
>
>I'm glad the rest of what I said was reasonably on-target..
>
>I've been away from ALL of the small dec hardware for far too long....

I ought to put our pdp-11/70 on top of your head for that statement
about 'small' dec hardware... ;-)

Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

From: [email-masked] (Chuck Huffington)
Date: Mon, 13 Jul 1992 15:28:59 PDT
To: [email-masked]
Subject: Re:  mysterious code:anybody recognize it as PDP assembly??

From: [email-masked] (Chuck Huffington)
Date: Mon, 13 Jul 1992 15:28:59 PDT
In-Reply-To: uunet!gnu.ai.mit.edu!bson (Jan Brittenson)
       "Re:  mysterious code:anybody recognize it as PDP assembly??" (Jul 13, 16:12)
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: [email-masked]
Subject: Re:  mysterious code:anybody recognize it as PDP assembly??

On Jul 13, 16:12 Jan Brittenson wrote:
|Subject: Re:  mysterious code:anybody recognize it as PDP assembly??
|IZZYCT4:
|
| >          .ROOT GOLKKK-L*(KOK, PRIV1,PRIV2,GRAD)
| > KOK:     .FCTR KOKILK-INV-LAMB-PEREK-FUN1-L
| > PRIV1:   .FCTR PRIVX1-MULT-PEREK-L
| > PRIVS:   .FCTR PRIVX2-ALNFAS-INV-ZEROIN-FUN1-L
| > GRAD:    .FCTR GRADTK-FUN1-DLINN-DLN1-L
| > INV:     .FCTR INVAR-KRTR-F-TLXV-MULT-FUNF-DLINN-DLN1
| > L:       .FCTR LB:(1,1)FOROTS/LB
| >          .END
|
|   This is a TKB overlay description for PDP-11. Looks like RSTS/E in
|particular, since I don't believe RSX accepts parentheses in directory
|specifications (PPN/UIC). .ROOT is the top of the overlay hierarchy,
|and I believe the file specifies that GOLKKK is the top of it all, and
|it calls the modules KOK, PRIV1, PRIV2, GRAD, which are to be
|automatically loaded (TKB can automatically emit code to load
|overlays, this is why the description is necessary) as required. These
|four guys never call each other. Below, the .FCTR directives specify
|exactly which files are part of each module. `L' is declared as a
|pseudonym for the FORTRAN library (LB:[1,1]FOROTS/LB).

You almost got it right.  The parens have nothing to do with
ppn/uic.  In this context they meant that the modules within
occupy the same memory locations.  If they are omitted the
modules will concatenate instead of overlaying.

I can't recall what the * means.  It has been too many years.

Date: Tue, 14 Jul 92 10:27:07 MET DST
From: Johnny Billquist <[email-masked]>
Reply-To: [email-masked]
To: [email-masked] (Chuck Huffington)
Cc: [email-masked]
Subject: Re: mysterious code:anybody recognize it as PDP assembly??

Date: Tue, 14 Jul 92 10:27:07 MET DST
From: Johnny Billquist <[email-masked]>
Reply-To: [email-masked]
To: [email-masked] (Chuck Huffington)
Cc: [email-masked]
Subject: Re: mysterious code:anybody recognize it as PDP assembly??
In-Reply-To: Your message of Mon, 13 Jul 1992 15:28:59 PDT

>|   This is a TKB overlay description for PDP-11. Looks like RSTS/E in
>|particular, since I don't believe RSX accepts parentheses in directory
>|specifications (PPN/UIC). .ROOT is the top of the overlay hierarchy,
>|and I believe the file specifies that GOLKKK is the top of it all, and
>|it calls the modules KOK, PRIV1, PRIV2, GRAD, which are to be
>|automatically loaded (TKB can automatically emit code to load
>|overlays, this is why the description is necessary) as required. These
>|four guys never call each other. Below, the .FCTR directives specify
>|exactly which files are part of each module. `L' is declared as a
>|pseudonym for the FORTRAN library (LB:[1,1]FOROTS/LB).
>
>You almost got it right.  The parens have nothing to do with
>ppn/uic.  In this context they meant that the modules within
>occupy the same memory locations.  If they are omitted the
>modules will concatenate instead of overlaying.

You're wrong. You are right that parens are used for overlaying
modules in the same memory, but LB:(1,1)FOROTS is a filespecification,
which are also eligible in .ODL files.

I said RSX before, but I suspect Bson is right. It's probably RSTS/E.

>I can't recall what the * means.  It has been too many years.

Autoloading.

Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Date: Sun, 19 Jul 92 00:35:05 PDT
From: [email-masked] (peter kevin lund)
To: [email-masked]
Subject: Looking for those finishing touches.

Date: Sun, 19 Jul 92 00:35:05 PDT
From: [email-masked] (peter kevin lund)
To: [email-masked]
Subject: Looking for those finishing touches.

Thanks to all who helped me get my 8/f working a few weeks ago; mail to
a couple of you bounced, so please don't be offended if you didn't hear
from me...

Anyway, I'm now in the position of shopping for memory and mass storage.
I have two 4K boards, which I've been advised is pretty minimal; if
somebody has some laying about (yeah, right!), I'd be interested in
talking with them about it...

Next up, storage...my school (UC Riverside) has a monthly sale of stuff
departments no longer want; at last check, they had a bunch of RX02s and
RL02s ($25/unit, $5 for RL02 media).  No omnibus controllers though.
I really like the RL02s on a general spiffiness basis; do omnibus interfaces
for them exist?

So the bottom line is, I'm looking for memory and drive interfaces; I can
offer (besides $) cheap RL02 cartridges and the great mystery board: the
M1705.  Oh, and one other thing; I saw some cards for sale which were
like half-width unibus cards; two sets of fingers on the bottom and two
plastic handles on top.  Do these have any relevance? (to anybody?  They
were dirt cheap...and I bet nobody's bought em...).

  Thanks,

      Kevin Lund ([email-masked])

From: [email-masked] (Andrew Mears)
Subject: Help - What to do with DECmate IIs !!
To: [email-masked]
Date: Wed, 22 Jul 92 17:25:17 EST

From: [email-masked] (Andrew Mears)
Subject: Help - What to do with DECmate IIs !!
To: [email-masked]
Date: Wed, 22 Jul 92 17:25:17 EST
X-Mailer: ELM [version 2.3 PL4]

I have two old Digital Equipment DECmate II WPS-8 word processing systems v1.5.0
that I wish to either make use of or get rid of. One of the machines has a
CP/M 2.2 board in it. 

I know very little about these machines and was wondering if anybody can
fill me in on the most recent of this now discontinued system and software. Are
there any archive sites around that are worth a look?

Is there any useful software around, such as print servers, mail handlers etc.

What can I do with them other than turn them into sea anchors?

I'm not yet subscribed so please email me.

Thanks in advance,

Andrew Mears
<[email-masked]>

To: [email-masked] (Andrew Mears)
Cc: [email-masked], [email-masked]
Subject: Re: Help - What to do with DECmate IIs !! 
Date: Wed, 22 Jul 92 09:34:30 -0700
From: [email-masked]

To: [email-masked] (Andrew Mears)
Cc: [email-masked], [email-masked]
Subject: Re: Help - What to do with DECmate IIs !! 
In-Reply-To: Your message of "Wed, 22 Jul 92 17:25:17 EST."
             <[email-masked]> 
Date: Wed, 22 Jul 92 09:34:30 -0700
From: [email-masked]

I am also interested in information about DECmate II or III's. I would like to
obtain one or the other to go with older 8's in my collection, but I don't
know anything about them. Which is the most fun or interesting? Can I run some
of the same softare on my PDP-8e with OS/8 and on a DECmate?

Paul Pierce
[email-masked]

Date: Thu, 23 Jul 92 06:23:27 PDT
From: Life is short. SQL Hard. <[email-masked]>
To: [email-masked]
Apparently-To: [email-masked]
Subject: DECmate-{I/II/III} Uses: OS/278

Date: Thu, 23 Jul 92 06:23:27 PDT
From: Life is short. SQL Hard. <[email-masked]>
To: [email-masked]
Apparently-To: [email-masked]
Subject: DECmate-{I/II/III} Uses: OS/278

	The one I've got I plan to put OS/278 on and get "real" FOCAL
	running, which if I can get stuff ported onto it will essentially
	give me a PDP-8 !

	rcs

From [email-masked] Thu Jul 23 13:05:22 1992
To: [email-masked]
Subject: Please take me off the list
From: [email-masked]
Date: Thu, 23 Jul 92 12:48:44 EDT
Organization: Florida Atlantic University, Boca Raton

Please Unsubscribe [email-masked]

Thanks

--- InterNet: [email-masked]      "Seer Snively"
  Steal this .sig  |   Better dead than Prodigy  |   Love & be loved.
I'm just a Kesey loving, drum playing, computer using, incense burning,
philosophical deadhead hippie high school kid with a netnews account.

Date: Wed, 29 Jul 92 21:24:13 MET DST
From: Johnny Billquist <[email-masked]>
Reply-To: [email-masked]
To: [email-masked] (peter kevin lund)
Cc: [email-masked]
Subject: Re: Looking for those finishing touches.

Date: Wed, 29 Jul 92 21:24:13 MET DST
From: Johnny Billquist <[email-masked]>
Reply-To: [email-masked]
To: [email-masked] (peter kevin lund)
Cc: [email-masked]
Subject: Re: Looking for those finishing touches.
In-Reply-To: Your message of Sun, 19 Jul 92 00:35:05 PDT

>Thanks to all who helped me get my 8/f working a few weeks ago; mail to
>a couple of you bounced, so please don't be offended if you didn't hear
>from me...
>
>Anyway, I'm now in the position of shopping for memory and mass storage.
>I have two 4K boards, which I've been advised is pretty minimal; if
>somebody has some laying about (yeah, right!), I'd be interested in
>talking with them about it...

Yes, 8K is pretty minimal. You can have up to 32K, which I'd
recommend...
Sorry, I don't have any spare memory right now.

>Next up, storage...my school (UC Riverside) has a monthly sale of stuff
>departments no longer want; at last check, they had a bunch of RX02s and
>RL02s ($25/unit, $5 for RL02 media).  No omnibus controllers though.
>I really like the RL02s on a general spiffiness basis; do omnibus interfaces
>for them exist?

Yes. Omnibus controllers for the RL01/RL02 exists, that are called
RL8A, and you'll need the hex-omnibus backplane expansion, since the
RL8A is a hex-width flip-chip. Don't remember the name of the
expansion box though...

>So the bottom line is, I'm looking for memory and drive interfaces; I can
>offer (besides $) cheap RL02 cartridges and the great mystery board: the
>M1705.  Oh, and one other thing; I saw some cards for sale which were
>like half-width unibus cards; two sets of fingers on the bottom and two
>plastic handles on top.  Do these have any relevance? (to anybody?  They
>were dirt cheap...and I bet nobody's bought em...).

No RL8A to spare, sorry. (I only have one). Unibus is hex-width, so
the cards you describe are rather 1/3 unibus width. Or double-height
flip-chip. No idea what they are, though...

>  Thanks,

Not much help, but maybe you got a little wiser from my ramblings.

Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol