z386: An Open-Source 80386 Built Around Original Microcode

https://nand2mario.github.io/posts/2026/z386/

Comments

cbdevidalMay 23, 2026, 4:05 PM
Of course they tested Doom :-D

They might also run Linux kernel 3.7, that supported i386. Gray386linux is still maintained, and runs a patched 3.7 kernel.

https://github.com/marmolak/gray386linux

nand2marioMay 23, 2026, 4:35 PM
Doom (DOS extender games) is an easier protected mode application as it does not use complex page tables. Linux is much more complex.
cbdevidalMay 23, 2026, 4:38 PM
I have faith in you!!
RiverCrochetMay 24, 2026, 1:39 AM
If modern x86 microcode ever gets sufficiently understood and reverse engineered I bet someone gets a PLAYDOOM instruction working. (I know it's been at least partially implemented on FPGAs)
KellyCriterionMay 23, 2026, 4:14 PM
haha, this was my first thought when I read the headline, because this "classic test" always comes up here :-))
ChrisArchitectMay 23, 2026, 9:16 PM
Related:

80386 Microcode Disassembled

https://news.ycombinator.com/item?id=48247004

UncleOxidantMay 23, 2026, 4:48 PM
Kind of surprised this only takes 18K LUTs. That's a fairly small FPGA these days.
mycallMay 23, 2026, 5:37 PM
How does it compare to something like VexRisc [0] with respect to its capabilities? I know having x86 support is a metric all by itself.

[0] https://github.com/spinalhdl/vexriscv

UncleOxidantMay 25, 2026, 3:34 PM
A lot of RISCV implementations are going to be better and take a lot less resources in an FPGA due to the much more-easily-decoded ISA. What I was saying above was that I was surprised that they could get an x86 into that few LUTs as the x86 ISA is not well suited to efficient implementations.
phireMay 23, 2026, 11:30 PM
No contest really: RISCV is a much better ISA, VexRISC is a hyper-optimised implementation of it (for FPGAs), and it's not hindered by trying to be microcode compatible.

The roughly equivalent VexRISC configuration (full with MMU) is only 2736 LUTs, running at 124 Mhz (on Cyclone V, which I'm pretty sure is the same arch)

mmastracMay 23, 2026, 3:21 PM
Did the microcode disassembly find any useful backdoors to read microcode without decapping?
nand2marioMay 23, 2026, 3:28 PM
Not really. The 386 does not have an interface to read the ROM direclty. Instead, it uses the Built-In Self-Test (BIST) to verify the ROM's contents. It's basically a checksum-like mechanism that verify the integrity of the CROM.
NooneAtAll3May 23, 2026, 6:26 PM
there are several iterations of 386 and only one was disassembled

so there's still a chance

KellyCriterionMay 23, 2026, 4:16 PM
Question: Are there today any 386 instances running somewhere in the basement to do some productive stuff, maybe processing only some controller data once a day?

I remember the link some month ago where that one small shop ran completely on an old Amiga (?IIRC, not sure, was linked here)

Around 98/99 I was involved in a small IT-management company serving SME around the region, we had a client producing distinct metal objects with a big press; this got feeded once a day with a 5.25 floppy from another machine with production data - and it was still in use while we had already ethernet/USB/3.5 floppies etc. :-D

bitwizeMay 23, 2026, 4:26 PM
A few years ago there was a story where the single Amiga that ran an entire US school district's HVAC was replaced with a system costing like 1.5 million dollars, after 30 years of dutiful service.

I can't think of examples offhand but you bet your ass there are donut shops and auto body repair services running 386s to do POS, inventory, and the like. Some of them may be driving terminals off Xenix.

xp84May 23, 2026, 4:54 PM
Funny thing about this is that the character-based systems of that era, whether PC-type or host+terminal type, were most of the time so much faster and more responsive than the laggy, over-animated, touchscreen trash they always replace them with in order to get big screens and prettier graphics.
zozbot234May 23, 2026, 5:53 PM
The Amiga was not character-based, it ran an accelerated framebuffer (with support for scanning out multiple resolutions and color depths on a single screen).
xp84May 23, 2026, 7:23 PM
Sorry, I was generalizing the "typical" pre-1995 system one would find in commercial installations, which in general were character-based. But I'm sure the Amiga solution would have been nice and fast too, since they were pretty powerful and programmers back then didn't feel the need to bring in PhoneGap, React, or 5,280 npm packages in order to display what amounts to a form.
asdefghykMay 23, 2026, 7:48 PM
RE "....a system costing like 1.5 million dollars, after 30 years of dutiful service....."

I immediately wondered ... how long the new system would last or be used .... and how long it would be problem free ?

bitwizeMay 24, 2026, 5:32 AM
Ultimately that kind of question doesn't really matter. The only question that matters is "who will fix it when it breaks?" The Amiga system was a single machine running custom code written by one guy. If that guy dies or decides to quit maintaining it and it fails, hundreds of school kids are going to end up shivering or overheating for who knows how long. That's an unpleasant risk that may prove more costly than the $1.5mil it cost to replace it. The new system was written by a team, working at a company that specializes in this sort of thing, that has credentials proving it complies with relevant industry and safety standards, and a contract binding it to a term of service and support. That shit's worth its weight in gold to businesses and governments, even though it doesn't necessarily result in added functionality. So while it's fun to post "look at what they need to mimic a fraction of our power" memes about old systems like that, there's a reason why these are done by teams working at institutional organizations. It helps defray the risk.

In the late 90s I was interning at a place, and one of the IT guys there was old, we're talking white beard. He thought Linux was an absolute joke, and told me that the future of IT belonged to Windows NT (though it should have belonged to OS/2). The reason why is because with Linux, there was "no ass to drag onto the carpet"—no one to sue when it breaks. With Windows, the largest and most successful software company of all time was backing it up, staking their entire business on customer satisfaction. Of course, he ended up being wrong about Linux, but only because companies (mainly Red Hat) stepped up to assume the risk for big clients. That's one of the major functions of business—to provide an arm for customers to twist.

AviationAtomMay 23, 2026, 11:31 PM
You missed a fun part of that story! The person who programmed it was a kid in the district at the time. They continued to hire him to come back and maintain it any time they had issues, which apparently was fairly rare.
bitwizeMay 24, 2026, 6:04 AM
And back in the 90s, before anybody knew anything about risk or "bus factor", that might've made sense. But it's no surprise that they paid a pretty penny for an actual support contract after decommissioning that system.
geonMay 23, 2026, 6:26 PM
I think there are industrial pcs with a 486-compatible soc.

A ton of industrial equipment are still using win 3.1.

bzzztMay 23, 2026, 6:41 PM
Consequence of the 'if it works, why mess with it?' mindset. It will become a problem when those boards give out and spares are gone.
st_goliathMay 23, 2026, 8:20 PM
I wonder how many of those are actually still out there. According to Wikipedia, Intel kept making replacement parts (386 and 486) until September 2007, but personally, I have never come across one in actual use. My own career in this field began with an internship in 2008. My day job includes working on a PLC runtime with a code base older than myself, originally written for DOS, but every industrial PC (or other x86 based embedded device) I have ever got to play around with had at the very least a Pentium class CPU in it.

As for the Windows 3.x based industrial equipment: Some industrial devices I have worked on in the past turned out to actually be ARM based, running Linux, but the software went a long way to convincingly fake old Windows style UI or emulate a DOS prompt. I was once tasked to extend such a UI library to faithfully reproduce Windows 98 style color gradient borders.

Only once have I seen an actual embedded 486SX with my own eyes, but not in active use anymore. Last year, someone dragged a dusty, old, weirdo Siemens telephony box to the the local Hackerspace. The box itself had a design language that screamed "Star Trek: Voyager". I found a UART, it was running "On Time RTOS-32" which, according to the German Wikipedia, was an RTOS with a Windows API compatible userspace, developed by a German company in 1996 and discontinued in 2023.

skissaneMay 23, 2026, 10:03 PM
> Some industrial devices I have worked on in the past turned out to actually be ARM based, running Linux, but the software went a long way to convincingly fake old Windows style UI or emulate a DOS prompt. I was once tasked to extend such a UI library to faithfully reproduce Windows 98 style color gradient borders.

IBM mainframes have an embedded PC (the "Support Element") used to manage the hardware configuration and diagnostics. Originally, it ran OS/2. In 2005, IBM replaced it with Linux–running a UI which looked like OS/2. (At some point more recently, they refreshed the visual look so it doesn't look like OS/2 any more, although I'm not sure when they did that.)

BirAdamMay 23, 2026, 10:30 PM
No. That’s why companies like Vortex are still in business. There’s even a company producing new Win98 machines for this reason.
userbinatorMay 23, 2026, 5:21 PM
There's likely plenty of them still in use in industrial/embedded applications.
spankibaltMay 24, 2026, 5:23 AM
Sadly, without an accompanying FPGA-implementation of an FPU it's much less useful for productivity work/research, i.e. outside of 08/15 gaming and application fare. Same with Ao486, which only implements a 486SX.
nand2marioMay 24, 2026, 7:18 AM
I think there are two reasons we haven’t seen an FPGA FPU yet, especially for MiSTer.

First, FPUs are complex and FPGA support for floating point is limited. There's DSP blocks for integer additions and multiplications. But very little FP support.

Second, the CPU itself may not be fast enough for an FPU to matter much. Quake wants at least a 75 MHz Pentium, while ao486-MiSTer is closer to a 486-66. So we probably need both a faster CPU design and a faster FPGA. Maybe Altera's new Agilex 5 will be useful here.

spankibaltMay 24, 2026, 10:47 PM
Aye. Well, hopefully something comes to pass as a lot of industry-specific applications demand the (emulated) physical presence of an FPU. Keeping that in mind, it's obviously high-level bitching (as we say in Germany); I, as a fan of IBM PCs and compatibles, am very fascinated by your and others' awesome work in this domain.
raszMay 25, 2026, 7:22 PM
> a lot of industry-specific applications demand the (emulated) physical presence of an FPU

Can you name some? I cant come up with any real world uses of FPU implemented PC for industrial use. Even MISTER is pushing it considering availability of emulation.

spankibaltMay 27, 2026, 1:23 AM
What I've personally seen that needed an FPU: a water analysis package for a "field laboratory" (its centerpiece being a luggable PC), several in-house applications of an insurance company (which my mentor, a mathematician, coded), as well as a bespoke, modular sasec (safety and security) suite for facility management. I'm slowly building a reference list of DOS- and UNIX-based industry software, as I have an interest in that stuff. Can't help with any names. Yet.

So much for needed. Packages that run without, but are only fully useful with an FPU, were relatively common.

dangMay 23, 2026, 11:18 PM
Related ongoing thread:

80386 Microcode Disassembled - https://news.ycombinator.com/item?id=48247004 - May 2026 (42 comments)