>>But you're supposed to use e820 or other mechanisms to retrieve the proper >>memory layout from the firmware. Well go back to the early 1990's and tell Microsoft and IBM that. :p DOS as it is, refuses to recognize memory not filled with 0xFF's as free. It instead thinks such memory is used by Option RAM. On Qemu 0.9.1, I got around the issues by padding the video BIOS with 0xFF's to the 64 kB boundary, and using the relevant option to load a a 64 kB .BIN file full of 0xFF's as an option ROM, as well as using the BOCHS legacy BIOS which has the first 64 kB filled with 0xFF's, thus getting D000-EFFF + from about CA00 or so to CFFF filled with 0xFF's, making DOS work correctly. But on Qemu 1.x and later, this no longer works. Well, the video BIOS padding does work, but I am unable to load an option ROM like in 0.9.1. Also, for some reason, all Qemu VGA BIOS'es are bigger than 32 kB, even the ones for CL-GD 5446 and VMWare SVGA II., even though the real CL-GD 5446 and VMWare SVGA II. BIOS'es are both 32 kB. This messes with the working of Windows 3.0 which expects segments C800-CFFF to be free.
-- 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
