That's pretty astonishing; I've heard of PROMs dropping bits over time, but I'm a bit amazed to hear of a failure in a TTL gate (the 74S04 is a hex inverter; its gates are on pg. 7 of the M8266 prints - they produce uPC03-08) taking out a bunch of other gates connected to it. Actually, the "m8266_ucode.v.txt" there seems to actually be the program that produced the symbolic dump (which is also available at: http://www.bitsavers.org/pdf/dec/pdp11/1134/m8266_ucode.out.txt) It looks like the program is in VHDL or something like that, but it doesn't seem to have the actual microcode (was it stored/defined in another VHDL file?); that raises the question of where the actual microcode that it was dumping was. It might be worth inquiring of Mike Douglas (he runs the DeRamp site) to find out where the files in "mfe_archive" came from; perhaps the source has, or knows of, the file which "m8266_ucode.out.txt" was a symbolic dump of - maybe from a complete KD11-EA simulation in VHDL? If that's not possible,it would be trivial to extract the PROM contents (well, partial contents - see below) from the "m8266_ucode.out.txt" file; each uword entry starts with the lines: ***** PDP-11/34a micro code word for MPC = 000 ***** (MSB is left, indented fields generated by expansion ROMs) micro word........ = 0000 0111 1100 0000 1100 1000 1010 0001 0000 0000 1110 0000 from ROM: E105 E103 E104 E100 E98 E97 E99 E106 E107 E108 E109 E110 The address of each uword is the "MPC = xxx" line; the contents of the 12 PROMs, at that address, are given on the "micro word........ = " line (the PROMs are 4 bits wide). If someone explained what format they needed as input for burning new PROMs, I could easily (like an hour) write a small portable program (using StdIO only, so it could be compiled and run on _anything_) that read that file in, and spat out the 12 PROM files. (Most of the dump could be ignored - all the data that's needed is in that one line.) BUT (and this is why it would be good to get back to the source of that file), that's not a complete M8266 ucode PROM dump. The KD11-EA has a uword address space 1 bit larger than the KD11-E - almost certainly to support floating point instructions; the KD11-EA adds 'uPC 09' (although looking its source at the top of pg. 7 of the prints, I don't quite grok how it is generated - maybe it's fed back through J2 from the FP11-A when one is plugged in). Anyway, uword addresses run up to 02000 in the KD11-EA, and the last uword in that dump is 0777. Interestingly, according to the flow charts of the 'basic' KD11-E/EA ucode in the prints (indexed and annotated here: https://gunkies.org/wiki/KD11-E/EA_microcode in full), they stop at 0757 - but the dump (in "m8266_ucode.out.txt") contains uwords that are 'supposed' to be blank (per the flow charts), as well as above 0757. So that dump must have been prepared from a copy of the 'new' KD11-EA PROMs - the ones including the floating point ucode. (Note that the FP11-A _also_ contains ucode, intended to control the stuff on the FP11-A; but the floating point instructions _also_ use the KD11-A for some stuff - e.g. fetching operands from main memory. Only the ucode address space is shared.) Right, a _completely_ different card - a boot PROM, not a CPU; totally un-related - and by a different person (Don North). But just for completeness, I looked in "tools.tar.gz", and it's just bootstrap PROM stuff. Noel