Thanks for mentioning z386. Much of its recent progress was made possible by the reverse engineering and disassembly of the original 80386 microcode (https://news.ycombinator.com/item?id=48247004), which z386 uses as its control program. That work has been especially valuable for reproducing obscure protected-mode behavior correctly.
With correctness helped greatly by that, development is now focused mainly on performance. In Doom, z386 is currently about 30% faster than ao486 on the same MiSTer setup, with benchmark performance roughly comparable to a 486DX2-66.
Can you describe why z386 is much faster than the supposedly highly optimized ao486? Is the original microcode (and corresponding chip architecture) that good?
The memory pipeline just starts one cycle later than now. Effective address is calculated during the first cycle of the instruction. The microcode then waits for it to finish with the DLY (delay) micro-op, which releases one cycle later.
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.
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.
> 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.
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.
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.
Yep. The microcode in real mode segment loading (as shown in the post) does not set the limit to 64KB. That is why returning to real mode with a large value like 4GB in limit gives you "unreal mode".
Nice findings. For segment loads from memory, the entry point is actually shared between real and protected mode on the 386. The microcode branches later based on PE and does the extra descriptor work only in protected mode. So maybe it's done similarly on the 286.
The decode vs. execution behavior is more interesting. From both Intel docs and my own core, PE is effectively checked in both stages independently, but decode happens ahead of execution (prefetch queue). So if an instruction is decoded in real mode, it’ll still follow the real-mode path even if PE is set before it executes.
That’s exactly why Intel requires a jump right after setting PE — it flushes the prefetch queue and forces re-decode in protected mode. As the 80386 System Software Writer’s Guide (Ch. 6.1) puts it: "Instructions in the queue were fetched and decoded while the processor was in real mode; executing them after switching to protected mode can be erroneous."
I was just trying to give a bit of historical context, but apparrently need to be more precise next time! 386 is the beginning of 32 bit. But it's mainly the pentium and 486 that ran Windows 95.
Author here. Happy to discuss the technical details. The broader goal is to understand the 80386 microcode and hardware, and build an FPGA core around it, similar to what was already done for the 8086.
With correctness helped greatly by that, development is now focused mainly on performance. In Doom, z386 is currently about 30% faster than ao486 on the same MiSTer setup, with benchmark performance roughly comparable to a 486DX2-66.