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

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 at 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.