Well about it being an EMM386 problem - no, it's DOS itself that maps the memory incorrectly if it's not filled the way it expects it. EMM386 just asks DOS for a memory map and tries to find the first free segment. But in this case, DOS hasn't mapped any segment as free, so EMM386 is unable to do anything and errors out. Also, I've used a real PCI machine from the late 1990's - a Celeron 333 MHz, and EMM386 worked fine on it. At least segments D000-DFFF were free. That's not the case on Qemu for some reason - I guess Qemu emulates a 21st century PCI machine instead, with no option to make it emulate one from the late 1990's. As for using UMBPCI - I already tried it and it's not compatible with Windows 3.x and earlier. And it wouldn't change much anyway since it's not the EMM manager that probes the memory but DOS itself. This is why MSD is able to show a memory map of the upper memory even when neither HIMEM nor EMM386 are loaded.
-- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1180923 Title: unused memory filled with 0x00 instead of 0xFF Status in QEMU: New Bug description: Qemu, ever since it was made (so, since 2003), has this problem in DOS (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the memory available when the memory is filled with 0x00 but when it is filled with 0xFF it gets recognized properly, where should I patch qemu to solve this memory problem? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1180923/+subscriptions
