🚀 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

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

What sounded crazier, is that the subject line could have been interpreted
as ....

wanted:  NEVER used pdp-8 ?


ask around a few government departments for those, Id say !

leon

In article <1992Oct5.234213.4863@news.columbia.edu>, lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> 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,
> 
> For any "serious" PDP-8 enthusiast, there is quite a lot of help out there,
> 
> ...  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.

I am quite sure that at one time there was a microprocessor that fully
emulated the PDP-8.  Is there still a supply of these chips?

In article <1992Oct6.104738.21099@cbnewsl.cb.att.com> rl@cbnewsl.cb.att.com (roger.h.levy) writes:
>
>I am quite sure that at one time there was a microprocessor that fully
>emulated the PDP-8.  Is there still a supply of these chips?

Several people have been asking for these chips.  The easiest way to get them
is to get a DECmate.  The CPU is usually socketed, except for the newest
models such as DECmate III and III+.

The 6100 is a compatible PDP-8 CPU-on-a-chip.  You need to provide your own
interfaces and extended memory control.  A late addition to the chip set was
a mostly compatible extended memory chip (medic) but it was rarely used.  The
6100 is found in the VT-78 and a few non-DEC machines such as the PCM-12 and
Intercept series.  These are 2/5 the speed of an 8/e, although DEC chose to 
use chips only about 60% of that speed in the VT-78.  Otherwise the VT-78
is totally compatible with the 8/e configured for the same peripherals, which
is a generous set of interfaces compared to an actual 8/e.  Most notably
absent is the ability to have EAE and no DMA interface was attempted in the
VT-78, although in theory this can be done.

there is a 6101 (PIE) chip that interfaces to the 6100, but it is not to be
used where software compatibility with any existing -8 peripherals is intended.

The 6120 is used in DECmates, and is a second-generation chip.  The overall
speed is comparable to an 8/e, and a few instructions are a little slower, but
some are actually slightly faster.  EAE isn't implemented, but may be possible.
The hooks for it seem to be present.  DECmates don't implement it though, nor
do they implement a buss structure :-(.  There are dedicated slots for certain
peripherals, such as a DMA color graphics board, hard-disk or 8" floppies,
and an "auxiliary" processor board which contains either a Z80 and 64K or an
8086 with 256K or 512K and a Z80 which shares 64K of the memory space with the
8086.  These boards can run CP/M-80 and the XPU can also run a generic MS-DOS.

The 6120 supports 32K memory directly, thus there is no medic chip.  There is
a standard interface chip, 6121, but it's only *almost* compatible with the
traditional interfaces of the PDP-8, and the reason that there is a software
problem with the machine is that the PDP-8 software depends on the interface
being *exactly* compatible, not merely vaguely compatible.  The result is the
buggy and emasculated OS/278 as compared to the original OS/8.  Some of the
problems are expedient in nature, some are caused by brain-dead and conflicting
conventions imposed by the system ROMs of the machine (not applicable to 
DECmate I which is more compatible on this point), and the main cause is the
problematic 6121 chip which can't be fixed.

I have, along with the help of others, prepared a list of steps to take to
"repair" OS/278, although some of the repair depends on features not yet
documented due to past stonewalling by (former) DEC managers.  Today's
DEC is more willing to reveal what was done a few years ago, but a lot of
the info is scattered, or only known to exist in the hands of people who never
had a long-term committment to 12-bit machines.  We thank the few of these
people who have assisted in certain areas, but it's up to the user community
to correct the problems of the (relatively recent) past.  I will be posting
a list of needed files which ought to be available in source form, which
aren't.  The tide *is* turning though, although some of it is being acquired
the hard way - disassembling the binaries.

I have already disassembled the ROMs of the DECmate II (four revisions) and
DECmate III (there appears to be only one revision) and have recently acquired
a DECmate III+ (likely only one revision here as well).  In the process, I
acquired enough information to determine the organization of the "slushware"
that controls the machine, as read in by the ROM-based code, etc.  I am about
60% done with disassembly of that code as well.  I have in the process located
where the disk boot and partitioning info are held on the hard disk, as well 
as figured out how to read and write it.  The slushware is taking a long time
in part because it's fairly long, and partly because it's software "talking"
to software, while the ROM is software talking to hardware, and thus more
constrained in purpose.

Much of the supporting information has been obtained from helpful users who
are hardware hackers.  They have noticed where DEC uses standard parts from
other companies, and provided copies of those companies' spec sheets for the
components, such as the SMC Video Interface chips as used in the VT-220 and
DECmate II, III, III+, and the 6120 and 6121 as used in all DECmates which
is made by Harris Semiconductor.  Harris has extensive documentation that only
presumes a basic understanding of the PDP-8/e, and a little knowledge gained
from earlier Harris and Intersil spec sheets for the 6100 series.

Using these spec sheets, and writing a half-dozen utility programs, I was able
to figure out how to turn MS-DOS absolute binary .BIN files read from the
ROMs into an OS/8 .SV file which in turn was then disassembled.  The original
files were created using a PC-based PROM blaster to read the chips into the
8-bit binary files, then converted to .BOO files with the MSBMKB program.
Then they were sent to the PDP-8 using MS-KERMIT and KERMIT-12.  At the
PDP-8 end DEBOO.SV was used to create a packed binary file of the ROMs.

The resulting files are to be treated as unusual files, because the bit
orientation of the binary doesn't match any PDP-8 conventions.  The
ability to unpack the files as OS/8 is fairly standard, but the contents
have to be loaded according to arbitrary conventions.  Moreover, the DECmate II
version is contained in a set of three ROMs, each of which contains the load
information for a different set of eight bits, thus the loading utility has
to incorporate three different storing routines for each of the ROM files.
The DECmate III and III+ ROMs are loaded in an entirely different format each
entirely contained in one ROM which switches loading format at the midpoint.
When any one set of three (or one in the III series cases) is loaded, the
resultant is exactly one PDP-8 field or 4096 words.  This is then the code to
be disassembled from the 4K .SV file.  When I start the III+ disassembly this
will be the sixth 4K disassembly of this family of code I have accomplished.
(Fortunately, they are related, so there is a good probability of picking out
"familiar" sections of code here and there, so it's not the same as disassembly
of 24K of unique code :-).)

The sources recreated from these binaries has allowed me to follow the flow
and format of the data loaded in from tracks 0, 78, 79, or the equivalent
hard disk sectors of the slushware into control panel (CP) memory.  This in
turn allowed me to write a utility to read the data into memory as it appears
in the CP memory in CP fields 0 and 1 (where the CP ROM loads it).  The
resulting image file is what I am presently disassembling, etc. to become a
fully documented source file of the slushware.

The 6100 and 6120 both support this slushware concept, meaning there is
code outside of the PDP-8's normal addressing space which is entered only
via a special form of CP-oriented interrupt.  It has higher priority than
normal interrupts or non-interruptible code, and runs even if the machine
is halted.  (On the 6120, normal memory HLT instructions cause a CP interrupt
and in CP memory HLT is a NOP.  There is a status register to determine that
the reason for interrupt to CP memory was in fact a HLT instruction.  This
allows a no-PDP-8-memory invisible debugger to exist.  There is one for the
DECmates II III III+ called CPODT (aka CPUODT) that is pretty good.  If you
run it first from OS/278, any other utility can always be broken out of, 
because CPODT has access to all operations as part of CP memory.  Needless
to say, CPODT is on my list of programs to acquire in accurate source form
or disassemble.  (I have disassembled a small portion of CPODT; just enough
to confirm that it loads over certain portions of the slushware in ways I
had suspected, but not more than a few percent of it.)

Once all issues such as this are resolved, it will be possible to completely
"fix" OS/278, and to create a unified OS/8 family system, tentatively dubbed
OS/8 V5.  It requires small modifications to *all* programs, but the result is
one system that runs on all models, just as P?S/8 currently (almost) does.
(P?S/8 has already implemented the equivalent to the main problem facing
OS/8 regarding the keyboard, but there is a wishlist for P?S/8 as well.  Some
of this may be resolved by removing known bugs in the DECmate slushware, 
although it's likely that system software as well as slushware changes will
be necessary for total compatibility in both OS/8 family, and P?S/8 systems on
all of the models of the "family of 8".)  In subsequent postings, I will 
outline the 6121 incompatibility issue central to the keyboard problem and
some tentative solutions, etc.

Does anyone else know where these chips can be purchased?  The useful chips
include 6120, 6121, 6100, 6101, 6102, 6103, and 6402 (UART) models from
Harris and Intersil.  Spec sheets can likely be provided by readers of the
newsgroup.

Perhaps we can hear from some of the groups currently implementing PDP-8
chip machines, etc.

cjl

In article <1992Oct6.104738.21099@cbnewsl.cb.att.com> rl@cbnewsl.cb.att.com (roger.h.levy) writes:
> 
> I am quite sure that at one time there was a microprocessor that fully
> emulated the PDP-8.  Is there still a supply of these chips?

You are referring to the Intersil IM6100 processor "family".  5 to 10
volt CMOS, various speed grades from 4 to 8 MHz.  Originally appeared
about 1976; Harris second-sourced them and also came out with an
improved version, the 6120 (co-designed with DEC? ... cl will elaborate :-)

I rather doubt that either company makes these any more ... 'tis a shame.

I have a few myself, along with the companion chips: the 6102 MMU,
timer and DMA combo, the 6101 PIE (peripheral interface element: kind
of port decoder/timing controller), and some 6402 CMOS UARTs.  Sorry,
not for sale!  These'll either get built into my home-brew PDP8 project
that I started in 1977 (so it's been a long time coming, what about
that garage you promised yourself you'd clean out? sheesh!), or held
for their antique value.  When PDP8 architecture comes back into vogue,
and everyone wants one, I'll be able to sell these things and retire
comfortably.

--
"The path of my life is strewn with cowpats from the devils' own herd."
                                          -- Edmund Blackadder II
bmw@isgtec.com   [ ...!uunet.ca!isgtec!bmw ]  Bruce Walker