Getting a cycle-accurate emulator of the NEC V20 microcode ROM right means you cannot fudge the microcode: you need the actual bit pattern baked into silicon, and that means going straight to the die. That is exactly what [GloriousCow] has been doing, methodically extracting a usable ROM image from a die shot of the V20, NEC’s Intel 8088-compatible processor that carries its own distinct microcode implementation.
Nearly 30,000 Bits and the Problem of Contrast
The NEC V20 microcode ROM section in the die shot holds 29,928 bits. You could, in principle, classify every one of those by hand, squinting at a screen and ticking boxes, and if you had a circle of equally dedicated friends, you could divide the work and share the misery. The more appealing alternative is automation, and [Travis Goodspeed]’s GitHub-hosted MaskRomTool exists precisely to handle this kind of bit detection automatically.
The catch, as [GloriousCow] found, was contrast. The die shot of the V20 simply did not have enough contrast for MaskRomTool to work reliably as a classifier. What it could do, however, was identify the physical locations of the bits and generate 42×42 pixel PNG files for each one. That output became the foundation for the next stage.
Training a CNN on NEC V20 Microcode Bit Images
With thousands of small images in hand, [GloriousCow] trained a convolutional neural network to distinguish a 0 bit from a 1 bit. Training a CNN is not free work: it required manually classifying 1,000 images to build a usable training set. The model performed fairly well once trained, though some bits came back marked as ambiguous rather than a clean zero or one.
For those ambiguous cases, the solution was refreshingly analogue. Rather than spending further time tuning the CNN, [GloriousCow] simply ran a visual inspection on the handful of uncertain images, the Mark 1 eyeball proving, as ever, to be a surprisingly useful instrument when the dataset is small enough. It is a pragmatic approach: automate the bulk, intervene manually on the edge cases, and keep moving.
Once the full microcode was extracted, the next step was matching it against the V20’s internal architecture to determine what each section actually does. That work is still ongoing. Progress so far lives in a GitHub repository, open for those who want to follow along or contribute.
A Processor With a Litigious Past
The V20’s microcode has never been a purely academic subject. Back when NEC and Intel were fighting in court over exactly how compatible one manufacturer’s processor could legally be with another’s, the microcode sat at the heart of the dispute. The question of whether microcode constitutes copyrightable expression, and whether NEC had copied Intel’s, ran through years of legal argument. It was one of the defining intellectual property battles of the era, and its outcome shaped how the compatible-processor market developed.
That history gives this kind of reverse-engineering project a certain weight beyond mere technical curiosity. Understanding precisely what the V20’s microcode contains, and how it differs from the 8088’s, matters both for accurate emulation and for the historical record of how NEC engineered its own path through compatible silicon.
The project is not finished. But with the CNN-assisted extraction done and the architectural matching underway, the NEC V20 microcode ROM is yielding its secrets one 42×42 pixel tile at a time.
