Subject: does this still exist?
From: "Ken A. Sturrock" <[email-masked]>
To: [email-masked]
Date: Tue, 7 May 91 02:38:54 -0400

Date: Tue, 7 May 91 02:38:54 -0400
From: "Ken A. Sturrock" <[email-masked]>
To: [email-masked]
Subject: does this still exist?

does this list still exist? If so, I'd like to join!

						-ken sturrock

-------------------------------------------------------------------------------
Ken Sturrock                                 (internet) [email-masked]
                                             (bitnet)            antkasx@gsuvm1

Date: Tue 7 May 91 18:25:36
From: Johnny Billquist <[email-masked]>
Subject: Some stuff...
To: [email-masked]

Date: Tue 7 May 91 18:25:36
From: Johnny Billquist <[email-masked]>
Subject: Some stuff...
To: [email-masked]

Well, I finally got a new modem for my pdp8, so now I'm
online again...

While I'm at it, I might as well try to say something.

First of all. I still miss an archive site. Since this seems
to be not so easy to setup as I hoped, I'll try to organize
things a little. Everybody how knows somewhere where we can
possibly set up an archive, please let me know, and I'll try
to dig further into it.

I'd also recommend everybody who has pdp8's to get Charles Lasners
ENCODE/DECODE program. Available together with his KERMIT12 on
watsun.cc.columbia.edu (Charles, correct me if I'm wrong, and
I don't know what directory). The files are K12ENC and K12DEC
I think.
I think we should use these programs for all binary file trasnfers.
If anybody is interested in how the programs work, ask the author.

Also, I might have promised some DECtapes to somebody, whose address
and name I have lost. If that person still needs 'em, let me know.

Another thing: If people need media convertions, and can't get it
from somewhere else, I have RX01, DECtape, Papertape, magtape,
RK05, RL02 on my eights.

Also, I'm always looking for more hardware. Things I'd like to
get my hands on now is: KE8-E EAE, FPP8-A, RL8A.
I'd like to buy, trade or recieve that stuff.
Things I have, that I might trade: KK8-E, KK8-A, KM8-A, DKC8-AA,
PC8-E, maybe some core memory (8K cards), plus maybe some other
stuff. Ask me...

If anybody knows of some hardware that isn't needed somewhere,
let me know, PLEASE! I live in Sweden, but I'll pay shippings.

Actually all king of hardware might be interesting, but not
whole boxes, just cards.

Just as a teaser, so that we might get an archive site:
I have a *much* improved (over DEC) FORTRAN IV here.
Also, my own KERMIT, which only runs on omnibus pdp8, but is
very nice. Lots of smaller CUSPs. Also, when we get an archive
site, we should be able to put a lot of OS/8 there.

I can't think of anything more to say right now.

	Johnny

Date: Tue 7 May 91 18:27:20
From: Johnny Billquist <[email-masked]>
Subject: Re: does this still exist?
To: [email-masked]
Cc: [email-masked], [email-masked]

Date: Tue 7 May 91 18:27:20
From: Johnny Billquist <[email-masked]>
Subject: Re: does this still exist?
To: [email-masked]
Cc: [email-masked], [email-masked]
In-Reply-To: <[email-masked]>

It sure exists, a little low on traffic sometimes, but it
exists.

I hope RS have added you by now. Otherwise, a hint is to write
to pdp8-lovers-request asking to be added to the list. (Same node).

	Johnny

Date: Tue, 7 May 91 15:46:13 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: Archiving, etc.

Date: Tue, 7 May 91 15:46:13 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: Archiving, etc.

It really is unfortunate that we still don't have an archive site :-(.

As Johhny Billquist says, we should all be using my ENCODE/DECODE
program to move "ASCII-fied" versions of binary files around.  This
solves several problems:

TECO macros are not quite "printable" ASCII files.  Encoding them
preserves the original contents.

Binary files of all descriptions (.RL .BN .SV, etc.) have to be encoded
because only OS/8 knows how to use them properly.  All other systems
will mangle them badly.

Some sources need the precise nature of the <CR> and <LF> preserved.
Since unix is a likely part of the "path" between us, the use of the
encoding will prevent loss.

Some binary files (mostly .SV files) have large regions of repeating
words, like 7402 octal or 0000.  Any other commonly available encoding
scheme is not 12-bit oriented, so the repetition of a pattern which is
only accessible in 3-for-2 form (OS/8 file strung out into 8-bit bytes)
won't look like a one-byte repeating pattern.  While LZW-oriented
compression will pick this up, all run-length methods will break down.
The ENCODE/DECODE program finds up to 256 occurrences of any 12-bit
pattern, and compresses it down to a sample and a repeat count.  So,
unless you want to store files we can't (currently) deal with on the -8
directly, use the ENCODE program to save storage space while you're at
it.  A forerunner of the ENCODE program used six-bit encoding, similar
to uuencode/uudecode, and no compression.  The new format is five-bit
encoding with run-length compression.  The release file K12MIT.SV, which
is the "standard" assembly of KERMIT-12, my KERMIT for all -8's and
DECmates, compresses into LESS total space with the new method, even
though the encoding is theoretically inferior (but more robust).  Thus
is the importance of compression.

The ENCODE/DECODE program is available from watsun.cc.columbia.edu via
anonymous ftp.  The encoder is known as k12enc.pal and the decoder is
k12dec.pal.  The encoder is not guaranteed to be assemblable with
"ancient" versions of PAL8; the decoder has been written with a
"brain-dead" implementation of PAL8 in mind - my recollection of PAL8 V1
as provided on the original version of PS/8.  The file k12pl8.enc is
PAL8 VB0 from OS/278 V2, and k12crf.enc is the companion CREF VB0.
These are DECODEable with the running copy of DECODE.SV you can create
with your own "lesser" version of PAL8 (hopefully any version will do
:-)).  Once they are available, you can assemble the ENCODE program.
PAL8 and CREF VB0 should work fine on any OS/8 system.  I have
hand-checked the binary looking for errant IOTs and OPRs.  I am glad to
say that there are none.  There are only two minor things to worry
about:

This version of the programs works with OS/278 V2 which has a major
dangerous bug.  The bug is that if the largest empty on a device is at
the end of the device (often true), it is claimed to be two larger than
actual!  This was apparently erroneously added as an "answer" to an
older bug in OS/8 - that any empty involving record 7777 would be
claimed to be one too few (which was always safe).  As long as the empty
is either not fully filled, or isn't the one on the end of the device,
the program will work fine.  All OS/278 versions of programs should be
suspect relative to this problem.  KERMIT-12 assumes that the returned
count is a "lie" by two, and handles it as such.  The only problem is
that theoretically, a file full situation occurs unnecssarily, and thus
foreshortens a possibly long file.  There is no situation that will
destroy the device such as possibly PAL8 and CREF, or any other OS/278
program.  Probably, most of these programs err on the conservative side
when used with OS/8, so there is no real danger.

There is an interaction between all OS/278 programs and prior versions
of the TTY: handler.  Because of the hardware incompatibility of the
DECmate, it is mandatory to do KRB after KSF skips.  Further, KSF will
not skip again.  This is true on the -8 also, although the KRB clears
the flag, not the KSF as on the 6120-based machines.  Since PAL8 (and
CREF) does <^C> checking, the flag cannot stay up for non-<^C> purposes
as in prior OS/8 situations.  This affects the TTY: handler where is
allowable to hit <^Z> to terminate the handler input when it should be
otherwise null.  Consider the following assembly:

.R PAL8
FOO<TTY:,DSK:BAR

DECTAPE=1
^Z           {this ends pass one}
^Z           {this ends pass two}

The timing is such that you can press the second <^Z> at the time of the
first one.  This is because pass-two input isn't needed in this
situation, and the OS/8 TTY: handler will find the ^Z and terminate with
null input back to the caller (PAL8).  When using PAL8 Version B0, the
flag doesn't stay up, so it is necessary to press the <^Z> when the
handler is waiting at the beginning of the second pass, not earlier as
you formerly could.

A third consideration is that this PAL8 is a 128K-supporting version,
identical to a few prior releases.  The major difference is that the
source truncates one column earlier, and the listing is one column
narrower because the full address portion of the listing is one digit
wider.  Unlike all prior versions of CREF, CREF Version B0 does this
correctly :-), so you can finally get a proper listing again.  I
strongly advise against using PAL8/CREF combinations past V10A and
before VB0.  (Note the reversal of the version number, another OS/278
quirk.)

Here is a sample ftp session to locate the KERMIT and ENCODE/DECODE
files.  The file k12mit.dsk describes all of the files as situated on
two release disks in RT-11 RX02 format.

$ ftp
ftp> open watsun.cc.columbia.edu
Connected to watsun.cc.columbia.edu.
220 watsun FTP server (Version 4.169 Mon Mar 19 11:02:20 EST 1990) ready.
Name (watsun.cc.columbia.edu:lasner): anonymous
331 Guest login ok, send ident as password.
Password:
230 Guest login ok, access restrictions apply.
ftp> cd kermit/d
250 CWD command successful.
ftp> dir k12*.*
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
-rw-rw-r--  1 4505     1327          526 Sep 13  1990 k12clr.pal
-rw-rw-r--  1 4505     1327         7961 Sep 13  1990 k12crf.enc
-rw-rw-r--  1 4505     1327        29175 Sep 13  1990 k12dec.pal
-rw-rw-r--  1 4505     1327        12092 Sep 13  1990 k12enc.doc
-rw-rw-r--  1 4505     1327        28978 Sep 13  1990 k12enc.pal
-rw-rw-r--  1 4505     1327         2556 Sep 13  1990 k12glb.enc
-rw-rw-r--  1 4505     1327         8831 Sep 13  1990 k12mit.ann
-rw-rw-r--  1 4505     1327        28356 Oct  7  1990 k12mit.bwr
-rw-rw-r--  1 4505     1327       112616 Sep 13  1990 k12mit.doc
-rw-rw-r--  1 4505     1327        16274 Sep 13  1990 k12mit.dsk
-rw-rw-r--  1 4505     1327        11536 Sep 13  1990 k12mit.enc
-rw-rw-r--  1 4505     1327        14716 Sep 13  1990 k12mit.lst
-rw-rw-r--  1 4505     1327       224685 Sep 13  1990 k12mit.pal
-rw-rw-r--  1 4505     1327         4976 Sep 13  1990 k12mit.upd
-rw-rw-r--  1 4505     1327        24305 Sep 13  1990 k12pch.pal
-rw-rw-r--  1 4505     1327        11617 Sep 13  1990 k12pl8.enc
-rw-rw-r--  1 4505     1327         1231 Sep 13  1990 k12prm.pal
226 Transfer complete.
remote: k12*.*
1122 bytes received in 0.26 seconds (4.2 Kbytes/s)
ftp> quit
221 Goodbye.
$ 

Re media conversion:

I can handle the following media:

DECtape
LINCtape
paper-tape
RX01
RX02
RK8E
certain forms of magtape (800,1600,3200)
SyQuest SQ-400 (SQ-555 45 MByte drives)
CESI HD floppies (5.25" 1.2 MByte)

as well as my fixed disk (80 MByte on OMTI 5400 SCSI controller)

I can also handle PC formats:

1.2 MBytes and 360KBytes 5.25" floppies
720KBytes and 1.44 MBytes 3.5" floppies
SyQuest SQ-400 (SQ-555 45 Mbyte drives)
Colorado Memories DJ10 (jumbo) tape cartridges (40 MBytes and 60
MBytes)

I don't like to send RK05s in the mail :-), but all the other removable
media can be shipped as necessary.

Charles Lasner ([email-masked])
cjl

Date: Sat 11 May 91 00:48:30
From: Johnny Billquist <[email-masked]>
Subject: Re: Archive site.
To: [email-masked]
Cc: [email-masked], [email-masked]

Date: Sat 11 May 91 00:48:30
From: Johnny Billquist <[email-masked]>
Subject: Re: Archive site.
To: [email-masked]
Cc: [email-masked], [email-masked]
In-Reply-To: <[email-masked]>

Well, Steve. If you can get things working, it sure would be
nice.

It might be possible to set up a FTP site at MIT, but nothing for
sure yet. Keep working on it!!!

	Johnny

Summary-line:  9-May     [email-masked]  #Archive site.
Date:    Thu, 9 May 1991 21:40:56 -0700 (MST)
From: Steve Gibbons <[email-masked]>
Subject: Archive site.
To: [email-masked]

Date:    Thu, 9 May 1991 21:40:56 -0700 (MST)
From: Steve Gibbons <[email-masked]>
Subject: Archive site.
To: [email-masked]
X-Vmsmail-To: SMTP%"[email-masked]"

Some assumptions:
1) I can obtain a uVAX
2) I can obtain an IP implementation for 1)
3) I can obtain a link to the rest of the IP world
4) I have enough storage

Items 1 and 2 are reasonably certain.
Item 3 should come soon.
item 4 is in question (unless someone would like to donate an RD53 to the
cause...)  My estimation is that 50-70 MB (read RD-53) would be about optimal
for a PDP-8 archive server.  FTP and ListServer...

I don't mean to get anyone's hopes up, but this _might_ actually work out...

Any thoughts?

 ____________________________________________________________________________
| Steve Gibbons, H.I.S. Interfacing | 602/885-7700x2649 or 602/296-8936(Fax) |
|   Sunquest Information Systems    |  spg@{alpha|beta|charon}.sunquest.com  |
>----------------------------------------------------------------------------<
| Never tell people how to do things. Tell them what to do and they will     |
| surprise you with their ingenuity.                                         |
| - George S. Patton, "War As I Knew It", 1947                               |
`----------------------------------------------------------------------------'

Date: Mon, 13 May 91 15:56:52 EDT
From: [email-masked] (Eric K. Olson)
Reply-To: [email-masked]
To: [email-masked]
Subject: Is this list alive?

Date: Mon, 13 May 91 15:56:52 EDT
From: [email-masked] (Eric K. Olson)
Reply-To: [email-masked]
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: [email-masked]
Subject: Is this list alive?

I sent mail asking to be added to this list to [email-masked],
a while ago.  Am I not on the list ([email-masked])?
Or is the list silent at the moment (which question this message will
probably answer for me).

Cheers!

-Eric

-- 
Eric K. Olson, Editor, Prepare()      NOTE:     [email-masked] doesn't work
Lexington Software Design             Internet: [email-masked]
72A Lowell St., Lexington, MA  02173  Uucp:     harvard!endor!olson
(617) 863-9624                        Bitnet:   OLSON@HARVARD

Date: Mon, 13 May T  21:32:33 EDT
From: Jan Brittenson <[email-masked]>
To: [email-masked], [email-masked],
        [email-masked]
Subject: Re:  Is this list alive?

Date: Mon, 13 May T  21:32:33 EDT
From: Jan Brittenson <[email-masked]>
To: [email-masked], [email-masked],
        [email-masked]
Subject: Re:  Is this list alive?

 > From: bootsie!olson (Eric K. Olson)

 > I sent mail asking to be added to this list to
 > [email-masked], a while ago.  Am I not on the list
 > ([email-masked])?

   No, you were not on the list. I think RS has been too busy to take
care of this (and any other administrative requests you PDP-8
eficionados may have pending). So I added you.

   If anyone else is waiting for the adm server (aka RS) to complete
their priority requests, just reissue them to me and I'll see what I
can do about it. At worst they will get defered back to RS.

						-- Jan Brittenson
						   [email-masked]

Date: Tue 14 May 91 04:05:23
From: Johnny Billquist <[email-masked]>
Subject: Re: Is this list alive?
To: [email-masked]
Cc: [email-masked], [email-masked]

Date: Tue 14 May 91 04:05:23
From: Johnny Billquist <[email-masked]>
Subject: Re: Is this list alive?
To: [email-masked]
Cc: [email-masked], [email-masked]
In-Reply-To: <[email-masked]>

There has been some traffic the last few days, so you should be
recieving some stuff...

	Johnny

Date: Fri, 17 May 91 21:57:00 -0500
From: Todd Enders - WD0BCI  <[email-masked]>
To: [email-masked]
Subject: PDP9, Anyone seen one?

Date: Fri, 17 May 91 21:57:00 -0500
From: Todd Enders - WD0BCI  <[email-masked]>
To: [email-masked]
Subject: PDP9, Anyone seen one?

     I was just looking through an old DEC Logic Handbook (positive logic
edition, (C) 1969), and in the back there were thumbnail sketches of the
various DEC minis extant at the time.  They had pdp-8, pdp-9, pdp-10 and
pdp-12, complete with representative pictures of a system of each type.

     Now the pdp-9 looks to me like a real neat machine.  Up to 32k words
of 18 bit memory (yes indeed, this was an 18 bit machine!), 1 microsecond
instruction cycle time, up to 256 i/o devices, etc.  And an *awesome*
front panel with *lots* of lights and switches! :-) :-) :-)  All this in
a 6 foot high by about 30 inch wide cabinet.

     Anyone ever see one of these beasts in action?  Was it as nice as it
seems from reading the sales hype?  Know where I could lay my hands on one?

Thanks!

===============================================================================

Todd Enders - WD0BCI                  ARPA: [email-masked]
Computer Center                       UUCP: ...!uunet!plains!enders
Minot State University                  or: ...!hplabs!hp-lsd!plains!enders
Minot, ND  58701                     Bitnet: enders@plains

     "The present would be full of all possible futures,
      if the past had not already projected a pattern upon it" - Andre' Gide

===============================================================================

From: Phil Budne <[email-masked]>
Date: Fri, 17 May 91 23:48:17 EDT
To: [email-masked], [email-masked]
Subject: Re:  PDP9, Anyone seen one?

From: Phil Budne <[email-masked]>
Date: Fri, 17 May 91 23:48:17 EDT
To: [email-masked], [email-masked]
Subject: Re:  PDP9, Anyone seen one?

> Up to 32k words of 18 bit memory (yes indeed, this was an 18 bit
> machine!)

As were the 1, 4, 7 and 15!

When I worked at DEC on 36 bit software, I met a few '15 folks who
seemed almost as sad as we were in the end!

I think I saw '7 in DEC salvage once.  Bore a resemblance to a PDP-6
(dull blue with metal trim).

I'm enclosing Mark Crispin's excellent PDP summary, since it hasn't
been re-posted in a while!

================

From [email-masked] Thu Jun  8 00:28:01 1989
Date: Thu,  8 Jun 89 00:09:28 EDT
From: "Robert E. Seastrom" <[email-masked]>
Subject:  What's a PDP-x ??
To: [email-masked]

If you folks have already seen this, please disregard it.  If
you haven't, keep it handy - it could come in handy some day.

                      ---Rob

PS: In case you didn't know (I didn't until 2 years ago), PDP
stands for Programmed Data Processor...

Date: Wednesday, 20 August 1986  03:42-EDT
From: Mark Crispin <[email-masked]>
To:   [email-masked], [email-masked]
Re:   DEC's PDP's
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052

     A number of people have requested my list of all the DEC PDP's,
so I thought I'd bore you all with it.

     The PDP-1 was an 18 bit machine.  It was DEC's first computer,
and some of the first timesharing systems were designed for it.  It's
also unique in being one's complement; all later DEC computers were
two's complement.  Some machines, such as one of MIT's PDP-1s, were in
operation until the late '70s.

     The PDP-2 was a designation reserved for a 24 bit machine, but as
far as I can tell it was never even designed and definitely none were
ever built.

     The PDP-3 was a 36 bit machine that was designed but never built
by DEC.  However, Scientific Engineering Institute built one in 1960.

     The PDP-4 was an 18 bit machine that was intended to be a
cheaper, slower alternative to the PDP-1.  It was so slow that it
didn't sell well, although it was interesting for its
auto-incrementing memory registers.  It was not program-compatible
with the PDP-1, but its instruction set was the basis of DEC's future
18 bit computers.

     The PDP-5 was a 12 bit machine designed to be a small laboratory
system.  It used many of the ideas in the LINC (Laboratory Instruction
Computer, designed by Lincoln Labs at MIT, some of which were built by
DEC).

     The PDP-6 was a 36 bit machine and the first machine to implement
the most wonderful computer architecture known to man.  It was rather
expensive and difficult to maintain, and not many were sold.  As a
result, DEC cancelled 36 bit computers for what was to be the first of
many times.

     The PDP-7 was an 18 bit machine and the sucessor to the PDP-4.
It was a major price/performance win over the PDP-4 and the first DEC
computer to use wire-wrapping.

     The PDP-8 was a 12 bit machine and the sucessor to the PDP-8.  It
basically defined the term "minicomputer", and went through several
incarnations.  The original PDP-8 was followed by the extremely slow
PDP-8/S (as bad as the PDP-4 was to the PDP-1, but at least the /S was
program-compatible).  DEC recouped with the PDP-8/I (using MSI
integrated circuits) and the smaller PDP-8/L, and somewhat later came
out with the "Omnibus 8" machines -- the PDP-8/E, the PDP-8/F (a
half-sized version of the PDP-8/E), the PDP-8/M (an OEM version of the
PDP-8/F), and the final machine, the single board PDP-8/A.  The
PDP-8/A still exists after a fashion as a current DEC product.

     The PDP-9 was an 18 bit machine and the sucessor to the PDP-7.
It had a faster memory than the PDP-7 and was the first
microprogrammed DEC computer.  Modulo a 300 wire(!) ECO required in
the first machines, the PDP-9 was a reliable machine and some are
still in operation today.  There was a short-lived PDP-9/L.

     The PDP-10 was a 36 bit machine and the sucessor to the PDP-6.
It is especially noted for its software, which represents the pinnacle
of DEC software engineering and has never been equalled.  The first
KA10, largely installed in universities, created a whole generation of
timesharing hackers.  The follow-on KI10, with paging and using IC's
instead of discrete components but otherwise unexciting, mostly was
sold to commercial organizations.  The KL10 went through several
incarnations and is today the most representative of this marvelous
machine.  The KS10 was a small, low-speed (approximately KA10
performance) processor which was DEC's last successful implementation
of this architecture.

     The PDP-11 was a 16-bit machine that went through more
implementations and operating systems than can be counted.  Presently
it superceded the less powerful PDP-8 as the representative
minicomputer.  While the PDP-11 used octal, it was in its deep heart
of hearts a hexidecimal machine, and the first indicator of the
creeping IBMification of DEC that took full fruit in the VAX.  [I can
hear the flames now...]  Rather than fight it the customers loved it;
more PDP-11's have been sold than any other DEC computer (possibly
more than all the others combined).

     The PDP-12 was a 12 bit machine and the sucessor to the PDP-8.
It combined a LINC and a PDP-8 type processor in the same box and
basically was a new model of the LINC-8 which was the same thing.

     No PDP-13 was ever designed or built.  Even DEC gets
superstitious.

     The PDP-14 was a 12 bit machine with a 1 bit register.  It was
used as a process control engine in applications that were felt to be
too rugged for a PDP-8, and basically replaced a set of relays.  Later
DEC made PDP-8's suitable for this sort of thing, but it didn't stop
them from the ultimate silliness of building a PDP-14 that used a
PDP-8 as its console processor!

     The PDP-15 was an 18 bit machine and the final one of this design
built by DEC.  More PDP-15's were built and sold than any of the
others, and it went through several incarnations including some which
used a PDP-11 as a front end.  Apparently the cancellation of the
PDP-15 came as a great surprise to the "Tiger Team" who worked on it,
although considering its general ungainliness compared to comparable
performance PDP-11's it wasn't surprising.  In many ways the PDP-15
died for the same reason the PDP-10 did.

     The PDP-16 was a "roll your own" 16 bit machine based on various
"building blocks".  Every PDP-16 was essentially custom-designed by
the customer.  It got a fair amount of attention when it was announced
but evidentally didn't sell very well.

     There was no PDP-17 or any other designator.  DEC apparently
decided that "PDP" had a perjorative ring to it.

Date: Mon, 20 May 91 17:05:28 PDT
From: [email-masked] (Paul Hardy)
To: [email-masked]
Cc: [email-masked]
Subject: PDP9, Anyone seen one?

Date: Mon, 20 May 91 17:05:28 PDT
From: [email-masked] (Paul Hardy)
To: [email-masked]
Cc: [email-masked]
In-Reply-To: Todd Enders - WD0BCI's message of Fri, 17 May 91 21:57:00 -0500 <[email-masked]>
Subject: PDP9, Anyone seen one?

I saw a PDP-9 in a hallway about ten years ago; looked like it was on its
way to the happy hunting ground in the sky.  The two things I remember about
it (impressions from a quick inspection) were that the display LEDs were
flourescent NIXIE tubes and there was some sort of round scope attached
to the main unit -- was this the console?!

                                   --Paul

Date: Wed, 22 May 91 5:17:25 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]

Date: Wed, 22 May 91 5:17:25 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]

From: Charles Lasner
Subj: Corrections and commentary on Mark Crispin's PDP list

    I have found "grievous" errors in Mark Crispin's descriptions of
PDP-xx computers from DEC, so herewith are some corrections:

PDP-1, 2, 3

    I have no fundamental problem with this description, however, I
would note that there is a story circulating that the original machine
was called PDP, *not* PDP-1.  The manual for the PDP was PDP-1, and they
intended it to stop there.  PDP-2 and PDP-3 are therefore tentative or
actual notation for more manuals.  I will not comment other than this
mention of the PDP-2, 3 memorial golf course :-)

PDP-4

    I once saw one of these in the Mill with a baudot teletype (model
28) hooked up to it; no further comment.

PDP-5

    The PDP-5 is nearly compatible with the PDP-8.  It has the program
counter in location zero.  Storing value-1 in 0000 is the same as a jump
to value.  This is how FOCAL, 1969 tests for running on the -5, since
interrupts must be moved from 0001 to 0002.  All other references to
0000 are disallowed, as are certain operate instructions.  These
restrictions seem arbitrary, and this was corrected in the PDP-8.  It's
probably not unreasonable to modify this machine to be -8 compatible,
although a little slow due to 8 microsecond memory.  Extended memory is
totally compatible, but EAE is not, it's more like a peripheral than a
processor option.  The bus can't do 3-cycle data break, but the early
555 DecTape ran on it in 1-cycle mode using the current Data Field as
the break field (which in turns means no interrupts are allowed while
the DMA is in progress!).  Other than that, through use of a physical
bus convertor (don't have the number, but I mean a passive device that
merely changes the connectors), the -5 likes -8 negative bus
peripherals.  An -8 expander box (804) was once hooked to a -5
containing the -8's plotter interface for a Calcomp plotter, etc.  Rumor
has it that someone modified the CPU of a -5 to gain the few operations
necessary to make it -8 compatible, and that an 8K version was running
OS/8 on some undisclosed peripheral.  I wouldn't give too much creedence
to the story because all of the early disk peripherals were 3-cycle
except the aforementioned 555 DecTape (as opposed to TC01 et al which is
three-cycle).

    The PDP-5 is clearly the PDP-8's father.  It is not known if it used
the PC in 0000 kludge as an economy measure, or just plain foolishness
at the time, but clearly, had it been slightly upgraded to PDP-8
processor compatibility by DEC, it would have been supported more
readily.  Many of the changes subsequently made to FOCAL, 1969, etc.
depend on removing restrictive operations caused by supporting the -5
and the even more demented 8/s (see below).  These restrictions mean
that you can't use combined operates such as CMA RAL because these two
can't do it.  In the -5's case, it's almost excusable, but in the -8/s
case it is not.

PDP-6

    The story I heard is that Alan Kotok virtually single-handedly got
all of the few made to work by using other people's memory.  Most wound
up in MIT at one time or another anyway.  The PDP-6 lacked certain
features required by later -10 systems, but was always welcome to ITS.

PDP-7

    It is interesting to note that a small class of peripherals were
introduced for either the -7/9 series or the -8.  I know of at least
two: the AA01A for the -8, and the type 884 sychronous modem interface.
Each was delivered in two parts.  One part was bus specific, and the
other was plugged into whichever first type you had installed
appropriately.  I personally participated in modifying the D-A part of a
AA01A to become an -8-only peripheral, because the trivial -8 interface
was a waste of valuable black block racks, and the empty space on the
AA01A was available to wrap on an -8-only interface complete with
daisy-chain.  I also once used a PDP-15 with a negative bus converter
which had the negative interface and 884 assembly for a synchronous
modem connection to an outside dedicated line.  It has been told to me
that the TC58/59 class of tape controllers consists of a generic
subsystem called TC50 internally, which is wrapped to a 7/9 bus or -8
bus specific portion to become the TC58 or TC59.  In this case, the two
are wrapped together, not cabled together, and are thus more or less
permanently attached.

PDP-8 and PDP-12

    Since the PDP-8 is the standard bearer of our group, we can't leave
any stone unturned here.  First off, the obvious typo in that the -8 is
the successor to the -5, not itself :=).  While the -8/s may be
extremely slow, it is also *not* compatible with the -8.  Please note
that OS/8 does *not* run on either the -5 or the 8/s.  This also applies
to P?S/8, which it should be noted runs on the entire -8 family from
PDP-8 through DECmate III+, whereas OS/8 has different "family" members
that each do part of this in an overlapping fashion.  I am part of a
group which desires to release OS/8 Version 5, to run on the entire
family.  Note, when all concerned parties discuss the "family of 8" the
-8/s and -5 are specifically omitted.  I have once discussed the
feasibility of upgrading the -8/s, and the consensus was that it could
be done, but it might run a bit slower, and in any case would require a
rack of cards hanging out of it.  It is also noteworthy that the -8/s
was originally a different project known as PDP-10!  It was to have 32K
memory implemented as drum-style memory as in earlier computers, and the
memory was what became the basis for the 32K PDP-8 fixed disk peripheral
called DF-32.  I guess they didn't pay close attention to the
improvements in processor OPR instructions the -8 made over the -5,
because the -8/s is *worse* than the -5 in terms of compatibility.  It
is also a fully *serial* computer, not parallel.  It should also be
noted that many DATA GENERAL Nova-type machines and micros were serial
or at least not fully parallel.

    Later models, the -8/i and -8/l did come out.  Early -8/i's had
Red-handled modules like the -8, even though the cards were TTL and
eventually became maroon (M modules).  There were even a few -8's with
8K in them ala the -8/i, because they had -8/i-type memory kludged into
them!  The -8/i originally had a negative bus, for compatibility with
the vast majority of existing peripherals made expressly for the -8.
The -8/l is essentially a stripped-down -8/i, and as such can have only
8 (or 12) K and a positive bus, whereas later -8/i's could have either
bus.

    The LINC-8 was an attempt to bring DEC some income from the MIT LINC
project.  After early on realizing that an independent LINC peripheral
would be difficult to pull off, the LINC-8 was born by making moderate
modifications to the -8 CPU and memory interface, and adding a "captive"
processor.  Many operations had to be simulated for complete
pseudo-compatibility with the *real* LINC, which in turn was constructed
of the same System Modules as the PDP-5.  The LINCtape peripheral is
actually an -8 peripheral, whose major registers are the LINC
processor's registers, which are "borrowed" because the LINC CPU is
totally disabled while the -8 runs the tape peripheral.  In certain
ways, the LINC-8 is a "cadillac" implementation of the -8, in that it
has certain niceties such as GMT 3 grasshopper fuses on all power
busses, and many fans, etc.  Also, the lamp drivers for all front panel
lamps are on actual small modules wrapped in, not one massive (and
damage-prone) lamp driver panel.  The bulbs still are soldered in here
though :-(

    The PDP-12 is a positive bus-only -8/i with a built-in DMA
multiplexor option eventually, as well as push-down stack hardware and
priority interrupt (KF-12B) as late-production standard features.  All
of the LINC stuff is "real" including the dual console.  There are less
actual lights than the LINC-8 because there is now only one set of
registers for a dual-mode processor, not two complete processors with
each's set of major registers displayed.  A standard option allows
read/write of DECtape, whereas only user modifications could do this on
the LINC-8 eventually.  The FPP-12 was born here, and included PDP-8 CPU
lockout mode option, although this was reborn in the FPP-8/e,a for the
Omnibus years later.  Clearly, the -12 was the one model that got the
benefit of "proper" hardware engineering, whereas subsequent models seem
to get ever shorter ends of the hardware "stick".  Curiously, a few
modules come from the LINC-8 project, because it was too much work to
recreate the function in TTL rather than negative voltage logic, so they
merely level converted and used a few R-series cards :-).  Some PDP-12
modules actually say they are specifics for the "LINC-8/i" which was
apparently its original designation.

    The PDP-12 is the only model where the number is also the word
length :-).  Many DEC-ignorant computer types actually believe that the
PDP-8 is an 8-bit machine!

    Newer models of -8's are all for the Omnibus, which defines all
processor and I/O signals on four DEC-feet or quad-width slot.  Various
incarnations are either wider or deeper, but all have the same bus.  The
standard is the -8/e, which is always 20 slots (optionally 40) in the
full-depth box, complete with bulky analog power supply.  The entry
level is the -8/m, which was designated for OEM's, and didn't include
the standard -8/e-type front panel with incandescant lamps.  The -8/f is
an -8/m including an LED variant of the lamp panel, and this panel is an
option for the -8/m as well.  Thus, the -8/m with panel and -8/f differ
only in color scheme and silk-screened name on the panel.  Both have a
slightly balky switching supply which is much smaller than the -8/e
supply, as well as much less power capability.  These machines are
"bread-box" size, and only allow for 20 slots in the box.  

    The newer breed of Omnibus boxes are all usually known collectively
as -8/a, but they came in various flavors: a short-lived 10-slot box
with many restrictions, a 12-slot box with somewhat more versatility,
and a 20-slot box with large power capability.

    Theoretically, any of these systems could be expanded from virtually
any model's box as an add-on to the base system, so standard options
included upgrading a 40-slot to 80-slot, or making a 20-slot -8/f grow
to 40 or optionally 60 slots using the same external -8/e-type box, etc.
The FPP-8/A was meant to go in the -8/a 12-slot box, which, like all
-8/a boxes, is hex-wide internally, not quad.  The sixth foot is
electrically non-existent and the fifth foot has only a few signals
optionally available later to various memory extension options beyond
32K.  When sold this way as an add-on for a 40-slot -8/e, the entire
option is known as FPP-8/e, including the BC-80C cable and 12-slot
hex-wide box, as well as the two hex-wide FPP cards.  My own machine is
a 40-slot -8/e, with a 20-slot -8/a box as an expander.

    The -8/a series also sports an optional octal digit LED readout
front panel, similar to an 11/34 in general appearance.

    Most of the -8/a models use a single slot CPU, the KK8A, which has
the bus pullups on it (at the *wrong* end electrically of the bus!)
which disallows the bus terminator, and is thus limited to what fits in
any one box, or at most 20 slots.  Some use the -8/e processor (KK8F)
which requires a terminator card (M8320) in the furthest slot away from
the CPU.  Some configurations reverse the apparent beginning and ending,
but always obey this rule.  This allows at least 40 slots (-8/e box or
two -8/a boxes) or at most 80 slots (two -8/e boxes).  It is possible to
discover which CPU is present due to specific CPU-model-dependent
quirks, but you can't tell more than that.  Some -8/a boxes are really
-8/e machines with -8/a memory options and all else is from an -8/e!
PDP-8/a systems get numeric suffixes like -100, -400, -500, and -600 as
well as model-option changes to make it something like -625, etc.  Since
there is much "plug and play" here, it is not too useful to describe an
-8/a system by model, but rather by specific components.

    All -8 models are backwards compatible with earlier bus
arrangements, and also there is a feeble attempt at forwards
compatibility called the DW-8/E.  This partially allows some Omnibus
stuff to work in the pre-Omnibus machines, but has many restrictions.  A
hacked-up version of the RK8E called RK8F is the only DMA option for the
DW8E.  The Omnibus machines support the positive bus via the KA8E and
KD8E(s).  The KA8E outputs a completely compatible positive transfer
bus, and each KD8E outputs a compatible DMA interface.  The Omnibus does
any priority multiplexing.  The negative bus is in turn supported by the
DW08A option, so it is reasonable to find a TC01 on an -8/a.  I have an
-8/e with a TC01 and TU55 myself.  (This requires an ECO to the W103
cards to become W123.)

PDP-9 and PDP-9/l

    The -9/l had a pink color scheme, and was apparently a stripped-down
-9.  The -9 was often sold with a -7 because there was some software
that ran on both simultaneously.  Apparently, the -7 became a dedicated
controller for the DECtape drives relative to the -9, because the -7 had
a feeble interface ala the TD8E on the -8/e, etc.  Later, the -9 got its
own TC02 DECtape, thus relieving the -7 requirement.

    I don't understand Mark Crispin's description of the -9 as being
microprogrammed.  Perhaps this is merely a misstatement of the fact that
the operate instructions, like in the -8, can be *user* microprogrammed
together such as:

    SMA SZA CLA         /skip if the AC is either negative or zero,
                        /and then clear the AC regardless.

    The -9 is not materially different in architecture from the -8, so I
can't imagine this meaning anything else.  I also understand that the
7/9/15 can microprogram more of these operations than the -8 can.  The
-8 is restricted to groups which can combine sub-operations, whereas the
18-bit machines can combine almost anything at once!

PDP-10

    The PDP-10 spawned much software development, and eventually
encouraged the use of BLISS.  It is noteworthy that much of the VAX
software is lifted directly from TOPS-20 because of the close
compatibility of the various (later) BLISS implementations.  However,
purists will note that BLISS-10 is *not* BLISS-36, while BLISS-32 just
about is.  This was done on purpose to rip off the -10 stuff for the
benefit of the VAX.  Perhaps this also means that some newer stuff can
come back to the 36-bit world as well :-)

PDP-11

    Since the early days of the RISC discussion, it has become debatable
whether the PDP-11 is more powerful than many designs, not just the -8.
I guess it all depends on how you measure the power.  The PDP-11
certainly had more hardware engineering effort applied, but was the
benefit worth the cost?  Measured this way, you could say the -11 is
DEC's weakest machine.  Look at how well the PDP-8 has fared while being
"negatively marketed" as compared to the -11!  Also, LCG had to put
controls on -11 marketing when salesmen were quoting -11 systems that
were a) impossible to implement (or at least highly impractical), and b)
were clearly short-changing a customer willing to shell out PDP-10-sized
bucks for a computer.  DEC also made lots of money selling the 11-03,
but I guess -11 freaks don't want to talk much about that :-)

    Various academic works have pinpointed the weaknesses of the -11 in
terms of pure architectural considerations.  The user group largely
consists of people who don't really know much about the -11, but rather
are in love with its software, and make the fatal mistake of measuring
the worth of a machine by how useful it is to them, not its intrinsic
value.  This merely means that DEC threw a lot of money at the -11, not
that it is a good design.  If RT-11 were known as RT-15 for the PDP-15
family, and DEC implemented an RT-11-like system for the -15 (which is
totally feasible, considering what a -15 is, and what RT-11 is), how
many of these people would be raving about how powerful the -15 is? :-)

    As a side note, there seems to be much interest in an RT-11-like
system for the VAX, presumably to be called RT-32.

    As is alluded to in THE SOUL OF A NEW MACHINE, the PDP-11 was born
over a weekend, appealing to the ego of certain individuals who could
pull strings in DEC, to pull the plug on what was to be known as DATA
GENERAL and the NOVA.  Considering the rocky road of the -11, it is
curious that DEC never sued DATA GENERAL over the NOVA's very existence.

cjl

Date: Fri 24 May 91 22:47:05
From: Johnny Billquist <[email-masked]>
Subject: Nostalgia trips anybody...?
To: [email-masked]

Date: Fri 24 May 91 22:47:05
From: Johnny Billquist <[email-masked]>
Subject: Nostalgia trips anybody...?
To: [email-masked]

I'm proud to announce the existance of an pdp-8/i on the internet.
The address is 130.238.4.9 (name is CRAP-1.UPDATE.UU.SE)

The machine is, as I said, an 8/i, with 8k core, four TU55 DECtape
drives. Anybody who cares is welcome to run on it, but it is a little
slow, due to swapping on the DECtape. Please notify me if you hang the
machine, so that it can be rebooted. Please do not clear the system dectape.
If you are unfamiliar with OS/8, the following commands and programs
whould be used carefully:
Commands:
ZERO
DELETE

Programs:
FOTP
PIP
BUILD   (Should probably not be used at all unless you know OS/8)

There exists an help, as well as the command "COMMANDS", which lists
all available commands.

Date: Tue, 28 May 91 11:46:11 CST
From: [email-masked]
Subject: PDP-8 Emulator, Software
To: [email-masked]

Date: Tue, 28 May 91 11:46:11 CST
From: [email-masked]
Subject: PDP-8 Emulator, Software
To: [email-masked]
X-Envelope-To: [email-masked]

Hello All,
    It's been many a year since I programmed on PDP-8's, but I havent forgotten
how much fun it was.  A nice small machine that took some effort to program,
but paid off with nice small tight programs.

I now work on Mac's, so I wrote a PDP-8 emulator for the Mac.  I expect it
should run about as fast as a PDP-8/E on my MacIIci.

It emulates the basic instruction set and 32K of memory.

And a simulated TTY 03/04.
And the rudiments of a simulated RK05.

Eventually I'd like to be able to boot OS/8 on it.  And make it available to one 
and all.

*But* I need some test programs to wring out the bugs out of the instruction set.
I'm pretty sure I have the basics of memory anddressing, indirection,
auto increment, and pending CIF's working.  It's just some of the subleties of
OPR that I probably havent polished.

Does anyone have all those wonderful MAINDEC's available on the net?
I seem to remember a large number of CPU test MAINDEC's.
I sure could use them right about now.....

Thanks in advance.

----------------------------------------------------------------------------
George R. Gonzalez             Microcomputer and Workstation Networks Center
[email-masked]      University of Minnesota

Date: Wed 29 May 91 05:20:56
From: Johnny Billquist <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PDP-8 Emulator, Software

Return-Path: <[email-masked]>
In-Reply-To: <[email-masked]>
Date: Wed 29 May 91 05:20:56
From: Johnny Billquist <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PDP-8 Emulator, Software

Aaargh. I have the MAINDEC's on papertape.
If you cant get 'em from somewhere else I might be persuaded
to load them down.

However, since the OPR's are pretty easy, you should be able
to figure out if they are correct anyway.

Need a short, but exact, description?

	Johnny

Date: Wed, 29 May 91 2:02:17 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: Maindec availability and PDP-8 emulators (to GRG, etc.)

Date: Wed, 29 May 91 2:02:17 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: Maindec availability and PDP-8 emulators (to GRG, etc.)

    First of all, you DO need the diagnostics to successfully debug an
emulator.  This is not the first time this has been done.

    Someone once remarked that the "most effective software" for the
PDP-15 was OS/8 and P?S/8 running under an emulator for the -8 written
by Mark Hyde.  This program got read in standalone in PDP-15 loadable
paper-tape (the -15 has a hardware RIM loader), and it just self-starts.

    The program starts by booting the DECtape on drive 0 -  the PDP-8
DECtape that is!  The idea is that all PDP-8 instructions up until
certain "sacred" IOT's in specific places are encountered are emulated
conventionally.  The special IOT's trigger a "smarter" mode of
operation: the contents of appropriate PDP-8 memory locations are
examined, and the proper course of action is taken.

    The emulator supports the standard DEC OS/8 system and non-system
handlers, and the P?S/8 extended unit system handler (which supports
drives 0-7 directly, unlike OS/8 where each handler only accesses one
drive).  There is no DECtape support for loose instructions, or other
handlers such as my own replacement TC01/08 OS/8 system handler with
drive one support coresidently and intelligent initial search direction
guesswork (same as in P?S/8's handlers).

    The point is that the emulator can do the DECtape I/O in real-time,
so the overall emulator efficiency is rather good.  Devices supported
are the console 03/04, high-speed reader/punch, the DECtape drives, and
if the -15 has the extend memory option, a 4-platter DF32 faked in
PDP-15 memory.

    Using this emulator allowed direct access to dismountable PDP-8
DECtapes which you could take off your -8 and bring to the -15.  I
believe that a recent version also added LPT: support as well.

    MainDEC diagnostics help prove an emulator totally works, because
there are sometimes complex interactions between instructions and
real-time.  For example, the PDP-8/e diagnostics check such things as
how many cycles go by (I think only one) before an SRQ instruction
actually skips after the TFL instruction sets the 04 output flag.  Or
just how CIF instructions precisely inhibit interrupts, affect GTF
instructions, etc.  The code looks somewhat pragmatic in the diagnostic
sources, but in any case, they enforce the precise definition of a
running machine.

    Curiously enough, the PDP-8 memory checkerboard program located an
error in the PDP-15 memory that skipped by the PDP-15 equivalent!  The
diagnostic correctly complained about the bad contents, which ultimately
led to PDP-15 modules being replaced :-).

    Another point about emulators: there can be high overhead for
emulating PDP-8 interrupts.  A good emulator should have a mode where
the ION mode goes away to enhance non-interrupt driven emulation.  Also,
emulating devices like RF08 and DF32 require "throttling" of the
emulation. i.e., deliberately slowing down the simulated transfer so the
diagnostics can work with expected timing, etc., lest insufficient
simulated CPU cycles get executed in favor of simulated DMA cycles, etc.

    Since some of the emulator authors are on the internet, I suggest
they access watsun.cc.columbia.edu for my KERMIT-12 sources.  Within
this collection is documentation for the PDP-8 ENCODE/DECODE
implementation I wrote with the aid of Frank Da Cruz of Columbia Kermit
fame.  This is an alternative to uuencode, etc., and is totally PDP-8
oriented.  Using this format, we can send the MainDECs to the emulator
authors unscathed by unwanted network "editing" of the binary files.  I
am sure that most of us who have the diagnostics, such as Johnny
Billquist, can turn his paper-tape copies of the diagnostics into OS/8
files and then ENCODE them for internet e-mail usage.  The authors will
have to figure out the format from the documentation, and then write
local tools to pseudo-load them into their PDP-8 emulator's "memory" and
start them up.  This involves decoding and checking the received files
into the equivalent of certain OS/8 binary formats, such as .SV and .BN,
and then subsequently pseudo-loading the files according to what they
represent.

    Probably the best way is to stick with OS/8 .BN files, because the
underlying format is 3-for-2 packed paper-tape binary image.  This would
be the closest format to desirable because core-image would require
whole pages to be loaded, even if containing junk.  Binary paper-tape
format would allow unneeded locations to remain set to emulator-specific
values.  This would allow an emulator to report an apparent branch to
unreferenced memory for example, which would indicate an error in the
emulator, since MainDEC programs are generally well-behaved.  (Also a
good emulator feature to implement if you want to develop and debug new
PDP-8 programs or changes.)

    Another subject is what devices to emulate.  Beyond the basic
instructions and 32K extended memory, there is the console device 03/04,
and perhaps the line printer, device 66.  It is suggested that the
device 01/02 reader and punch be emulated as files such as READER.BIN
and PUNCH.BIN because if the emulator is good enough to run OS/8 or
P?S/8, then the paper-tape portions become somewhat vestigial.  However,
emulation by file allows for ease in running MainDECs at the early
debugging stages, so perhaps a local utility needed early on is a tool
to take the ENCODEd files, decode them, and "de-OS/8" them into
paper-tape images to become the designated READER.BIN files.

    There needs to be a way to set the simulated front panel switches
beause the diagnostics all use them.

    Additional devices that can be emulated reasonably include the RF08
and or DF32 and the RK8E.  On MS-DOS and other systems where the basic
physical block structure is 512 bytes/sector, the RK8E can be done as a
pre-allocated collection of sectors the size of the physical RK8E disk.
Unfortunately, the overhead of the I/O operation is high for the RK8E
due to the PDP-8 code helping the controller a bit too much.  This
tendancy is furthered in devices like the RX01/02 (or DECmate's RX50)
where the hardware is even cheaper and the software has more work to do.

    A possible alternative to all of this is to emulate the CESI MDC8
SCSI controller.  The software basically sets up an SCSI command, and
then says "you go do that command" to another processor, in this case a
6809 in the "real" MDC8.  Should it include DMA, such as reads or
writes, the 6809 connects to the Omnibus to do it directly.  The command
itself is referenced in PDP-8 memory by the 6809 because the IOT's just
point the 6809 at the SCSI command.

    This is a perfect low-overhead device to emulate.  The actual I/O
overhead past command setup is quite minimal, so no special-purpose
kludges are required.  Handlers exist for OS/8 and P?S/8 for floppies
and fixed (and removable cartridge) disks.  I have even written a
"backbone" system called MENU-8 which preselects which of several
possible operating system images are further up the device, and which to
boot indirectly to.  This is sort of what the PC does on a hard disk
with a partition table.  In theory, you could have multiple systems on a
disk (CP/M-86, UNIX, MS-DOS) and each is bootable under some usage, but
only one "owns" the disk.  I have an arrangement for multiple copies of
P?S/8 and OS/8 to "co-exist" on a large disk in this manner.  All you
need is to emulate an MDC8 and give SCSI commands that address a large
region of a disk.  This could be quite practical on a PC environment,
where it is best that the PDP-8 disk be "separate" from the normal DOS
environment (or UNIX).

    A further benefit of using the MDC8 example, is that the floppy
format is directly supportable by the emulator, as long as you can
read/write PC 5.25" disks.  Many machines "like" this format, so PDP-8's
can boot this floppy directly, and so can the emulator if so
implemented.  This is analogous to the PDP-15 emulator cited above.  The
floppy format is exactly IBM-PC High Density two-sided format EXCEPT for
one change:

The PC format is 15 sectors of 512 bytes, and the PDP-8 format is 26
sectors of 256 bytes.  All other track, etc. considerations are
identical.  This format is readable/writable on a PC with a little
helpout to the hardware.  (You can't do it through the BIOS, but you can
talk to the floppy controller yourself and do it.)  This allows PDP-8
MDC8 users (like me :-)) to interchange PDP-8 programs directly with
emulated PDP-8 w/MDC8 users wherever they may spring up.  Rumor has it
that such a program is being developed for 286 (or better) -based PCs.

    There is also a VAX Fortran-based emulator floating around.  I
wouldn't expect too much performance from it in turns of emulating the
SPEED of an -8, but it is rumored to work.

cjl

Date: Wed, 29 May 91 09:40:47 -0500
From: "Lawrence T. LeMay" <[email-masked]>
To: [email-masked]
Subject: PDP8/E core memory
Cc: [email-masked]

Date: Wed, 29 May 91 09:40:47 -0500
From: "Lawrence T. LeMay" <[email-masked]>
To: [email-masked]
Subject: PDP8/E core memory
Cc: [email-masked]

I have two sets of PDP8/E core memory boards, and i'm trying to
figure out EXACTLY what I have... Perhaps someone here has the
correct manuals and could look these boards up for me...

Set 1:
  board A: 8K XY Driver Board 2074 PCC

  board B: (Core memory board)
           Dec P/N  H212
           Size  8K X 12 (175)

  board C: G104C Sense Inhibit 

Set 2:
  board D: G227C

  board E: G619A Planar Stack Board (Electronic Memories Inc, Core memory)
           (Dec H220)

  board F: G111C Sense Inhibit

I'm assuming that Set 1 is 8K because of board A, but I'm not sure... And
set 2 I have no idea, but could be the same as set 1 (but then, why are
the board numbers all different?).

BTW, is it possible to get these boards tested/repaired?? I thought I
heard something about a year ago about someone who was repairing PDP8
memory boards... Ah well, wishfull thinking no doubt.

-Larry LeMay
 [email-masked]

Date: Wed, 29 May 91 11:59:26 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: 8/e memories

Date: Wed, 29 May 91 11:59:26 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: 8/e memories

From: Charles Lasner <[email-masked]>
To: "Lawrence T. LeMay" <[email-masked]>
Subject: Re: PDP8/E core memory
In-Reply-To: Your message of Wed, 29 May 91 09:40:47 -0500

    You have a 4K and an 8K set of -8/e memory boards in that order.
The 8K designation is misleading, but what they mean is that the board
etch is theoretically interchangeable, BUT not really when populated
with different or more/less stuff.  Also the 4K board for use with the
8K version became obsoleted in favor of the board your 8k set has in it.

    The deal is that the about 1000 earliest 8K sets tried to carry out
the premise of the etch you mentioned, and those early card sets were
very finicky.  All 4K sets have to tuned *AS A SET* as it is, but the 8K
versions were more critical still.  One advantage of the 8K newer cards
is that each card is adjusted to a spec, not a local set, so 8K boards
should be totally interchangeable.

    On an irregular basis, I repair omnibus boards, including -8/e
memory cards.  When I am done with them, they are literally better than
new.  The reason is that late in the -8/e era came out the VT8E.  If you
patch the diagnostic for -8/e memory checkerboard for example to NOT do
CAF instructions (two locations), and manually start the program, the
diagnostic runs just fine on virtually any 8K stack, or whatever.  The
manual start is just as good as the NOP'ed instructions because you use
a manual clear.

    Now here's where it gets interesting:  DEC's spec for the final
adjustment of the sense amp timing is to specify that therre are
generally 4-5 settings of the tap switch that work without causing
errors while running this program.  Use the "centermost" of them.  Well,
what if there are FOUR settings, not five, which do you use?  Also, the
center one may not be the best after all.  I toggle in a short VT8E
program which starts it up in graphics mode, the worst case DMA mode,
with it using a suspect memory as the designated buffer.  (You can make
the whole program self-relocate and then it's arbitrary.)

    When the suspect memory is subjected to the tighter timing of a fast
series of bus cycles "attacking" portions of the memory, it is getting a
worse test than the checkerboard program!  In core memory, reads are
worse than writes.  The way it works is that the read is destructive and
yields what the immediate FORMER contents WAS.  Then, the contents have
to be written back.  All of this has to be done in one DMA cycle!

    Technically, there is one mode faster than this to "punish" the
memory, namely to make it execute WITHOUT DMA a series of one-cycle
jumps and operates, essentially like the LEAPFROG program of the LINC
from years ago.  In this mode, all instructions are 1.2, whereas longer
instructions are a mix of 1.2 and 1.4, and the memory doesn't
participate in the 1.4-long cycle unless it is a TAD or AND.  (If a DCA,
it merely has to write, but the others have to read, and then have lots
of time to restore the aftermath of the destructive read.  ISZ is a
strange one, the destructive read is followed by an increment from the
CPU, and then the updated contents are written back in the next cycle.

    The point is that only operates and JMP are truly 1.2 per cycle.
Unfortunately, there are no programs for the -8 that do this and check
for reliable memory contents afterwrds.  My patched checkerboard program
is therefor subjected to the next worst thing: a series of 64 DMA
cycles, which are 1.4 each, and otherwise do the same thing, namely read
sequential areas of memory, and each has to "fixup" after the
destructive read.  If it doesn't get done in time, then the
checkerboard's testing code will pick up the discrepancy.  So, this way,
it narrows down the acceptable settings to 1-3 notches, instead of 5.

    Also, if faced with an even choice count, I will always choose the
earlier strobe setting as this seems to be slightly less noise-prone,
although most seem to get 3 options thus avoiding the quandry.

    I may be persuaded to fix some "outside" boards, but I've never done
this;  I'm not in "the business" :-).  I suppose some "hobbyist rate"
can be determined for my time (clearly much less than my "consulting
rate" is :-).

cjl (have oscilloscope, WON'T travel, with apologies to Paladin...)

Date: Wed, 29 May 91 14:36:14 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: reply to GRG

Date: Wed, 29 May 91 14:36:14 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: reply to GRG

    Glad my ideas helped this potential emulator author.

    A few words about the technique of emulating the hardware of the
RK8E:

There is some overhead in what he is attempting to do, because the RK8E
makes the PDP-8 participate in the I/O controlling.  The code is NOT
merely a setup of a disk read/write and just wait for it, rather there
are kludgy things like checking for track overflow and setting/not
setting a "don't check id's" bit, etc. between individual record
transfers.  Also, since this is a one-at-a-time device, there is
multiple occurrences of this overhead.  

    The point I was trying to make is that only certain pragmatic
occurrences of the handler's IOT's were allowed on the PDP-15-based
DECtape emulation.  These were in "standard" places like P?S/8's system
handler, and OS/8's system and non-system handlers.  Once detected, the
emulator abandonded the emulation, and examined the call at a higher
level, namely it understood the system call and attendent arguments.
The requested operation was done totally with "real" I/O to carry the
whole operation out.  PDP-8 emulation continues by returning to past the
arguments as if the entire call were done by -8-code.  This avoids ALL
of that overhead!

    Using the MDC8 as an alternative, you don't have to deal with any
special pragmatic cases, because there is the same level of emulation,
namely that the PDP-8 code is processing the arguments of the call, and
setting up in PDP-8 memory an image of an SCSI command.  Then, the IOT's
happen which merely point the "hardware" at the command.  The -8 expects
its on-board controller to do all the work, while it merely periodically
checks a done flag or gets interrupted EVENTUALLY after the fact.  This
is ideal for an emulator, because you just emulate the SCSI command, and
then restart the -8 after the fact.

    For the benefits of interrupts, the command getting actually
executed on the physical bus can restart the emulation process, and when
the host machine gets interrupted for actual I/O completion, the
emulator can make the done flag emulation skip when necessary.  This
allows the partial overlap desired should interrupt-driven PDP-8 I/O be
desired, yet minimizing the usual non-interrupt I/O emulation overhead.

    Since every SCSI command is a complete entity in andd of itself,
every call translates into just one SCSI command, so effectively you get
the emulation speed of the PDP-15/DECtape example, without having to
have the special-purpose pragmatisms of "knowing" the inner-workings of
handlers and applications and diagnostic programs, which incidentally
are CURRENTLY being developed.  (The CESI product is not "dead" in that
there are some currently supported systems that use it.  I write
diagnostics for the beast, etc., and am still quite active in this area.
A properly configured emulator could run MDC8 diagnostics :-)

    PDP-8 quirks.

    GRG is quite correct, there is a strange bug of the original PDP-8
and LINC-8 with extended memory.  If a CDF to a non-existant field is
attempted, then the next instruction is used as a pointer address to
where another instruction is, which is then executed.  Assuming the
inadvertantly pointed-to instruction isn't a JMP or JMS or itself skips,
then the PC is incremented to skip around the next instruction past the
bad CDF!

    I have a memory test routine used in P?S/8 to find out the machine's
core size which uses this fact to detect memory size on PDP-8's while
also doing other things for other model's quirks.  It is partially based
on the routine found in the PS/8 and OS/8 technical reference manuals,
which is DEFECTIVE!  This is responsible for bugs when running OS/8 on
an -8/l specifically.  Otherwise, that code works on most models;  my
code is size-optimized, but uses most of the ideas in the OS/8 example,
and an additional check that an -8/l can't screw up.  The P?S/8 checking
code is based on the fact that field zero exists, and ALL ELSE is
optional, whereas OS/8 also needs field one (perhaps two also) to exist
as well.  The -8/l bug is that there is an -8/l quirk that CDF to a
non-existant field is a NOP, NOT a CDF to another field that does exist
somewhere else, or addresses fresh air.  This is what most of the other
models do.  Since the -8/l treats it as a NOP, then the LAST CDF is
still in effect.

    Most -8/ls are 8K, so the last "legal" CDF is CDF 10.  Then they
attempt CDF 20.  That becomes a NOP here, so attempts to access memory
"work" in that they find addressable memory, and it isn't in field zero
(a check that exists because of the PDP-8 quirk mentioned earlier; they
force an -8 to essentially store over field zero location zero if a
"bad" CDF happens on an -8, so they check for inadvertent destruction of
00000.) The problem is that this is FIELD ONE's test location, NOT field
two as expected, so the routine is "fooled" into believing that field
two exists, and by iteration, fields 3-7 as well :-).  So, this stupid
code reports a 32K 8/l instead of 8K!  (Real 4K -8/l's don't have this
problem, but 8K and 12K -8/l's do.) The P?S/8 solution is to ALWAYS do
CDF 00 BEFORE attempting the next test field.  This way, field ZERO's
test location will get zapped, and that will be picked up by the PDP-8
quirk test code.  The sequence is CDF 0 then CDF testfield, not CDF 10,
CDF 20, CDF 30, etc., as in the defective OS/8 example.  I believe this
invalid code is still in programs like PAL8, etc., so beware of -8/l
usage!

    I would recommend implementing the -8/e instruction set for an
emulator, and forget about other quirks.  The memory check would be that
non-existent memory just can't be stored into and read back with the
same value.  This is the gist of the main test loop typically anyway.
Then, a feature can be added to the emulator we would really like,
namely that execution of SUPERSET instructions like BSW and CAF can be
trapped back to the emulation level.  This will allow detection of
instructions in OS/8 programs that prevent their use on the -8, etc.
P?S/8 is carefully scrutinized for this, as I run it on straight -8s and
my own 4K LINC-8.  OS/8 used to be as good, but over the years has
gotten very sloppy, and was subjected to "management tyranny"
specifically over the use of OS/8 on "pre-Omnibus machines" as they
called it when they dropped support.  All of this turmoil over avoiding
the use of a small few instructions.  The easy way to prevent this could
have merely insists that all programs be assembleable using PAL8 both
with and without a header file containing the EXPUNGE pseudo-op and a
suitably re-defined symbol table containing only PDP-8-worthy symbols,
no extensions.  The P?S/8 PAL assembler source itself literally contains
those usages in the beginning of the source.  The binary output of the
assembly of P?S PAL does include superset symbols like BSW for the
benefit of users of PAL, but it makes no internal dependency on them for
subsequent execution.  An emulator capable of (optionally) trapping
superset instructions specified in various lists would allow us to find
these past problems and correct them.  Usually, they can be patched out
using short sequences;  BSW is always replaceable with three RTL or RTR
instructions depending on the author's intent, or somesuch.  I
personally have used things like JMS I [ROL6] in my code, so it calls a
subroutine containing RTL;RTL;RTL.  If the program discovers it is
running on an -8/e or better, then it patches itself with BSW over all
of the JMS's for better execution speed maintaining compatibility.
Using techniques like this, and just plain being careful, has led to why
KERMIT-12 will run on any model, from PDP-8 through DECmate III+, even
though the underlying operating system is an OS/8 family member that can
only run on a few models.  These few pesky instructions are all that
prevents more universal application.  I am committed to OS/8 Version 5,
which, like P?S/8 DOES CURRENTLY, WILL RUN on the entire hardware family
of PDP-8 (which excludes the -8/s and -5 as most of you already know :-(
:-)

For myself, I would like to see an emulator also have a serial port to
the outside world, so KERMIT-12 could be run on the emulator :-).

cjl