80386 microcode disassembled (opens in new tab)

I worked a bit on the extraction process so I can chime in here a bit. The first part is to just mark the x,y locations of where all the bits are, generally by the intersection of the rows and columns of the microcode array.

Then you have to classify them as 0's or 1's. Each is visually distinct, a 1 being encoded by the presence of a transistor and a gap in the polysilicon. We didn't have to guess which is which is by the nature of Intel microcode we could assume 0's were much more frequent, so a transistor meant a 1.

There are some automatic tools designed to perform this work via color thresholding, but they didn't work very well here because some of the mosaic was blurry, and a lot of dust had crept in which created false 1 bits.

Instead, we trained a convolutional neural network to classify the extracted bit regions into 0's and 1's. This was overlaid back onto the original mosaic as white or black squares at 50% opacity.

Then we spent several long, tedious days just checking the results for errors. Finally we had the raw 2d array of bits - the next step is to extract the microcode words from the bit array.

Here's a video of some guys de layering the chips for the Nintendo 64 lockout mechanism. It's pretty in-depth and it goes over a lot of different ways they do this.

https://youtu.be/HwEdqAb2l50?si=VFLed64PZvpCHfy1

Just look at the images[1].

> The photo above shows part of the microcode ROM. Under a microscope, the contents of the microcode ROM are visible, and the bits can be read out, based on the presence or absence of transistors in each position.

[1]: https://www.righto.com/2020/06/a-look-at-die-of-8086-process...

The microcode is in a ROM. It's a regular structure where a 1 looks different to a 0.

Maybe the hit counter increment was the inspiration for the post.

Well, one indication is the value loaded into EDX on reset:

    9B5 BIST1  -> TMPD    0x0303         PASS2
    9B6 SIGMA  -> EDX
    9B7 BIST2  -> TMPE    TMPD           XOR
    9B8 SIGMA             0x3ddc0c2c     XOR
    9B9 SIGMA  -> EAX     BOOTUP_JUMP    JFPUOK

0x303 = family 3, model 0, stepping id 3.

Just building your own microprocessor from gates is an easier way to learn about designing microcode and understanding how processors work(ed). But it can't hurt to study a few simple old designs like RISC or Transputer. The 80386 is on the other side of that spectrum, needlessly complicated because they wanted to be backwards compatible with an old bad design.

There certainly is no need to go to university to learn chip design. Watching a few Alan Kay talks [3] or browsing Bitsavers computer designs [4] are good starting points.

We made an easier way (than FPGA) to simulate and convert your gate level design into transistors on a chip (for less than $200 in 2026). We call it Morphle Logic [1].

Eventually you grow into making the largest fastest and cheapest supercomputer wafer scale integration [2].

[1] https://github.com/fiberhood/MorphleLogic/blob/main/README_M...

[2]https://www.youtube.com/watch?v=vbqKClBwFwI

[3] https://www.youtube.com/watch?v=f1605Zmwek8

[4] http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/...

I did nand2tetris a couple times, but it emphasizes simplicity in every level of abstraction. That in itself is an amazing lesson and has been an inspiration, but that also means it skips things like microcode. In college (in the 1990s) I took a EE class as part of my CS degree that went through how an 8086-like[0] CPU is made, a lot like nand2tetris but without necessarily making each part an assignment. It did cover how microcode worked where there was an internal program counter that stepped through a table of control words whose bits directly orchestrated each controllable piece of the CPU. We each got an instruction to implement on a simulator that the teacher had made previously. (I got DEC, decrement.)

In a way I guess the instructions in nand2tetris are the microcode. The bits of the instructions directly control the hardware with the first bit choosing 2 instruction types, so there’s only 1 step of code per instruction, unlike with microcode where an instruction can have any number of microcode steps.

In Ben Eater’s series of videos building an 8-bit CPU on breadboards he has ROMs that are indexed by the opcode (4 bits of the instruction) + a step counter to determine the control word. The ROM stands in for what could be done with sufficiently complicated logic gates. I like it as a next step on the hardware side as you get hands on experience with electronics and having to troubleshoot it.

It’s disappointing how it only has 16 bytes of RAM so you can’t really build higher levels of abstraction like you can with nand2tetris. But at that point you could (I should) either redo it with a better design (and put it on PCBs) or move on to the 6502 project, and then since that puts together a timer, CPU, ROM, RAM, I/O, UART, etc. mentally group those together and move on to microcontrollers that already have them together.

Anyone interested in reading about how a CPU could be made out of logic gates could also read Code by Charles Petzold (moves slower, recently updated) and/or Pattern on the Stone by Danny Hillis (moves faster).

Edit: I just checked Code (2nd edition) and that uses a 4 bit cycle counter and hard logic gates to determine what to do each cycle. But then it uses an array of diodes for part of the logic. Would that be considered microcode?

[0] there were classes that covered more advanced (pipelined) CPUs in another CS class but not at quite a low level where you felt like you could make one yourself

Do you know if nand2tetris covers/uses microcode?

I'm absolutely going to make one of those

I wouldn’t say it didn’t have any microcode. It actually had a small PLA for sequencing the multi-cycle instructions. [0]

I don’t think anyone would actually label it as microcode (not when the entire point of RISC was to avoid microcode) they would call it a sequencer or finite state machine; But really it’s the same thing. It’s certainly much simpler than the full microcode of any contemporary CISC, and the bulk of instructions execute in a single cycle without using it.

If you want a design with zero microcode, you really need to look at MIPS, or the original Berkeley RISC. Those ISAs go out of their way to avoid multicycle instructions. Not entirely successfully, but they don't use PLAs [1] to implement any state machines for the few remaining instructions like multiply and divide.

[0] http://daveshacks.blogspot.com/2016/01/inside-armv1-instruct...

[1] At least on the few MIPS designs I've looked at. And I'm not sure if they deliberately avoided PLAs for doctrine reasons, or it was just more efficient to do so.

Yet their purity brought them no commercial benefit.

nand2mario has made a Verilog implementation from it. It currently runs DOOM, but some of the more fiddly protected-mode bits prevent it from running full operating systems (besides DOS). I'm sure the bugs will get ironed out eventually.