🚀 go-pugleaf

In article <1992Oct5.170334.12874@tc.cornell.edu> mdw@theory.TC.Cornell.EDU (Matt Welsh) writes:
>I know this sounds crazy, but I'm wondering if someone out there
>has an unwanted/unloved machine in the PDP-8 line that they'd like
>to give a happy home (namely, to me), or sell. There must be one
>out there, somewhere, sitting in someone's machine room or attic,
>collecting dust-- if so, send me email and I'll see what I can do
>about getting it off of your hands. :) The actual model probably
>isn't important-- I'm just looking for one of these machines to
>bang around on for a while.
>
>Thanks for any help.
>
>mdw
>
>-- 
>Matt Welsh    mdw@tc.cornell.edu        +1 607 253 2737
>Systems Programmer, Cornell Theory Center
>  "Yow! Up ahead! It's a DONUT HUT!!"

For any "serious" PDP-8 enthusiast, there is quite a lot of help out there,
and many people with long-term commitments to the architecture, which is
still actively being developed today by hobbyists, and a smattering of still
existing applications, etc.

If Matt's request is a valid one, there is more than enough help available.
However, a common characteristic of the group of -8 enthusiasts is: please
only ask assistance if you have some expectations of commitment yourself.  Idle
curiosity is not welcome if effort is to be spent.  Idle curiousity per se is
not unwelcome, however it is directed to various FAQ documents (some of which
are being prepared currently).  Some of these are available via anonymous FTP
from ftp.telebit.com in the /pub/pdp8 area.

If after availing one's self of all of the relevant info, and you still want
to acquire enough of a machine to be useful towards some endeavor, even if
it's nothing more than studying the architecture, then requests such as this
are welcome.  However, if the request is really just an attempt to get the
ability to program the architecture on some basis, and not to get a hands-on
experience with the machine, the use of a simulator is recommended.  There are
several CPU-only simulators available, and some with varying levels of
peripheral support.  There are two ongoing projects (for PC's and MAC's) that
when available will be capable of running PDP-8 systems software from media
that can also boot up on suitably configured *real* PDP-8's.  This means that
there is direct media interchange between the simulated machine and the real
machine.  Real machines in turn, if suitably configured can exchange media
between other real machines and other simulators.  (The PC-based simulator
runs with media impossible to read on the MAC version, etc.)

There is an additional problem peculiar to PDP-8's and to a lesser extent
PDP-11's.  Since the machines are modular, a PDP-8 is what some people believe
they are discussing, when in fact they are merely talking about a CPU and
memory and a buss without any peripherals.  Some of these machines were even
sold sans peripherals as they were imbedded in some OEM systems with custom
peripherals designed by the OEM, not DEC.  For example, thousands of PDP-8/M
machines were once used by Burger King as point-of-sale terminal systems.
Each machine supported 1-3 special-purpose terminals made by AMF for Burger
King, and a special communications port used for central warehouse inventory
control after hours, etc.  If any of these machines have become available to
the used market, clearly the Burger King cards are of little use to anyone
else.  These machines even lack a normal device 03/04 console interface, yet
to the uninitiated, these are PDP-8's as opposed to PDP-8 CPU-and-memory-only.

The usual definition of a PDP-8 as it applies to this group is a machine with
a minimal configuration or better, which is capable of running the existing
software.  Clearly a machine such as described above is less than that.  In
fact, a simulator is a far better machine in most ways.

However, any CPU can, with serious effort applied, be turned into a "real"
machine by adding suitable peripherals.  This can take the form of actual
terminals and other interfaces to other devices, or can be interfaces to
other support machines.

For example, a PDP-8/e with 12K and two serial ports can be used with a PC
or other machine, assuming a custom support program is written on both ends.
The expertise to do this is available in the community of PDP-8 enthusiasts
in case anyone is interested.  All that's required is that a program be written
that supports any form of "glass TTY:" relative to the I/O associated with
one of the serial ports, i.e., it is a terminal emulator, preferably in the
VT-100 family, and also supports block transfers via the other port.  The
baud rate of the block device support can be made fairly high to allow a
decent rate of performance, such as 38,400 baud or more.  OS/8 can be
implemented in this little hardware, and P?S/8 can be implemented in as little
as 8K.  (Configurations above 4K require extended memory control module as
well as the other memory, which comes in 4K, 8K, 16K and 32K boards from
various vendors, etc.)

The serial port can be eliminated and replaced with a parallel port if the
serving machine can do bi-directional parallel transfers.  (There has been
some discussion about possibly modifying a PC standard parallel card to
allow this; PS/2 models allegedly already support this.)  This would allow
an even faster block device, etc.  If an additional serial port is added to
the 8/e, the system can also support Kermit-12, etc.

If an RX01 or 02 and RX8E is added, then the serving machine can be eliminated,
although it is apparent that the serving machine may offer a better overall
device to the 8/e than does the limited RX01/02, but the alternative is for
older clunkier peripherals, since most of the PDP-8/e's haven't benefited from
peripheral technology improvement available on virtually every machine today.
This isn't a reflection on the -8 whatsoever, just that you have to have new
interfaces to talk to new technology, etc.  Thus, unless you are committed to
supporting a large, heavy, hot, finicky older disk, or use a low-performance
small capacity disk like an RX, an all-original PDP-8's peripherals may do
you in.

This is why some people are suggesting embedded systems such as 80186 minimal
machines that control IDE disks with interfaces to the -8/e or something along
those lines.  My own 8/e-8/a has a 6809-based controller that talks to an
SCSI buss and peripherals using a DMA channel to the -8.  Using this kind of
solution allows for a high-performance low-cost peripheral, and allows the
entire machine other than the terminal to be inside the table-top case of the
basic PDP-8/e.  As for the terminal, almost anything will work; my novel
solution to this problem is that I (occasionally) use a DECmate III running
Kermit-12 as the console terminal of my 8/e system :-).

The fledgling PDP-8 archive on ftp.telebit.com will grow and allow free 
access to much PDP-8 software to allow anyone to view typical code that
runs on the machine, and to allow anyone with the basics to enhance their
own library, etc.

Anyone who wishes assistance in this sort of thing is invited to post to
the pdp8-lover's mailing list: pdp8-lovers@ai.mit.edu.  Send e-mail to
pdp8-lovers-request@ai.mit.edu to subscribe, etc.

cjl