nand2mario

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.

Probably some protected mode logic bugs. Just need more time to debug through the boot process.

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.

Doom (DOS extender games) is an easier protected mode application as it does not use complex page tables. Linux is much more complex.

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.

Right. Or it could be frequency illusion. Once you become aware of something, it appears to be more frequent:

https://en.wikipedia.org/wiki/Frequency_illusion

xtce_trace sounds fantastic — exactly what I need right now while debugging my Verilog 8086 core. Thank you also for the microcode disassembly. It’s been fun to work through.

It currently uses 44% of the LUTs and 59% of the BRAMs (out of 340 × 2 KB blocks). The chip itself is fairly large and inexpensive, though performance leans toward the lower side.

Yes, for exactly the reason. SDRAM is much easier to work with in retro computing than DDR.

Author here. You’re right—EDO or FPM would be correct for the era. But as others have noted, DDR3 is fundamentally different from early 1990s memory, and it simply won’t run at the very low clock speeds of a 486. SDRAM, on the other hand, behaves in a way that’s much more comparable to the memory used back then.