[Simh] The Missing PDP-8s

[Warren Young]

On Tue, Aug 13, 2019 at 10:18 AM Bob Supnik <bob at supnik.org> wrote:

> As was pointed out, the existing PDP-8 CPU is basically a PDP-8/E or
> -8/A.


It's a mongrel. SIMH's FPP (floating point processor) peripheral emulates
the version for the 8/a, but memory is limited to 32 kWords as in all
models before the 8/a, which added a mode to allow 128 kWords of core or
semiconductor RAM. The 32 kWord limit is hard-coded in pdp8_defs.h as
MAXMEMSIZE. I'd expect at least that limit to be lifted if you're going to
call the SIMH simulator a PDP-8/a simulator.

I think it'd be a lot of work to give the current CPU emulator
model-specific modes down to a level necessary to get full branch coverage
in software that probes for model quirks and changes behavior accordingly.
I'm personally aware of multiple pieces of commonly-available PDP-8
software that does this, and there was doubtless a lot more that I'm not
aware of, because the economic lifetime of the PDP-8 was roughly 2 decades
long! Closer to a quarter century, if you count the PDP-5.

it's clear that the DECtape controllers should
> have been abstracted to a library ten years ago, but doing so would be a
> major PITA, now that there are six (at least) distinct implementations
> (PDP1, PDP18b, PDP11, PDP8 TC, PDP8 TD, KA10).


I think it'd be more work than it's worth to make a single abstraction
layer; I think you'd want at least two versions.

The reason there are two DECtape controllers in the current PDP-8 simulator
is that one is block-by-block (TC) and the other is line-by-line (TD),
where "line" is 3 bits! That means there is a device driver in TD-aware
PDP-8 software that has to assemble incoming data 3 bits at a time!

We have a mode in the PiDP-8/I software that lets us build the OS/8 disk
packs in a way that works with either driver. The OS/8 TD8K driver for the
TD8E DECtape is so-named because it requires an 8 kWord PDP-8 because the
code complexity in the driver requires that it be split over two "fields"
(4 kWords) of core, which is unusual for an OS/8 device driver.

We have this mode so you can use the PiDP-8/I software stack to build disk
images for real hardware, where switching modes is much more consequential
than simply changing a "C" to a "D" in a SIMH boot script.

This feature of the PiDP-8/I software is scriptable, so that for any
question OS/8's "BUILD" program can ask, you can script an answer to it to
get a new custom OS/8 medium build:

    https://tangentsoft.com/pidp8i/doc/trunk/doc/os8-run.md
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20190813/beb769de/attachment.html>