UselessSoftware wrote on 2026-03-30, 03:03:

It was still in a pretty broken state last time I made a post, but I've been doing a lot of work on it over the last few months […]
Show full quote

It was still in a pretty broken state last time I made a post, but I've been doing a lot of work on it over the last few months and fixed numerous bugs, CPU and otherwise.

It now runs Windows NT 4.0 for example. The main blocker there was that my V86 mode handling was really broken, and NT requires it to be functional to even do something as basic as set the graphics mode with the standard VGA driver.

Last time I posted, the only 32-bit OS it would run was some older Linux distros, and even then with various issues and occasional process crashes.

I've also added ATAPI CD-ROM, PCI bus, BusLogic SCSI, and the i430FX + i430HX chipset. The CPU is also now basically at a Pentium baseline.

I haven't pushed a version that can run NT or with the other new features to Github yet, but should be this week probably. I want to add a better and PCI-based SVGA card first. It's mostly implemented (GD5440) but not quite done.

But I'm just sharing because this makes me happy! It's always been a bucket list goal to make a working x86 PC emu, and it's really getting there lately.

Can You get OpenGL 1.1 software acceleration?

Nice work!

Awesome work on PCulator so far! 😀

DLL hell wrote on 2026-03-30, 03:41:

UselessSoftware wrote on 2026-03-30, 03:03:

It was still in a pretty broken state last time I made a post, but I've been doing a lot of work on it over the last few months […]
Show full quote

It was still in a pretty broken state last time I made a post, but I've been doing a lot of work on it over the last few months and fixed numerous bugs, CPU and otherwise.

It now runs Windows NT 4.0 for example. The main blocker there was that my V86 mode handling was really broken, and NT requires it to be functional to even do something as basic as set the graphics mode with the standard VGA driver.

Last time I posted, the only 32-bit OS it would run was some older Linux distros, and even then with various issues and occasional process crashes.

I've also added ATAPI CD-ROM, PCI bus, BusLogic SCSI, and the i430FX + i430HX chipset. The CPU is also now basically at a Pentium baseline.

I haven't pushed a version that can run NT or with the other new features to Github yet, but should be this week probably. I want to add a better and PCI-based SVGA card first. It's mostly implemented (GD5440) but not quite done.

But I'm just sharing because this makes me happy! It's always been a bucket list goal to make a working x86 PC emu, and it's really getting there lately.

Can You get OpenGL 1.1 software acceleration?

It should work! I haven't tried. I did try UT99 and its software renderer works.

The "47 FPS" is a lie. Or misleading. That's the rate it's rendering SVGA memory and blitting to the SDL window.

UT99 is actually rendering at more like 0.5 FPS 🤣

GloriousCow wrote on 2026-03-30, 06:34:

Nice work!

ppgrainbow wrote on 2026-03-30, 10:08:

Awesome work on PCulator so far! 😀

Thanks guys! I'm installing this right now... going to see how it runs. Assuming something doesn't break before it's finished!

I was also able to install Server 2003, which runs all the way through the GUI portion of setup, but then... hangs at a black screen on the first actual boot. I'm trying to dig into why.

UselessSoftware wrote on 2026-04-02, 03:24:

Thanks guys! I'm installing this right now... going to see how it runs. Assuming something doesn't break before it's finished! […]
Show full quote

GloriousCow wrote on 2026-03-30, 06:34:

Nice work!

ppgrainbow wrote on 2026-03-30, 10:08:

Awesome work on PCulator so far! 😀

Thanks guys! I'm installing this right now... going to see how it runs. Assuming something doesn't break before it's finished!

I was also able to install Server 2003, which runs all the way through the GUI portion of setup, but then... hangs at a black screen on the first actual boot. I'm trying to dig into why.

UselessSoftware, any idea how the operand sizes and truncation of (E)IP/(E)SP works when handling interrupts and call gates that push those contents onto the (higher) privileged stack? What for example happens with the use of D/B bits of the lower and higher privileged program during stack switches, TSS (E)SP loads and storing return values on the (new) stack when combined with call/interrupt gate size and the user and kernel D(CS)/B(SS) bits?
For some reason I never got 2000/XP booting, despite NT 4 booting without issues (i440fx with ATAPI drive). Kept getting 0x7B BSODs no matter what on 2000 and up.

Or make your current code available so I can see how it's supposed to work?

Probably a silly question, but you seem likely to know.

Would it be possible in a simpleish way:
Boot an emulatory thing like this on say, "core2" and then boot any other legacy os like dos, 9x as normal on core1 without something crashing?

Think picogus or similar hardware emulation without the physical hardware, or virtual machines, and effectively no overhead. More like a tsr with a separate processor/os.

I can imagine it working, but I can also imagine it having serious problems with memory management and the likes.

superfury wrote on 2026-04-05, 08:35:

UselessSoftware, any idea how the operand sizes and truncation of (E)IP/(E)SP works when handling interrupts and call gates that […]
Show full quote

UselessSoftware wrote on 2026-04-02, 03:24:

Thanks guys! I'm installing this right now... going to see how it runs. Assuming something doesn't break before it's finished! […]
Show full quote

GloriousCow wrote on 2026-03-30, 06:34:

Nice work!

ppgrainbow wrote on 2026-03-30, 10:08:

Awesome work on PCulator so far! 😀

Thanks guys! I'm installing this right now... going to see how it runs. Assuming something doesn't break before it's finished!

I was also able to install Server 2003, which runs all the way through the GUI portion of setup, but then... hangs at a black screen on the first actual boot. I'm trying to dig into why.

UselessSoftware, any idea how the operand sizes and truncation of (E)IP/(E)SP works when handling interrupts and call gates that push those contents onto the (higher) privileged stack? What for example happens with the use of D/B bits of the lower and higher privileged program during stack switches, TSS (E)SP loads and storing return values on the (new) stack when combined with call/interrupt gate size and the user and kernel D(CS)/B(SS) bits?
For some reason I never got 2000/XP booting, despite NT 4 booting without issues (i440fx with ATAPI drive). Kept getting 0x7B BSODs no matter what on 2000 and up.

Or make your current code available so I can see how it's supposed to work?

Sorry it took so long to reply!

Gate size controls the saved return-frame width. CS.D controls normal instruction defaults. SS.B controls which stack pointer register is used for stack addressing. TSS type controls how wide the new privilege stack pointer is loaded.

For interrupt/trap gates and call gates, the source and target CS D-bits don't decide the hardware frame size. Intel's 80386 manual says the architecture has separate 16-bit and 32-bit gates, and that the operand size for the control transfer is determined by the type of gate, not by the D-bit or instruction prefix.

As far as the 0x7B error, I was actually getting this error FOREVER. I thought it was a bug in my CPU or ATA code (I guess it still could be somehow) but then I added a BusLogic SCSI controller and NT happily booted from that.

The NT on ATA blue screen was with a very old Award 486 BIOS. Later when I added i440FX and i440HX machines with newer Award BIOSes, suddenly NT booted just fine from ATA! If I go back to the old 486 BIOS, it throws a 0x7B again. 🤣

I still have no idea what the deal is, but don't really care anymore. I just removed that old 486 machine since I'm at a Pentium-class core now anyway.

I do have more recent code on Github now too. The Voodoo3 code (screenshots below) isn't pushed yet.

https://github.com/mikechambers84/pculator

myne wrote on 2026-04-06, 06:11:

Probably a silly question, but you seem likely to know. […]
Show full quote

Probably a silly question, but you seem likely to know.

Would it be possible in a simpleish way:
Boot an emulatory thing like this on say, "core2" and then boot any other legacy os like dos, 9x as normal on core1 without something crashing?

Think picogus or similar hardware emulation without the physical hardware, or virtual machines, and effectively no overhead. More like a tsr with a separate processor/os.

I can imagine it working, but I can also imagine it having serious problems with memory management and the likes.

You could write what's basically a very simple bare-metal hypervisor that runs DOS pinned to the first core and then dedicate a second core to hardware emulation.

But then you are using a virtual machine behind the scenes. I don't believe there's any way to do it otherwise. If DOS is truly running bare-metal, it has direct access to physical ports/IO/memory addresses. There's no way to (reliably) intercept its attempts at hardware access and trick it into seeing something that's emulated.

But you could theoretically write something so simple and transparent that it's invisible and it really feels just like you're directly booting the machine into DOS if that's what you're after.

This is kind of a huge milestone. 3dfx Voodoo3 3000 PCI is working!

UselessSoftware, Is that software emulated or like opengl passthrough? Haven't seen any non-fully software emulated one yet (if it exists. It would make it portable).

Also, does the i440fx have anything undocumented with it's IDE implementation? I am using it to boot all OSes, but somehow it still results in a ox7B booting from the CD-ROM, after saying it's starting Windows 2000. I don't see any hard disk activity after that point, like it forgot it exists. NT4, NT3 and 9x boots without issues. Haven't tried ME yet.

One odd thing right now is that 32-bit Windows 3.x (/3 switch) boots but with /s it crashes (and /r boots). I see it read some file from the HDD and it eventually overwrites the IDT (with ES at 16 bytes below the IDT somehow) from a REP MOVSB instruction. This only happened after I made protected mode cycle-accurate, after fixing 32-bit booting.