nand2mario

6 ms·

1.
by nand2mario 1mo ago
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 co
2.
by nand2mario 3mo ago
Probably some protected mode logic bugs. Just need more time to debug through the boot process.
3.
by nand2mario 3mo ago
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.
4.
80386 Early Start Memory Access(nand2mario.github.io)
49 points by nand2mario 3mo ago|9 comments
5.
by nand2mario 4mo ago
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
6.
by nand2mario 4mo ago
Doom (DOS extender games) is an easier protected mode application as it does not use complex page tables. Linux is much more complex.
7.
by nand2mario 4mo ago
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.
8.
80386 microcode disassembled(reenigne.org)
278 points by nand2mario 4mo ago|54 comments
9.
by nand2mario 5mo ago
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".
10.
by nand2mario 5mo ago
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&#x2
11.
80386 Protection(nand2mario.github.io)
124 points by nand2mario 7mo ago|30 comments
12.
by nand2mario 8mo ago
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.
13.
by nand2mario 8mo ago
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.
14.
by nand2mario 8mo ago
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
15.
80386 Multiplication and Division(nand2mario.github.io)
108 points by nand2mario 8mo ago|30 comments
16.
Z8086: Rebuilding the 8086 from Original Microcode(nand2mario.github.io)
51 points by nand2mario 9mo ago|24 comments
17.
by nand2mario 10mo ago
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.
18.
by nand2mario 1y ago
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.
19.
by nand2mario 1y ago
Yes, for exactly the reason. SDRAM is much easier to work with in retro computing than DDR.
20.
by nand2mario 1y ago
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, b