Dumping Intel 43201 microcode ROM

[Eric Smith]

Previously I posted photos of a Zilog Z8-02 MPD running a copy of the
Z8671 BASIC subset ROM code on a breadboard. The Z8-02 was packaged in
a ceramic leadless QUIP package, and I have only one good QUIP socket,
so I made an adapter that the QUIP socket can plug into, which then
has a very wide 64-DIP footprint for ease of prototyping.  The bottom
of the adapter has footprints for surface-mount decopling capacitors
very close to all of the QUIP socket pins; the SMT capacitors are
installed depending on the specifc chip for which the adapter is
configured.

Although the Z8-02 is totally unrelated to the Intel iAPX 432, this
served as validation that I can make a usable QUIP socket adapter.
The iAPX 432 General Data Processor consists of two chips, the 43201
instruction unit and the 43202 execution unit, both packaged in the
ceramic leadless QUIP. Since I only have one QUIP socket, I plan to
make sockets using pogo pins and a machined or 3d-printed frame. For
now, I have just wired up the 43201 on a breadboard in microcode ROM
dump mode, and captured the ROM contents using a logic analyzer.
Photos:

    https://www.flickr.com/photos/22368471@N04/sets/72157653865063443

The 43201 has 4K words of 16 bits of vertical microcode ROM, however
the top-level control is not done by the microcode ROM, but rather by
a bunch of PLAs and hardwired logic. Many of the simpler 432
instructions are executed without use of the microcode ROM at all.
Microcode routines are invoked in response to specific conditions or
more complex instructions, and the routine entry addresses come from
those PLAs, so it is fairly difficult to interpret the contents of the
microcode ROM.  While I can identify many of the entry points, I only
have been able to determine what a few of them actually do, such as a
few of the floating point instructions, and one of the simplest object
instructions. However, eventually I hope that study of the ROM dump
will shed some light on a few dark corners of the architecture left
unspecified by the otherwise fairly comprehensive iAPX 432 General
Data Processor Architecture Reference Manual.

I have a design in progress for an iAPX 432 test system using a
MicroZed board. This is based on the Xilinx Zynq, which has ARM
Cortex-A9 processor hard cores as well as a substantial amount of FPGA
fabric. The MicroZed will plug into my board, which will have
level-shifters and such, as well as the QUIP sockets for the 43201 and
43202. The FPGA will be programmed to act as a memory controller for
the 432 packet bus, as well as a logic analyzer for both that bus and
the interchip bus used for microinstructions and status.

There is not known to be any surviving coherent release of iAPX 432
software, so I'm developing my own software from scratch. It is a
large task, because the iAPX 432 architecture is completely
object-oriented (implemented by the microcode and hardware), and there
have to be several dozen properly formed system objects in memory just
to execute the simplest program.

I expect that my first attempts to get the iAPX 432 to execute a code
image I have generated will result in failure. The 432 architecture
provides for a lot of software fault recovery, but if the system
objects are not properly set up for the fault condition, it will
assert the FATAL pin and halt. (This is the same concept as a double
bus fault on more conventional processors.)  By studying the bus
activity leading up to the halt, I hope to be able to determine what
problem with the memory image led to the halt.