dumping Western Digital Microms (PDP-11, WD16, Pascal Microengine)

[Eric Smith]

The DEC LSI-11, Western Digital WD16 (as used in the Alpha Micro
AM100), and Western Digital Pascal Microengine use variations of the
same chipset, called CP1600 for the LSI-11 and WD16, and WD9000 for
the Pacal Microengine.

The chipset consists of a control chip, a data path chip, and two to
four microcode ROMs, of 512 words of 22 bits each, known as
"Microms".

I built an apparatus on a breadboard to dump the contents of Microms,
using a PIC and a quad gate driver to produce the four-phase 12V
clock, three 74HCT163 four-bit counters and two 74HCT245 buffers to
drive the address onto the microinstruction bus, and a 74HCT4050 and
74HCT04 to level shift the MOS phase 2 clock back to 5V and invert it,
to enable the 74HCT245 buffers.

Photos:
    https://www.flickr.com/photos/22368471@N04/albums/72157662054690240

The apparatus cycles through the entire 2 kibiword address space
continuously. An HP 16701A logic analyzer with 16557D state/timing
card is attached to capture the addresses and data.

Because the microinstruction bus is active low, the addresses are
driven in reverse sequence, and the microinstructions captured on the
logic analyzer are inverted.

So far I have dumped the following LSI-11 Microms:

3010D, DEC P/N 23-001B5 (also designated CP1631-10) - addr 0x000-0x1ff
3007D, DEC P/N 23-002B5 (also designated CP1631-07) - addr 0x200-0x3ff

So far I have dumped the following Pascal Microengine Microms:

WD2171-10 - addr 0x000-0x1ff
WD2171-12 - addr 0x200-0x3ff
WD2171-13 - addr 0x400-0x5ff

WD2171-14 - addr 0x000-0x1ff
WD2171-15 - addr 0x200-0x3ff
WD2171-17 - addr 0x400-0x5ff
WD2171-18 - addr 0x400-0x5ff

There exists at least one other Pascal Microengine Microm which I
don't have, the WD2171-16. I expect that it probably occupies addr
0x400-0x5ff.

I have not yet dumped the WD16 Microms as I do not have an AM100 CPU
board at hand.

My next challenge is exporting the data from the 16701A to anything
else. The 16701A used to work fine on my Ethernet, but for mysterious
reasons it now claims that the network can't be accessed, despite that
plugging a laptop into the same Ethernet cable works fine.

I'll need to write a small Python script to post-process the output,
for use with my disassembler (also in Python).

Note that dumping the Microm contents is only part of the problem; the
control chip also contains PLAs that can force microcode jumps under
various conditions despite there being no corresponding jump
instruction in the Microms. This is used for macroinstruction decode,
and possibly for other purposes.