🚀 go-pugleaf

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