It is interesting how what worked flawlessly on the hardware of the time is almost impossible to get to work on these emulators, the fidelity is quite low. But bit by bit I'm making progress in figuring out where the differences are and how to work around them. I've got a basic self-hosted development system working now with all of the data in a ram disk. The floppy, keyboard and VGA screen all work, now I need to figure out why the harddrive controller keeps disappearing.
Oh well, the night is young ;)
Thank you for posting this! It really moved the needle in what already was a super long debug session.
Also if you look at qemu's device emulation, that's usually "done" when it can run modern operating systems. Qemu doesn't try hard to emulate the entire IDE or SCSI command set in every detail, or every aspect of old hardware.
Another thing is that qemu is not cycle-accurate at all. Instruction and device timings will be wildly different from real hardware, especially if using TCG.
My development system is a ramdisk right now and that feels a bit scary.
So what is? One would need software supporting debugging. VirtualBox supports that I think, but I don’t know if that works if it runs on top of Hyper-V - which is enabled by default in Windows due to some security features (and I don’t want to disable that anyway).
It is the right software. It's not even debatable: qemu is the one most used for OS development by an order of magnitude difference or more.
It's a marvelous piece of engineering which is slower than others, but that's the price to pay for accuracy.
In fact, (having worked for quite a while in supporting decades old enterprise software) my experience with most PC virtualizers and emulators is that they're ridiculously accepting of errors that will most definitely trigger random behavior in (at least some) real hardware.
For me, the fact that Windows 95/98 can't use the HLT instruction is a reason why I wouldn't use these legacy operating systems to run older software. Not that many programs ran on Win95/98 but not on Win2000. Perhaps except for DOS games, which are better served by DOSBox.
In addition, MS was quite happy to ship advanced but dangerous features to customers only hidden behind user-accessible plain checkboxes. One example that comes to mind is the "DMA" checkbox in the IDE controller settings page. Guaranteed to corrupt your data and render your system unbootable on certain hardware (likely a worse scenario than anything HLT could potentially do to you), and at most you get a warning box claiming this may happen when you enable the checkbox.
Most likely, MS knew it was trivial (due to the design of DOS-based 9x/ME) for a 3rd party to ship either a utility or even a BIOS addition to do HLT-on-idle (and in fact, most laptops would do so in their APM BIOSes), so the problem didn't appear to them to be significant at all (and, frankly, really wasn't a significant problem at all). Not so much for e.g. DMA which would require a new driver replacement.
haunter•4mo ago
rzzzt•4mo ago
For absolute positioning a USB input device is emulated, so this might not work in Windows 98 without a suitable driver: https://docs.getutm.app/preferences/ios/#cursor
AshamedCaptain•4mo ago
pdntspa•4mo ago
Most non-multitouch touchscreen devices emulate a mouse if there is not a more specific driver available. Trackpads were widely available on laptops at the time and you could jump to any point on the screen with those.
You can click but don't expect any gestures to work.