[Qemu-devel] [Bug 1180923] Re: unused memory filled with 0x00 instead of 0xFF

[Battler]

>>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