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 Yesterday, 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.