Good news on the QEMU fronts!

First I found this blog post about building Qemu with CLANG instead of GCC, and I didn’t  even run it through google translate, but I had a feeling that it must work because there is simply too much text there for something that doesn’t work… Although it is with the TCG interpreter…

Qemu 1.1.0-1 on OS X 10.6.8 via clang!

And sure enough it works! (well so far I’ve only booted the IBM PS/1 MS-DOS 4.00 image I had handy. But that is good news for me as I’m planning on shifting away from running Windows all the time, and it was annoying having this powerful mac pro, but not being able to run / play with Qemu.

The move the clang would make sense as I under stand it Apple is moving away from GCC at any rate.

Also on the road to a non TGC build of Qemu I did find out the compiler included on the 10.6.3 DVD works while the later IOS update one does not…

Using built-in specs.
Target: i686-apple-darwin10
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/src/configure –disable-checking –enable-werror –prefix=/Developer/usr/llvm-gcc-4.2 –mandir=/share/man –enable-languages=c,objc,c++,obj-c++ –program-prefix=llvm- –program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ –with-slibdir=/usr/lib –build=i686-apple-darwin10 –enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/dst-llvmCore/Developer/usr/local –program-prefix=i686-apple-darwin10- –host=x86_64-apple-darwin10 –target=i686-apple-darwin10 –with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

GCC for update for IOS 5 … which doesn’t build a working Qemu exe

Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646~6/src/configure –disable-checking –enable-werror –prefix=/usr –mandir=/share/man –enable-languages=c,objc,c++,obj-c++ –program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ –with-slibdir=/usr/lib –build=i686-apple-darwin10 –with-gxx-include-dir=/include/c++/4.2.1 –program-prefix=i686-apple-darwin10- –host=x86_64-apple-darwin10 –target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646)

While the one that does come on the 10.6.3 DVD works fine.

Next up for all those of you on Windows or Win32 i386 platforms, rainbow has kindly provided a Win32 build of Qemu, which you can download from his site!  Ive booted MS-DOS on it from within VirtualBOX and it seems to work fine!

One thing I’ve noticed about 1.1.0 is that it cannot read low density 3 1/2″ disks!!!!

7 thoughts on “Good news on the QEMU fronts!

  1. Qemu 1.1.0 not reading low density 3 1/2″ disks? That’s terrible! 🙁

    But other than that, Qemu 1.1.0 is working good.

    Anyways, I’m wondering if it’s possible to port your modified patches from Qemu 0.15.1 onto Qemu 1.1, plus add three more patches per my feature request:

    1. Add a patch with the ability to boot from a SCSI hard disk, if it is possible. Official versions of Qemu don’t have the ability to boot from a SCSI hard disk.
    2. Add Tseng ET4000 and S3 Trio 864 VGA adapter support, if it is possible.
    3. Try to port Miroslav Novák’s Qemu Break patch for slower games.

    If this isn’t possible or if you don’t have the time to do it, let me know.

    I remember booting Windows 3.1 off of a 1.08 GB SCSI hard disk with 8 MB of memory on a 66 MHz 486DX2 based PC back between early 1994 to mid 1995. I tried to run MS-DOS off of a SCSI hard disk under VMware Player, but ran into bugs, including a Sector Not Found error message, plus Windows 3.1 wouldn’t even start properly.

    The Tseng Labs ET4000 is a really popular VGA adapter that is designed to run Windows 3.0 in SVGA resolutions as this feature is currently found in DOSBox and in MESS emulators and I was wondering if there is a way to port it to Qemu.

    As for Windows 3.1, I still don’t know if the Cirrus VGA adapter is still broken, but I’m wondering if it’s possible or not to port the S3 Trio 864 VGA (currently found in DOSBox) capabilities to Qemu.

    And lastly, I’m wondering when the ISA features are going to work. When I use the -m isapc parameter, nothing displays on the Qemu VM for some reason. 🙁

    • ISA has been broken for years.. dont hold your breath.

      Also your binaries can’t read my Qcow2 disks!!

      qemu-system-i386.exe: -hda os2.disk: Header extension too large
      qemu-system-i386.exe: -hda os2.disk: could not open disk image os2.disk: Invalid
      argument

      I’m going to have to test this some more…

      I think the one thing that may have stopped you from booting from SCSI is a lack of a SCSI bios…? Search my site, I did some NT machine with way too many SCSI disks.. lol

      I’ve backported the ISA video card in Qemu, and even dumped a real BIOS into it that worked ‘better-ish’ than the PCI/Free BIOS .. Windows 95 liked it.

      Also the break patch was for a way older version, and QEMU has changed far too much over the years…. :/

      I wouldn’t know where to start with the Tseng stuff.. but I know there are a few emulators that support it… I’d also LOVE Etherlink II / 3com 3c503 support … !

      • Well its not just your build, the one I just built on OS X is incapable of reading any of my qcow2s!! I used 0.14 to convert them to VMDK and I can boot… kind of.

        I was able to play DOOM under OS/2 2.0 with full sound (you have to enable adlib in the configure phase!) … but no networking… The NE2000 doesn’t seem to be working.

        • Again, I would like to state that the Windows Qemu builds are done by Eric Lassauge.

          I’ve tested the NE2000 PCI driver under MS-DOS and it worked without problems.

          With Qemu 1.1 not being able to read low density floppies and other problems that are occurring, I think that there are a lot of bugs that need to be ironed out for sure. 🙂

      • Well…I found that booting from SCSI now works properly with Qemu 1.1! I was able to boot MS-DOS from a SCSI drive with some minimal problems. Dr. Watson reported an exception number c0000094 (divide by zero) error messages at randon when running DOS on a SCSI hard disk.

        As for running Windows 3.1 with the defective Cirrus drivers in higher resolutions, it was a no go as I’m running into display corruption issues.

        The only thing that worked was to run Windows 3.1 was to either run that OS with the Cirrus CL-GD-5446 drivers running at 640 x 480 with 16 million colours (-vga cirrus) or use the generic 256 colour drivers (up to 1024 x 768 resolution) using the VMware VGA driver (-vga vmware) with 8 MB of video memory. 🙁

        The usage of Cirrus drivers for emulation in Qemu under Windows 3.1x, Windows 9x and NT have gotten worse since Qemu 0.10. To be more specific, ISA support has been broken since Qemu 0.9.1 and it could be removed someday if any bugs found are too hard to fix.

        The official Windows Qemu 1.1 binaries that I linked to are NOT mine, but is maintained by Eric Lassauge who develops the official Windows Qemu builds.

        As for the Tseng ET4000, since the vgabios-isacirrus.bin is designed for Windows 9x, I’m wondering if we could have vgabios-isatseng.bin (aka et4000.bin) as a replacement for the defective Cirrus drivers running on Windows 3.0 and Windows 3.1. If users want to run Widnows 3.x under Qemu with the Tseng drivers, if it is implemented, it would be run with the “-vga tseng” parameter.

        I would really love support for Tseng ET4000 on Qemu if it is possible. One user in the Bochs x86 PC tracker has suggested to add the chipset, possibly in future versions of Bochs: http://sourceforge.net/tracker/index.php?func=detail&aid=3520768&group_id=12580&atid=362580

        The Tseng ET4000 chipset is a popular ISA-based video card that originally has 512 KB of display RAM and it’s expandable to 1 MB. With 1 MB of video memory, you can run both Windows 3.0 and Windows 3.1 with a resolution of up to 1024 x 768 at 256 colours.

        I kinda liked the idea of having the ISA Cirrus video card in Qemu. I haven’t tested running Windows 95 yet with the defective Cirrus drivers or the VMware driver yet.

        I just need to look over the patch to see how it can be done. 🙂

        Lastly, for the Qemu Break patch, it was only designed for Qemu 0.9.0 and attempting to do a newer version for the latest version of Qemu would be too much work. I believe that it’s simply not possible to find ways to get games that run too fast under Qemu to slow down without having to excessively consume too much CPU.

Leave a Reply