Using Qemu in 2020

Posted on by

So I wanted to dive back into old BSD, and I wanted to use the new native Qemu on OS X. That means having to “learn” the new crazy syntax that has drifted a LOT over the last 10+ years.

I want to run NetBSD 1.0 and tear into the GCC 2.x patches required back in the day

In the old days, I was using Qemu 0.13 and had it working using the following:

qemu.exe -L pc-bios -hda netbsd-1.0.vmdk -net nic,model=ne2k_isa -net user -redir tcp:42323::23 -m 64 -no-reboot  -rtc base=localtime -k en-us

Thankfully I was using VMDK containers, probably as I’m sure I installed it under VMware, with it’s better floppy support, but pulled it back to Qemu to have NE2000 support. Now let’s look at the dmesg to where the source of the problem is, the network card:

NetBSD 1.0 (QEMU) #0: Thu Sep 22 06:45:37 PDT 2016
    [email protected]:/usr/src/sys/arch/i386/compile/QEMU
CPU: Pentium (GenuineIntel 586-class CPU)
real mem  = 67764224
avail mem = 62312448
using 852 buffers containing 3489792 bytes of memory
pc0 at isa0 port 0x60-0x6f irq 1: color
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
lpt0 at isa0 port 0x378-0x37f irq 7
wdc0 at isa0 port 0x1f0-0x1f7 irq 14
wd0 at wdc0 drive 0: 1023MB 2080 cyl, 16 head, 63 sec <QEMU HARDDISK>
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
fd0 at fdc0 drive 1: density unknown
pci0 at isa0 port 0x0-0x665: configuration mode 1
pci0 bus 0 device 0: identifier 12378086 class 06000002 not configured
pci0 bus 0 device 1: identifier 70008086 class 06010000 not configured
pci0 bus 0 device 2: identifier 11111234 class 03000002 not configured
ed0 at isa0 port 0x320-0x33f irq 10: address 52:54:00:12:34:56, type NE2000 (16-bit)
npx0 at isa0 port 0xf0-0xff: using exception 16
biomask 4040 netmask 412 ttymask 12
changing root device to wd0a

So the important thing here is that the NE2000 is the ed0 device using an IO of 0x320 and IRQ 10. I’m pretty sure back then I cheated, and just recompiled Qemu to remove the default definition that doesn’t work properly with trying to share IRQ 9.

Keeping this in mind, let’s build this for the new Qemu:

qemu-system-i386 -net none -device ne2k_isa,iobase=0x320,irq=10,netdev=ne -netdev user,id=ne,hostfwd=tcp::42323-:23 -drive file=netbsd-1.0.vmdk,if=ide,index=0,media=disk,cache=writeback,format=vmdk -rtc base=localtime -k en-us

So the first important thing is to disable any/all defualt NIC’s with the ‘net none’ flag. Next to add in the NE2K_ISA type device manually so I can specify the iobase & irq manually. Note the netdev as this is used to tie in the emulated device, to the backend that will process the packets. The next part is the redirect to have the host listen on port 42323 and redirect them into port 23 of the VM. Again the syntax to redirect ports has drifted significantly. The hostfwd now is bound directly to the netdev user, in this new syntax it allows for multiple NIC’s to be bound to multiple user NAT’s if needed.

-device ne2k_isa,iobase=0x320,irq=10,netdev=ne -netdev user,id=ne,hostfwd=tcp::42323-:23

The next ting is the hard disk, before ‘hda’ worked fine, although like everything else that is subject to change in the future, so dealing with it now, use the drive flag:

-drive file=netbsd-1.0.vmdk,if=ide,index=0,media=disk,cache=writeback,format=vmdk

It could be my personal opinion but the drive syntax, although much longer is easier to work with. The key parts being what interface to use (IDE), and what port/index to plug the device in (0), along with the media type, the cache strategy, along with the encoded format, which is more so important when dealign with RAW devices, as unidentified media will be tagged as raw, however it’ll be mounted read-only unless it is directly specified as above.

For additional fun, the serial port can be set to a MS Mouse port, although I haven’t tested it as of yet.

-serial msmouse

Have fun QEMU’ing!

9 thoughts on “Using Qemu in 2020”

  1. Sounds fun. I have two vintage VMs, DOS622/Win3.11 and Win98 for gaming on both VMware and UTMapp (QEMU gui on iOS) and I have been trying hard to understand that syntax for a bit more modern VMs such as Win XP and 7, using homebrews QEMU 5 on my Mac. Not having very good luck so far in terms of speed.

    I also plan to try and build old macOS Snow Leopard and System 7 or macOS 9.x with QEMU just for fun. I’ve never used the last two as a kid. What about OS/2 Warp? I remember my dad using it one day. All I want is to ditch VMware for good and understand better the QEMU things. The only reason I am still on VMware is because of Grand Prix 4 game, supposed to run on XP with ease (as a kid, I do remember playing it with XP!!) but it could only run in W10 VMware VM. Oh dear.

    Anyway I’m able to play GP2 and GP3 which is awesome for now. And trying to find time, peace and concentration to remember how I used to code things in VB3 with Win3.11.

  2. I’m not much of a fan of the new Qemu syntax. The old syntax for specifying drives was much more terse, whereas now I have to remember the extra words to tell it it’s a raw disk image instead of it just guessing that. Also the default NIC has meant that I accidentally exposed something to the Internet that I didn’t want to, and it’s not as simple as putting a wrapper script around it because I have a lot of different versions floating around.

    • Yes it is… kind of showing off why you have gigabytes of stuff to orchestrate command line flags now.. This isn’t even touching things like differential disks, and things like shared memory busses and all the other fancy stuff.

      I’m getting into the “-net none” type habit as of late, along with turning off serial & parallel as it just wastes resources.

      Qemu doesn’t care about legacy stuff, so we are always at their trendy whims.

  3. Sorry, I am coming late to this post, but I also wanted to chime in here. I’ve actually had good luck with the newer versions of QEMU, though stability and speed really seems to depend on what you are doing. For example, for reasons I can’t quite understand FreeDOS seems very sluggish (which seems counterintuitive to me, but whatever.)

    I just wanted to add that I recently adapted Michael Engel’s NeXT busmouse patch to the newest release candidate (5.1.0-rc3). With the OpenStep 4.2 update and its VESA driver you get a visually pretty setup. It still seems a little wobbly at times, but it is workable. I haven’t had time to fight with the network card, but I hope it can be figured out.

    I’m not sure if someone else has done this, but if not I’d be happy to share the patch. Alas, I don’t have a place to stick it on the web. Neozeed, maybe you could help there if you think it could have some value.

    Cheers!

    • Id be MORE than happy to host the patch, and go over it.

      I like sourceforge as it’s been around for eons, so it’s not trendy and will probably be around a bunch more (they got new owners and fired the guy that did the trojan shit, and removed it everywhere, although I know in the PR space the damage is done)…

      you can email me with my user @gmail.com

      • Hi neozeed, Did you get any response from Astromike for adapted Michael Engel’s NeXT busmouse patch to the newest qemu? It would be great to have this available somewhere.

        I just tried to run Rhapsody with latest qemu. I managed to get though dreaded PIIX “Interrupt timeout” patching hw/intc/i8259.c, but I got stuck at PS/2 mouse that is jumping randomly in qemu.

        So the most straightforward workaround would be busmouse support updated for latest 5.x qemu. But I lack time and skills to do it 🙁

        Cheers, Adam.

  4. > For additional fun, the serial port can be set to a MS Mouse port, although I haven’t tested it as of yet.

    I have, and I don’t think it works, but I can’t tell why. I’m trying to not dig into qemu+CuteMouse’s source code myself… not again/more.

    I opened a bug in the bug tracker ( https://bugs.launchpad.net/qemu/+bug/1888663 ), but I assume it’s really low on the priority list. If anyone can get it working, I’d be happy to hear it!

Leave a Reply