Dumping Intel 43201 microcode ROM

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