3 ms·

Why Dosbox/Dosbox-X instead of qemu or VirtualBox in general? Dosbox and Dosbox-X focus much more heavily on accurate emulation, rather than fast virtualization

by bri3d 2y ago

Why Dosbox/Dosbox-X instead of qemu or VirtualBox in general? Dosbox and Dosbox-X focus much more heavily on accurate emulation, rather than fast virtualization. Peripherals are implemented to match the original period-correct hardware, rather than as a "good enough" view or cooperative facade requiring guest support. Weird CPU errata (like specific carry register behavior) is implemented. Why the author chose Dosbox-X to try to run Windows XP? It sounds like Because They Can.

smaudet 2y ago
Ooh. This makes me very much want to tinker with DosBox myself. Qemu can IIRC do similar things with drivers but possibly because it was co-opted to run android emulator imgs (which are all very standard and boring), it seemed difficult to tinker with custom drivers and emulated hardware. The above could just be my own inexperience talking, but examples are one of the best ways to learn, if DosBox-X takes extra care that's noteworthy at least.
zamalek 2y ago
> Because They Can. It's probably also a great way to find bugs.
Dwedit 2y ago
Unfortunately, CPU accuracy is not one of DOSBox's focuses. If you install the "Recommended" build of DOSBox-X from the website, then proceed to install the default "Visual Studio build (64-bit)", you get buggy and inaccurate CPU emulation. How do you know it's buggy and inaccurate? Run QBasic, and PRINT VAL("5"). You get 4.99999999999. But... You get the correct result if you are using a 32-bit build. You get the correct result on all non-MSVC builds. You get the correct result if you have the Dynamic core selected, even on 64-bit MSVC builds. It's just 64-bit MSVC builds with any core other than the Dynamic core that give the wrong result. So what's going on here? MSVC 64-bit doesn't support 80-bit floating point math, and doesn't allow you to use inline assembly to manually run the 80-bit floating point instructions. Instead, floating point operations are truncated down to 64-bit. I think that the MSVC 64-bit build should NOT be the default build recommended to users for just that reason.
deleted 2y ago
[deleted]

by bri3d 2y ago

smaudet 2y ago

Ooh. This makes me very much want to tinker with DosBox myself. Qemu can IIRC do similar things with drivers but possibly because it was co-opted to run android emulator imgs (which are all very standard and boring), it seemed difficult to tinker with custom drivers and emulated hardware. The above could just be my own inexperience talking, but examples are one of the best ways to learn, if DosBox-X takes extra care that's noteworthy at least.

zamalek 2y ago

> Because They Can. It's probably also a great way to find bugs.

Dwedit 2y ago

Unfortunately, CPU accuracy is not one of DOSBox's focuses. If you install the "Recommended" build of DOSBox-X from the website, then proceed to install the default "Visual Studio build (64-bit)", you get buggy and inaccurate CPU emulation. How do you know it's buggy and inaccurate? Run QBasic, and PRINT VAL("5"). You get 4.99999999999. But... You get the correct result if you are using a 32-bit build. You get the correct result on all non-MSVC builds. You get the correct result if you have the Dynamic core selected, even on 64-bit MSVC builds. It's just 64-bit MSVC builds with any core other than the Dynamic core that give the wrong result. So what's going on here? MSVC 64-bit doesn't support 80-bit floating point math, and doesn't allow you to use inline assembly to manually run the 80-bit floating point instructions. Instead, floating point operations are truncated down to 64-bit. I think that the MSVC 64-bit build should NOT be the default build recommended to users for just that reason.

deleted 2y ago

[deleted]