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

Eric Smith spacewar at gmail.com
Thu Dec 24 01:38:54 CST 2015

On Mon, Dec 21, 2015 at 2:26 AM, Eric Smith <spacewar at gmail.com> wrote:
> I built an apparatus on a breadboard to dump the contents of
[Western Digital]
> Microms,
[from the LSI-11, WD16, and WD9000 Pascal Microengine chipsets]

I managed to get the state analysis data files exported as CSV and
compressed to fit on a floppy, so I finally got them to my PC. Since
the dumping apparatus cycles through the 2K address range
continuously, and I used the full 1M sample buffer of the acquistion
card, I have over 500 copies of each location. My Python script
reported that five of the nine Microms I read had inconsistent read
results for many addresses. Usually each address with problems only
reported two or three different contents. Sometimes the (wrong)
contents were 0, or were the value of the previous word (as if the
Microm didn't accept the most recent address).  I changed from a 2 MHz
symmetric four-phase clock to a 1 MHz asymmetric, giving more time to
all phases but particularly to phase 1 and 2, and to the phase-1-to-2
and phase-2-to-3 delays, but it didn't help.  With the logic
analyzer's timing analysis, I discovered that there were four to eight
nanosecond glitches on the phase 1 clock while phase 2 is active. Even
more surprising, the phase 1 glitch was present on the CMOS phase 1
clock from the PIC. When the glitch occurs, the microinstruction bus
value changes, even though at that time the 74HCT245s are actively
driving it from my counter. I don't think the MICROM has strong enough
buffers to overdrive the 74HCT245.

After a lot of head scratching and consulting with a friend, I
concluded that it is probably due to ground bounce when the 74HCT245s
are enabled. The two together are driving 11 lines with about 50 pF
load on each line, so that could require quite a transient on the
supply and ground to the 74HCT245s.

I beefed up the supply and ground wiring to the 74HCT245s, added more
0.1uF bypass capacitors closer to the relevant pins, and in addition
to the four 10uF aluminum electrolytic bulk bypass capacitors I had
previously, added about ten 10uF tantalum capacitors.

I was pleasantly surprised that after doing all that, when I read all
nine Microms again, they all read consistently. The four that read
consistently before do match the new dumps. Now I think I've got good
data from all nine parts.

In the future it would be nice to dump the KEV11-A (LSI-11 EIS/FIS)
Microm, the KEV11-C (LSI-11 CIS or DIS) Microms, and the Alpha Micro
AM100 (WD16) Microms, but I don't presently have any of those.

I'm working on a microcode disassembler in Python, but it's not ready yet.

There is still the problem that we need to optically extract the PLA
contents from the control chips, since that is different between the
LSI-11, Pascal Microengine, and AM100 (WD16). Without that, it won't
be possible to fully understand the microcode control flow, because
those PLAs can cause changes in flow that aren't represented by jump
or return instructions in the microcode ROMs.


More information about the cctalk mailing list