Qemu enters the 1.7 testing phase

I built 1.7rc2 on OSX, and I’ve only tested the x86 portion… x86_64 of course still fails on vista & friends… 2003 of course hangs at “starting windows” so no progress there.  I haven’t tried any MIPS, PowerPC, or SPARC things…

Also the Adlib/SoundBlaster is still broken in this release, there is a source change in adlib.c that has to be made.  Also I just noticed that IRQ sharing works in ISA mode again, so the Ne2000 can go back to 0x300 IRQ 9.

Also speaking of emulation, I was thinking of shoving a VAX-11/780 into the world for the heck of it.  Although I don’t think anyone would care.  I’ll have to dig out the source to 4.3 and give the shell the ability to add new users.  I wrote it once, and I fear I’ve lost those changes but it was cool for something back then.

Anyways post back here if you want an account on vax.superglobalmegacorp.com !

18 thoughts on “Qemu enters the 1.7 testing phase

  1. For some reason, Windows 9x (either 95, 98 or ME) fails to run qemu versions above 1.2.2, I tried a build of win95 named 189 and that bsods with exception 0A in vmm:lcode.

  2. The only thing that i can now say about QEMU, is that their involvement with KVM and their actual focus in being a Linux-only VM is shitting the whole thing, to the point that in the future this will end really becoming a Linux-only virtualizer.

    QEMU probably is still the only way to run ancient non-x86 systems and strange platforms. But unfortunately, today QEMU isn’t what it was :-(…

    • It’s a shame about NeXTSTEP & Netware no longer running… and its just beyond me to fix. I almost wonder if its easier to ‘fix’ PCem?

      I almost got it to boot OS/2 2.0 XR6100 … I got the hourglass desktop… And I like how it runs 286/386/486 BIOSes..

  3. Today there are better system emulators for x86 than QEMU out there, like PCEm.

    For NeXTSTEP probably there are still hopes, in the form of Previous-VM:


    But for other rare, or ancient system emulations like MS Jazz (MIPS) or IBM 40p (PPC/PReP), the only way is QEMU :-/… Unfortunately, as i said, QEMU as a whole is getting too tied to KVM and *NIX in general, to the point that Win32 builds are nothing but a shame.

    Is strange that, while in any *NIX QEMU works nice and fast, actual win32 builds run slowww, with the same machine and configurations. Also, QEMU dependence in too many Linux shit, like GLib and GTK isn’t pleasant at all.

    • ioport.c

      // DOOM breaks here
      //Assertion failed: (mrp), function portio_read, file /Users/jsteve/src/qemu-1.7.0-rc2/ioport.c, line 182.

      and hw/audio/adlib.c

      it needs to look like this:

      static MemoryRegionPortio adlib_portio_list[] = {
      { 0x388, 4, 1, .read = adlib_read, .write = adlib_write, },
      { 0, 4, 1, .read = adlib_read, .write = adlib_write, },
      { 0, 2, 1, .read = adlib_read, .write = adlib_write, },

      • OMG, that bug is dumb. Your patch however is wrong, the right fix is to change 1 and 2 to 0 and 1 in these lines.

        adlib_portio_list[1].offset = s->port;
        adlib_portio_list[2].offset = s->port + 8;

        Next time please report this on launchpad or the qemu-devel mailing list. I found this blog post entirely by chance.

        • Ah even better… I hope this let’s doom 1.2 and higher run without crashing…

          The lists just ignored me about netware 3.12 not working since qemu 0.90 … Maybe things have changed?

  4. My setup is… crazy.

    uwisc# df
    Filesystem kbytes used avail capacity Mounted on
    /dev/hp0a 7421 5399 1279 81% /
    /dev/hp0g 136603 44401 78541 36% /usr
    /dev/ra0c 1142905 9 1028605 0% /homes/a-f
    /dev/ra3c 1142905 9 1028605 0% /homes/s-z
    /dev/ra2c 1142905 9 1028605 0% /homes/m-q
    /dev/ra1c 1142905 9 1028605 0% /homes/g-l

    I only installed the kernel source code so I could add in larger disks. The UWISC kernel sits between disktabs and kernel hacks. And I think this release is too old for anything like a MVII… You may have to go with Quasijarius.

Leave a Reply