Qemu 5 was recently released

Posted on by

It’s been jumping numbers like crazy, and I’m still holding onto 0.9 because I’m weird. Anyways there is something amazing hiding in all those release notes and stuff:

68040!

The m68k emulation is good enough to run Linux! Granted the target machine is the Macintosh 800, although the Mac ROM doesn’t boot enough to do anything Apple enough, using a serial console however does get us into the system. On my ancient Mac Pro I get emulation in the speed range of a 1Ghz G4!

root@qemu68k:~# cat /proc/cpuinfo 
CPU: 68040
MMU: 68040
FPU: 68040
Clocking: 1304.9MHz
BogoMips: 869.99
Calibration: 4349952 loops

Absolutely amazing!

Installation is a bit tricky as there is no true bootrom / boot process, so I had to load the installer with a dummy ‘raw’ disk, and tar the kernel & initrd to that raw disk so I could later extract it on the native OS to boot into the disk. I followed mostly the instructions here.

And what is that? NeXT CUBE emulation?

The peripherals are nowhere near complete enough to boot, HOWEVER it does boot the PROM, complete with keyboard support.

qemu-system-m68k -M next-cube -bios Rev_2.5_v66.BIN

It’s fun enough to play with. And thanks to Qemu’s fast emulation, perhaps this is a speedy way to run stuff in the future?

Now isn’t that cool?

25 thoughts on “Qemu 5 was recently released”

  2. It’s always nice seeing retro systems get so much love from the QEMU devs. Maybe someday it will be able to emulate SGI hardware and run IRIX.

  3. I tried the macOS version of QEMU 5.0, I couldnt boot Windows 10, but I managed to boot Windows 2000. I was just disappointed to see that there is no really powerful gpu emulation for that machine (i386). Unless I should have tried to boot using x86_x64 instead, I did not see any improvement over my VMware Fusion Win2k VM that has only 64mb of vram (*sighs*).

    That was my first experience with QEMU and I must say it was quite a nightmare to learn how to boot it. Although I am tech-savvy enough to use command line, I wasn’t really comfortable doing that for a VM.

    • Qemu is… Always been klunky to be honest. I’m surprised it didn’t boot 10, although it may require an incredible amount of command line flags.

      I’ve only booted a NeXT ROM, Linux m68k, and Mach 2.6 i386 so far.

      VMware / virtual box will always win. If I had money I’d have invested in making qemu human usable, but SUN already did with virtual box.

      • I think Oracle/SUN (whatever) is losing a good opportunity here. They could take the fight to VMware (forget Parallels, they can’t touch a soft that can let VMs have DX11) if they weren’t stubborn enough to limit the video ram to 256mb. Both VMware and Parallels go beyond 1GB for that. And I also need networking, so DOSBox is out of equation (the easiest method is adding pcap, a NE2000 emulation, and you still need a MITM to act as a “fake” internet provider).

        Did I mention that SB16 emulation in VirtualBox is HORRIBLE? Somehow they managed to break it in 5.22, I had it working in 5.21 before the jump to Catalina. Parallels has no MSDOS drivers for the sound device they emulate (I assume it is some kind of AC97).

        This is why I am stuck with VMware and its frozen svga drivers for older Windows versions. I need DX9 with 3D acceleration/3DFX, for games like FIFA 99, so I can play them at decent speed and patched for widescreen. And I can only get it on PCem, but it is damn, damn slow.

        Yes, VMware always win, but only because their rivals simply suck. Gutted.

  4. I’ve successfully built QEMU git (5.0.50) on MSYS2 under Windows10.
    It boots m68k Linux 4.16.0 (unofficial Debian 10 Sid).
    Unfortunately, there are alot of issues… Windows console is broken
    (doubles all input). Keyboard mapping on the framebuffer console
    is wrong on both backends: SDL2 and GTK displays.
    A “ghost” CD-ROM at ID:2 , kernel warnings at 83932 etherent
    e.t.c. e.t.c.

      • Thank to Laurent Vivier (maintainer of the m68k target in Qemu) framebuffer console kayboard is repaired. In Debian configure the “macintosh” keymap rather than the “macintosh_old” one. Even ATL+Fn “virtual console” switch works except ALT-F4 which closes Windows program 🙂
        (not QEMU issue).

        “Ghost” CD-ROM at ID:02 exists by default on SCSI bus in QEMU.

      • This m68k Linux 4.16.0 (unofficial Debian 10 Sid) has a broken network card ‘macsonic’. It stalled after transferring about 100..200Kb. I even can’t upgrade…

          • You may debug 68000 “natively” now:
            (gdb) disass /rs main
            Dump of assembler code for function main:
            hello.c:
            3 int main () {
            0x800003f8 : 4e 56 00 00 linkw %fp,#0
            4 printf(“Hello, world!\n”);
            0x800003fc : 48 79 80 00 04 7e pea 0x8000047e
            0x80000402 : 4e b9 80 00 03 24 jsr 0x80000324
            0x80000408 : 58 8f addql #4,%sp
            0x8000040a : 42 80 clrl %d0
            5 }
            0x8000040c : 4e 5e unlk %fp
            0x8000040e : 4e 75 rts
            End of assembler dump.

  5. For some reason they decided to drop to PPC PReP platform in Qemu 5.0. It never worked with Windows NT for several reasons, but I really hoped that they would improve this instead of just removing it.

  7. Has anyone managed to compile qemu 5.x on macOS Catalina, and run Windows 10 x64 on it? I even managed to compile (MacBook Pro Late 2013 13-inch, latest Catalina) and run, but the VGA device is pretty bad, I don’t have drivers for it. Another problem is the CPU type, when I use -cpu host it hangs at boot. Then I have to use the default, I can get to the desktop but besides a bad video, I have no sound either. I was only able to use drivers for virtio disk drive and the network card.

      • I see. I can relate and understand. I was just touching the water about modern emulation, kinda like thinking ahead of the ARM Macs transition. It’s highly unlikely that we will have a x86 hypervisor when they arrive, so I am testing the options we have today. QEMU for me might be the best choice for my three VMware VMs: DOS622/Win3x, Win9x and WinXPSP3. I have a Win10x64 VM too, but for two games only. One of these games is Grand Prix 4, that one should run on XP too, but runs better on Win 10 VM for some strange reason.

        • “Good luck” (in the sense of this being very brave.)

          I was wondering what the cost of cross-architecture emulation is to see the feasibility of using a Pi to emulate older Windows systems, and tried PPC builds of OS X on Intel just to see what kind of overheads occur. As far as I can tell, the result is about an 80%+ drop in performance – a 2Ghz processor behaves like a 400Mhz processor. Obviously this is hugely workload dependent – I was trying to run a full OS and measure things like application launch times which mean it’s looking at a lot of new code, but I’m really skeptical that using Win10 on a cross-architecture emulator is feasible. What makes DOS/3x/9x work is they were designed to run in 100Mhz or less.

          • Indeed. These past few days I have been testing something. So far I didn’t manage to have a decent Win 10 VM on QEMU with my Mac, but I’m surprised to see that a Windows XP SP3 x86 build running much better on my 2017 iPad Pro thanks to UTM app, and surprisingly faster than it does on my maxed out 2013 rMBP 13-inch with QEMU. I’m very, very puzzled. Still, not near native speeds like I get from VMware Fusion running the exact same machine, but pretty close.

            ARM Macs are definitely the way to go in the future.

            I won’t even try to make a Win 10 VM on my iPhone X yet alone with a maxed out RPi 4. Microsoft has to up their game now. Linux has been there for years and now macOS testing the same water. Maybe x86 days are numbered now?

Leave a Reply