A volunteer reverse-engineering team has finished decapping an Intel 8087 math coprocessor from 1980 and successfully read its complete on-die microcode ROM under a microscope. The result is a window into how 1980s-era math coprocessors actually computed floating-point operations at the transistor level — and a primary-source document for the early implementation of what became the IEEE 754 floating-point standard. For retro-computing builders and anyone working on emulation accuracy, this is a meaningful artifact.
This piece is editorial synthesis of the original decap writeups on righto.com, Wikipedia's history of the 8087, and the published IEEE 754 standard documentation. No independent first-party benchmarking is reported.
Key takeaways
- The 8087 was Intel's first math coprocessor, introduced in 1980 alongside the 8086.
- It implemented the draft IEEE 754 floating-point standard before the standard was finalized in 1985.
- Researchers acid-etched the package and used microscope imaging to read every bit cell in the on-die microcode ROM.
- The microcode reveals how transcendental functions (sine, log, etc.) were implemented as iterative CORDIC-style state machines.
- x87 instructions inherited from the 8087 still execute on every modern x86-64 CPU today.
What is the Intel 8087, and why does it matter?
Per the Wikipedia history, the Intel 8087 was a math coprocessor designed to attach to the Intel 8086 and 8088 CPUs. It added IEEE 754 floating-point support to a CPU family that, on its own, could only do integer math. In 1980 this was a significant deal: business and engineering applications that needed reliable floating-point arithmetic — CAD, accounting, scientific simulation — had to either tolerate software emulation (slow) or pay for the coprocessor (fast but expensive). The 8087 was the start of the x87 family of FPUs that would persist through the 80287, 80387, and eventually integrate into the 486 die.
The chip itself is a 40-pin DIP package on an NMOS process at roughly 3-micron geometry, which is hilariously coarse by 2026 standards but cutting-edge in 1980. Its die is small enough that an enthusiast with a half-decent microscope and the patience to do bit-by-bit transcription can read the entire ROM by hand. That's exactly what the decap project did.
How does decapping work?
You take the packaged chip, soak it in fuming nitric or sulfuric acid under temperature control until the plastic encapsulation dissolves. With ceramic packages, you can sometimes split them mechanically. The goal is to expose the bare silicon die without melting the bond wires that connect die pads to package pins. Once exposed, you image the die under an optical microscope at 50-500x magnification. For modern process nodes you need an SEM (scanning electron microscope) because the features are sub-wavelength of visible light. For 1980 NMOS at 3-micron pitch, an optical scope works fine.
The 8087's microcode lives in a ROM block on the die. On NMOS ROMs of that era, each bit is encoded as the presence or absence of a transistor at a grid intersection — a "diffusion ROM." You can literally see the ones and zeros under the microscope. The decap team imaged every cell, transcribed the pattern into binary, and then did the harder work: figuring out what each microcode word means. That requires correlating the bit pattern with the chip's documented behavior on test instructions and tracing which control lines each microcode bit drives.
What did the microcode reveal?
The recovered microcode shows that the 8087 implements transcendental functions — sine, cosine, log, exponential — as iterative state machines using the CORDIC algorithm. CORDIC is a 1959 algorithm that computes trig and log functions using only shifts, adds, and table lookups, which is enormously cheaper than implementing a polynomial approximation in silicon. The 8087's microcode shows the iteration loop explicitly: the same handful of microinstructions executes repeatedly with rotating operands until the result converges.
This is the kind of detail that has been known in general terms for decades — Intel's patents from the early 1980s describe CORDIC implementations — but having the actual microcode bits transcribed lets researchers verify the specific iteration count, the convergence behavior, and the edge-case handling of subnormals and exceptions. That's important for cycle-accurate emulator accuracy, for understanding why the 8087 produces the exact result patterns it does on hard test cases, and for documenting the historical record of how IEEE 754 was first implemented in hardware.
Why does the IEEE 754 connection matter?
The 8087 was designed during the IEEE 754 standardization process. The standard itself wasn't ratified until 1985, but the 8087 (1980) implemented what became the final standard in nearly all its essential details. The 80-bit extended-precision format that's still part of x87 today, the rounding modes, the exception-handling architecture — these were all baked into the 8087 ahead of the ratification, and IEEE 754 substantially codified what Intel had shipped.
That makes the recovered microcode a primary-source document for a foundational moment in computing. If you want to understand why double-extended precision is 80 bits and not 96 or 128, or why x86 SSE2 still has subtly different behavior than x87 on certain edge cases, the answer is in the 1980 8087 microcode. The decap project gave us machine-readable access to that record for the first time.
What does this mean for emulator accuracy?
For projects like 86Box, PCem, and DOSBox-X that aim for cycle-accurate emulation of late-1970s/1980s PCs, having the actual 8087 microcode lets them verify their FPU emulation against the real hardware's behavior — not just the documented behavior, but the undocumented edge cases too. There are corners of x87 behavior (denormal handling, certain transcendental result patterns) that aren't in the published manual; the decap data lets emulator authors check whether their implementation matches the original silicon.
For retro-build hobbyists running an actual 8088/8087 machine, the microcode isn't directly useful — your chip already has it — but it does feed into a richer body of documentation about what your hardware does and why.
The retro-computing community side of the story
The decap was done by hobbyists, not by a corporate research lab. That's significant. The community of people who reverse-engineer old chips has been growing — Ken Shirriff's decap and analysis writeups on righto.com are required reading — and the toolchain (acid decapping setups, microscope rigs, ROM transcription software) is now within reach of a dedicated individual. Projects like this run on volunteer time, often years of it, and they preserve technical history that would otherwise be locked inside silicon nobody can read anymore.
If you want to follow or contribute to this kind of work, the practical entry points are:
- Stereomicroscope. A good 20-40x scope with a USB camera is the starting point. Used research-grade microscopes from eBay are an inexpensive way in.
- Decap chemistry. Fuming nitric is the standard solvent for plastic packages but requires a fume hood and serious PPE. Many newer projects use mechanical decap on ceramic packages or commercial decap services.
- Image stitching software. Hundreds of microscope images get stitched into a single high-resolution die scan using software like Hugin or Fiji.
- ROM transcription. Once you have a stitched die image, manual or semi-automated bit-cell recognition transcribes the ROM into a binary file.
Where retro-build hobbyists go from here
For the most part, the 8087 microcode story is a window into computing history, not a buying recommendation. But it dovetails with the live retro-computing scene in a few ways. People who maintain working 8088/8086/80286 machines with original 8087 coprocessors get a richer documentation set. People who run period-accurate emulation get better fidelity. And people who build modern retro-style projects (DOS games on real metal, vintage CAD on a clone XT) get a deeper appreciation of the silicon their software is touching.
If you're building or maintaining vintage hardware in 2026, the practical accessories that matter haven't changed: a SATA/IDE-to-USB adapter for migrating old drives, a Raspberry Pi 4 8GB for emulation when you want to demo period software without sourcing original hardware, and a modern host like an Intel Core i7-9700K build for running emulators with comfortable headroom.
Common pitfalls in chip decap work
- Acid handling. Fuming nitric is one of the more dangerous reagents a hobbyist will ever handle. Get the PPE first; the chip can wait.
- Bond-wire damage. Over-etching dissolves bond wires and severs the die from the package. Stop short; partial encapsulation is fine if you only need the die surface.
- Glass passivation. Most chips have a glass overlayer that's transparent but can reduce contrast under the microscope. HF can remove it but is even more dangerous than nitric.
- ROM cell ambiguity. Some bit cells look the same whether they're a 0 or a 1 depending on lighting angle. Multiple images at different angles and a known test pattern help disambiguate.
- Microcode word format. Knowing the ROM bits is not the same as knowing what they mean. Tracing control-line connections from the ROM to the rest of the chip is often the longest part of the work.
Bottom line
A successful decap of the Intel 8087 has put the chip's complete microcode in the public record for the first time. The result is a primary-source document for the start of IEEE 754 floating-point computing, useful for emulator accuracy and meaningful as computer-history preservation. It's the kind of project that exists because dedicated hobbyists spent years on it — and the kind of artifact that justifies the time.
Related guides
- How Creative's Sound Blaster Ruled PC Audio for 20 Years
- Can a Raspberry Pi 4 (8GB) Run a Local LLM in 2026?
Citations and sources
- Wikipedia — Intel 8087
- righto.com — Ken Shirriff's reverse-engineering writeups
- Wikipedia — IEEE 754 floating-point standard
This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.
