Super interesting project.

How difficult is it to make this run on real hardware? I have an old D945GSEJT motherboard lying around, waiting to be put to use. It is now too old, and with its 32-bit CPU, it is difficult to run any recent Linux distro on it.

Its hardware, including the GMA950 and ICH7M, is not very MS-DOS-friendly. However, nowadays we have VSBHDA, and it likely supports the basic VESA video modes required by most MS-DOS games. Running Windows 98 is still impossible because compatible drivers are unavailable.

If I understand correctly, this project can replace some native hardware components with emulated legacy equivalents. It also preserves native CPU execution paths where possible, so it does not incur the overhead that a full-blown VM or PCem-style emulator would have on the same hardware.

I know this is very far away in the future, but could this also make it possible to emulate additional advanced hardware, such as running a Voodoo software rasterizer on a secondary core of a modern multicore CPU that would otherwise sit idle while DOS is running natively?

^Isn't that a nice Hackintosh board? :)
I vaguely remember that GMA 900/950 is natively being supported by Mac OS X 10.4 (Tiger) to 10.6 (Snow Leopard).

Edit: Nevermind, I was a bit off-topic again. About the "Voodoo software rasterizer".:
There's already one from the 90s, "3Dfx Emulator v0.2 from ELZ SOFTWARE.
It required roughly a 200 MHz Pentium, according to its readme file.
So it's technically possible on DOS, in principle.

inagy wrote on 2026-07-26, 15:53:

Super interesting project. […]
Show full quote

Super interesting project.

How difficult is it to make this run on real hardware? I have an old D945GSEJT motherboard lying around, waiting to be put to use. It is now too old, and with its 32-bit CPU, it is difficult to run any recent Linux distro on it.

Its hardware, including the GMA950 and ICH7M, is not very MS-DOS-friendly. However, nowadays we have VSBHDA, and it likely supports the basic VESA video modes required by most MS-DOS games. Running Windows 98 is still impossible because compatible drivers are unavailable.

If I understand correctly, this project can replace some native hardware components with emulated legacy equivalents. It also preserves native CPU execution paths where possible, so it does not incur the overhead that a full-blown VM or PCem-style emulator would have on the same hardware.

I know this is very far away in the future, but could this also make it possible to emulate additional advanced hardware, such as running a Voodoo software rasterizer on a secondary core of a modern multicore CPU that would otherwise sit idle while DOS is running natively?

I give it a solid chance it might work. Your hardware is still fully BIOS, so vga/svga will be good and RetroOS will just use that. Listing
- cpu -> excellent (supports VME + plenty powerful for emulating GUS and nice General MIDI (doom + duke3d + dark forces will have nice music)
- firmware -> classic bios (= retroos happy case)
- video -> supports classic vga (= happy case)
- audio -> hda, RetroOS supports hda and works on QEMU and my high-end modern laptop (which is harder to get right then your case) but I havent tested this at all
- hdd -> needs to be in IDE compat mode (bios toggle) and it should work
- keyboard -> I havent written (UHCI/EHCI) only xHCI, but this should work under BIOS SMM legacy emulation (haven't tested this)

So it might work, but I have had many cases were "works on QEMU/BOCHS" does NOT imply "works on metal", metal typically is much more finicky.

Note on installing
1) install a any ancient 32-bit linux distribution (with a MBR), retroos leeches on ext2,3,4 filesystem from linux
2) copy retroos kernel.elf into /boot/retroos
3) add a grub entry (bios variant and not framebuffer)
menuentry "RetroOS" {
insmod part_msdos
insmod ext2
insmod multiboot
insmod vbe
set gfxpayload=keep
search --no-floppy --file /boot/retroos/kernel.elf --set=root
multiboot /boot/retroos/kernel.elf
boot
}
4) make /home/retroos and fill it with your dos apps (its gid, is the group id uses for write allow although writing to ext is currently only enabled on qemu i didnt want to fuck my laptop linux, enable at your own risk)
5) pray

I have been polishing, fixing and improving various things over the past weeks. I think it's approaching the state where hobbyists genuinely feel it can be fun to play with.

VGA emulation is much more solid cga (alleycat/digger/paratrooper/pacman/sokoban), ega (keen, operation wolf, test drive) and tweaked vga-modes (dyna blaster, pinball fantasy,...)
Sound emulation is now vastly better. It now emulates SB16, GUS and also General midi that uses similar wavetable synth as the gus emulator and uses the gus patches (that are free). Sounds pretty awesome.

Future ideas
1) Adding support for networking.
2) Also adding windows 95/98 (and later) support
3) Making the linux part complete enough that the linux distribution it currently leeches on becomes usable.
4) Adding 3dfx support
5) Optimizing some paths, page faults necessary for mode-x and general protection faults for IO are brutal and might need special paths. Currently I've tried to prevent special cases and alternative paths.

Also if people have fixes feel free to make a PR, if there are hardware issues codex/claude is typically able to solve those in 30min. Or if there is a problem I would appreciate a ping/log or explanation here in this forum or on my github.

Awesome, thanks for the answer!

In the meantime I tried to move along with it.
It's not baremetal yet, but with the help of Codex CLI I managed to compile and run the whole thing in WSL2 on a Ubuntu 24.04 Docker baseimage (no sound yet, but I'm sure that's just a step away figuring out the necessary QEMU flag).

inagy wrote on 2026-07-27, 09:18:

Awesome, thanks for the answer! […]
Show full quote

Awesome, thanks for the answer!

In the meantime I tried to move along with it.
It's not baremetal yet, but with the help of Codex CLI I managed to compile and run the whole thing in WSL2 on a Ubuntu 24.04 Docker baseimage (no sound yet, but I'm sure that's just a step away figuring out the necessary QEMU flag).

The run script should work out-of-the-box

./run.sh qemu --sound (sb/ac97/hda)

--firmware (uefi/bios) be careful uefi means vga is emulated and necessitates trapping all video mem access in planar-vga modes
--kvm (if running in a kernel with virtualization this helps for uefi)
--arch (386/686/x64)

hda and ac97 are not available in 86box and bochs.

./run.sh (bochs/86box)

gsos wrote on 2026-07-27, 03:29:

I give it a solid chance it might work. Your hardware is still fully BIOS, so vga/svga will be good and RetroOS will just use th […]
Show full quote

inagy wrote on 2026-07-26, 15:53:

Super interesting project. […]
Show full quote

Super interesting project.

How difficult is it to make this run on real hardware? I have an old D945GSEJT motherboard lying around, waiting to be put to use. It is now too old, and with its 32-bit CPU, it is difficult to run any recent Linux distro on it.

Its hardware, including the GMA950 and ICH7M, is not very MS-DOS-friendly. However, nowadays we have VSBHDA, and it likely supports the basic VESA video modes required by most MS-DOS games. Running Windows 98 is still impossible because compatible drivers are unavailable.

If I understand correctly, this project can replace some native hardware components with emulated legacy equivalents. It also preserves native CPU execution paths where possible, so it does not incur the overhead that a full-blown VM or PCem-style emulator would have on the same hardware.

I know this is very far away in the future, but could this also make it possible to emulate additional advanced hardware, such as running a Voodoo software rasterizer on a secondary core of a modern multicore CPU that would otherwise sit idle while DOS is running natively?

I give it a solid chance it might work. Your hardware is still fully BIOS, so vga/svga will be good and RetroOS will just use that. Listing
- cpu -> excellent (supports VME + plenty powerful for emulating GUS and nice General MIDI (doom + duke3d + dark forces will have nice music)
- firmware -> classic bios (= retroos happy case)
- video -> supports classic vga (= happy case)
- audio -> hda, RetroOS supports hda and works on QEMU and my high-end modern laptop (which is harder to get right then your case) but I havent tested this at all
- hdd -> needs to be in IDE compat mode (bios toggle) and it should work
- keyboard -> I havent written (UHCI/EHCI) only xHCI, but this should work under BIOS SMM legacy emulation (haven't tested this)

So it might work, but I have had many cases were "works on QEMU/BOCHS" does NOT imply "works on metal", metal typically is much more finicky.

Note on installing
1) install a any ancient 32-bit linux distribution (with a MBR), retroos leeches on ext2,3,4 filesystem from linux
2) copy retroos kernel.elf into /boot/retroos
3) add a grub entry (bios variant and not framebuffer)
menuentry "RetroOS" {
insmod part_msdos
insmod ext2
insmod multiboot
insmod vbe
set gfxpayload=keep
search --no-floppy --file /boot/retroos/kernel.elf --set=root
multiboot /boot/retroos/kernel.elf
boot
}
4) make /home/retroos and fill it with your dos apps (its gid, is the group id uses for write allow although writing to ext is currently only enabled on qemu i didnt want to fuck my laptop linux, enable at your own risk)
5) pray

Do beware that various things don't exist on a 80386 (and 80486), like VME(Pentium and up) you mentioned, as well as CR0.WP(486+). The same for all the newly added stuff at the Pentium (CPUID and all it's reported features that don't exist on a [3/4]86).

BinaryDemon wrote on 2026-07-14, 08:25:

A super interesting project. I’m curious about the bare metal, the ram requirements are similar to MSDOS? Not sure I’ve ever seen a 386 with less than 2mb, but if the system only had 640kb ram would it still load and have enough memory to run stuff like Wolf3D / Prince / Keen?

There's the Compaq DeskPro 386, with a minimum of 1MB memory (640KB base+386KB mapped high with ROM (shadow RAM for BIOS ((F)E0000-(F)FFFFF) and remainder I don't remember atm, I think it was at 15MB+)). Also the first 386-compatible machine.

superfury wrote on 2026-07-27, 17:19:

Do beware that various things don't exist on a 80386 (and 80486), like VME(Pentium and up) you mentioned, as well as CR0.WP(486+). The same for all the newly added stuff at the Pentium (CPUID and all it's reported features that don't exist on a [3/4]86).

I know, that is why it needs testing on real hardware. But I did try to be careful. My arch abstraction turns non-vme cpu's into vme cpu's from the kernel pov (ie. it handles the non-vme stuff internally so it just seems to work). Also it tries to handle wp, pae, x64 carefully so that only cpu's that are capable are using it. I rely mostly on 86box to see if it works correctly, which is a pretty accurate emulator. That said, I'm sure there will be failures on real hardware, but with codex/claude those will be likely relatively easy to fix. I welcome fixes like that.

gsos wrote on 2026-07-27, 16:43:

The run script should work out-of-the-box

./run.sh qemu --sound (sb/ac97/hda)

Thank you!

So the problem here was the PulseAudio emulation of WSL2, which needed some changes in the environment variables passed to QEMU. After that it was working just fine, there's sound.

In the meantime I've managed to build a hdd img file for QEMU which boots using GRUB and stays in BIOS videomode. Hopefully I can just take this and flash it onto the HDD of my Intel board.

What I found out is that VESA LFB modes are not working because the VGA framebuffer memory (QEMU and likely on the Intel board as well) is in an PCI BAR area currently unmapped by the DPMI part of RetroOS (if I understood it correctly), but Codex managed to extend the necessary BIOS calls (mapping, pallette mode setting), to my surprise this change made it run Duke3D in full 800x600 with very decent speed 😀

Hopefully I'll have time at latest next week to setup the Intel board and do a test on real hardware.

So far what Codex did is up in my fork, but got to be honest, low level x86 code is not expertise, so I have no idea how good the code it is. And also it's currently mixed with all the other research stuff I made with it. (While testing I found a bug related to Sound Blaster timing which makes Duke3D crash reproducible, that's in a Markdown file, as I was planning to to see if Codex could solve it or not). Anyway, the changeset so far: https://github.com/gerben-stavenga/RetroOS/co … :RetroOS:master
I don't know if you planning on accepting contributions, if you think it's worthwile, I could try to turn them into separate PRs.

Thanks! I merged in your DPMI mapping routines and added an acknowledgement of your contribution in a contributors.md.

The palette stuff i didn't take as that is a seabios bug, that got fixed. I added a newer seabios.rom in third_party and instructed run.sh to start qemu with that rom so palette is now correct without dpmi override hacks.

I also updated the boot process so that the same kernel will now correctly use bios with grub if bios is present, so no need have the extra kernel_grub_bios target.

I'm aware of the duke3d irq issue. I'm sure I'll fix that soon.

That's great. 😀 I've also validated and replacing the QEMU SEABIOS indeed solved the SVGA palette issue.

I've managed to create a HDD image and transfer it over to the Intel board. The good news: it boots.

If GRUB hands over text mode and let the hardware VGA do the heavy lifting, I can play in 320x200, DUKE3D runs just fine. But not VESA modes detected.
If I make GRUB initialize a framebuffer, I see the start messages but DOS Navigator never starts, though I can kill it from the F12 OSD menu still.

Also there's no audio, I don't see any printout regarding that as I see on the QEMU startup. Checked and I didn't accidentally disable the onboard codec in the BIOS. So I guess it's just not detected by the kernel.

I'm thinking about somehow creating a GRUB TFTP boot setup around the SEJT (probably with a Raspberry Pi 4), so I could quickly iterate with new kernels and don't need to swap SD cards. Sadly I don't have much time in the upcoming days.

Hey @inagy,

Okay, I (with some help from Codex) reworked HDA discovery to support legacy interrupts and updated the logging to include early boot messages.

C:\PROC\KLOG.TXT should now contain details about the hardware being detected. If sound still doesn’t work, that log may give us a useful clue.

Since your setup involves flashing an SD card, I assume you’re not concerned about RetroOS modifying its filesystem. With the latest version from GitHub,
add this argument to your GRUB entry:

multiboot /retroos/kernel.elf disk-writes=persistent

RetroOS should then allow persistent writes to the card. You can us Dos Navigator to copy C:\PROC\KLOG.TXT to C:\KLOG.TXT, reboot into another OS, and send or inspect the resulting file.

I did some code clean up. Bios path and uefi path and native soundblaster vs emulated became unwieldy, now these differences are handled more uniform.

- OSD (OS display overlay) now works with both bios and uefi. This allows killing/switching threads/volume control and profiling/debuging control over a thread.
- Switching between threads is better supported in presence of soundblaster state.
- Removed the tarfs, boot now needs to be correctly specified in the filesystem. This helps with kernel.elf binary size.
- Added voodoo support (ported mame). Needs testing/i tested glide sdk examples. i need to buy a voodoo dos game.

gsos wrote on 2026-07-27, 17:31:

I know, that is why it needs testing on real hardware. But I did try to be careful. My arch abstraction turns non-vme cpu's into […]
Show full quote

superfury wrote on 2026-07-27, 17:19:

Do beware that various things don't exist on a 80386 (and 80486), like VME(Pentium and up) you mentioned, as well as CR0.WP(486+).
The same for all the newly added stuff at the Pentium (CPUID and all it's reported features that don't exist on a [3/4]86).

I know, that is why it needs testing on real hardware. But I did try to be careful.
My arch abstraction turns non-vme cpu's into vme cpu's from the kernel pov (ie. it handles the non-vme stuff internally so it just seems to work).
Also it tries to handle wp, pae, x64 carefully so that only cpu's that are capable are using it.
I rely mostly on 86box to see if it works correctly, which is a pretty accurate emulator.
That said, I'm sure there will be failures on real hardware, but with codex/claude those will be likely relatively easy to fix. I welcome fixes like that.

Some late 80486 do have VME, as well as CPUID..

"The Pentium architecture added a number of enhancements to the virtual 8086 mode.
These were however documented by Intel only starting with the subsequent P6 (microarchitecture);
their more recent formal name is Virtual-8086 Mode Extensions,
abbreviated VME (older documentation may use "Virtual 8086 mode enhancements" as the VME acronym expansion).
Some later Intel 486 chips also support it.
The enhancements address mainly the 8086 virtualization overhead, with a particular focus on (virtual) interrupts."

https://en.wikipedia.org/wiki/Virtual_8 ... ions_(VME)

PS: Also interesting is the difference between how CS register of the 386/486 and 586 CPU behave after entering Protected-Mode.
The behavior of the 586 BIOS has big influence on backwards compatibility.

https://www.os2museum.com/wp/maximum-overkill/

Edited.

It's great, the treasure trove of technical information and historical reasons here on this forum. I did not know about the CS issue.

I've mainly been polishing and bug fixing, I added a video https://www.youtube.com/watch?v=gNR5KuIyKNQ demonstrating the 3dfx support on the tomb raider 3dfx demo.

I was thinking the next project could be to factor out the dpmi, xms, ems part from retroos so it can be compiled into a single "jemm"-substitute that could be used to provide xms,ems,dpmi at once for dos/freedos. together with the 3dfx, sound blaster, general midi and gravis ultrasound emulation.

The second project is similar but make a retroos.efi that would allow booting freedos on uefi-only system, with retroos providing the vga services.