Running Amiga like OSes on QEMU

Disclaimer

Previously no donations were accepted and they are still not solicited but to respond to "popular demand" (i.e. a few people asked) now there is a way to

Unless another version is listed, this needs at least QEMU 3.0 and does not work with older versions but you ought to use at least QEMU 8.0 and using the latest QEMU version is recommended. Pre-compiled binaries are available from QEMU downloads or you can try binaries provided by Emaculation.com

See further info by OS: AROS, AmigaOS, MorphOS
by machine to run OS, first available in QEMU version, minimum recommended version:

amigaone	pegasos2	sam460ex	mac99
AmigaOS, 8.2, 10.0	AmigaOS, 8.0, 8.2 MorphOS, 6.1, 8.0	AmigaOS, 3.0, 5.0 AROS, 2.12, 4.0 MorphOS, 6.0, <8.1	MorphOS, 3.0, 4.1

by topics: VFIO passthrough, running Linux
or read FAQ or Comments.

News

To compile QEMU yourself get QEMU sources from git and see developer introduction for instructions. I don't provide binaries or help building it. All PPC machines are emulated by the ppc-softmmu target in QEMU so you only need to build that (configure --target-list=ppc-softmmu). Building with --enable-debug makes emulation considerably slower so if you want performance don't enable this option. The sam460ex machine should run all of these OSes but it is a bit slower and MorphOS does not boot on the emulated machine and runs better on the mac99 Power Macintosh emulation. Since QEMU 6.1 there is also a pegasos2 machine which can run MorphOS and AmigaOS better and since QEMU 8.2 also amigaone machine is available which works with AmigaOS.

AROS

The sam440-ppc-boot-iso from the AROS Nightly Build Downloads (ABI-v1) page should boot and mostly work but it's not well tested on real hardware so when a problem is found I'm not sure what is an AROS bug or an emulation bug. Start it as:

qemu-system-ppc -machine sam460ex -serial stdio -rtc base=localtime \
  -drive if=none,id=cd,format=raw,file=aros-sam440-ppc.iso \
  -device ide-cd,drive=cd,bus=ide.1

Minimum required QEMU version: v2.12.0.

Known problems

1. Screen is 640x480 and no other modes are available. (This is probably because AROS does not support EDID in SM502 graphics driver, this should be implemented in AROS.)
2. Sometimes seems to hang during boot at a grey screen. (This may be a race condition in AROS, booting again helps.) The slowness during boot is because the low level i2c driver accessing RTC which could be improved writing a better AROS driver.
3. Only the -device ne2k_pci network card emulation seems to work with the prm-rtl8029.device AROS driver. Other cards don't seem to work but not sure if it's AROS driver or QEMU problem but since other OSes work I think those AROS drivers are x86 only and don't work on big endian machine like PPC so this should be fixed in AROS.

AmigaOS

AmigaOS has different versions that come with kernel and drivers for the supported machine only, so the appropriate version matching the emulated hardware is needed. Currently these are amigaone (since QEMU v8.2.0), pegasos2 (since QEMU v6.1.0) and sam460ex (since QEMU v3.0.0). The sam460ex is easiest to boot as the firmware is included in QEMU and Sam460 install CD comes with the required graphics driver but it runs slower so other machines are preferred.

AmigaOS on sam460ex with QEMU v9.0.0 and newer can be started as:

qemu-system-ppc -machine sam460ex -rtc base=localtime -cdrom Sam460InstallCD-53.58.iso

Older QEMU versions not supporting -cdrom option with sam460ex need to use the more verbose -drive if=none,id=cd,format=raw,file=Sam460InstallCD-53.58.iso -device ide-cd,drive=cd,bus=ide.1 syntax instead.

See separate page describing the easiest way to install AmigaOS using BBoot for running the AmigaOne SE/XE/microA1 or PegasosII versions of AmigaOS on these machines.

The pegasos2 machine was added in QEMU v6.1.0 but needed some fixes to run the appropriate PegasosII version of AmigaOS that was first available in QEMU v8.0.0 but installing AmigaOS was not easy at first. This is documented on a historic page on installing AmigaOS 4.1 on pegasos2 that is now replaced by the simpler BBoot method above. From QEMU v8.2.0 there is also amigaone machine which shares most components with pegasos2 as these two machines are very similar but the AmigaOne version of AmigaOS has less bugs and those who only have this AmigaOS version can now also use it with QEMU. The amigaone machine was improved in QEMU v10.0.0 so that or newer version is recommended for using it.

Known problems

1. Disk fills up quickly during install

   You may have too big block size set for the file system. This can be changed during partitioning in "select filesystem / edit defaults". Not sure why it seems to default to a large value such as 32k (maybe it depends on partition size) but if you expect to write many small files 1k or 512 bytes block size will use less space but may be slower. Something between 1k and 4k may be a good value depending on expected partition usage for FFS and 512 bytes for SFS.

2. Graphics glitches on Apple silicon macOS with older QEMU

   There is an issue with pixman library on 64 bit ARM such as Apple silicon Macs running macOS which is "solved" in brew by just disabling the parts that don't compile. This causes missing graphics elements with sm501 and ati-vga. You either need to compile pixman with some patches or use at least QEMU 8.0 which has fall backs for this case for sm501. For ati-vga this was fixed in QEMU 8.2.

See separate known problems page for more troubleshooting tips.

MorphOS

Since QEMU 6.1 at least MorphOS version 2.6 can be run with the pegasos2 machine but only tested with newer MorphOS version 3.18. Start it as:

qemu-system-ppc -machine pegasos2 -rtc base=localtime \
  -device ati-vga,guest_hwcursor=true,romfile="" \
  -cdrom morphos-3.18.iso -kernel boot.img -serial stdio

where boot.img is the Pegasos II boot file copied from the CD (mount the ISO, copy boot.img from the top level directory, unmount the CD and use the copied boot.img with the -kernel option).

For mac99 (and QEMU before 6.1) at least MorphOS version 3.8 is required, latest is recommended. See problem 1. below for openbios-qemu.elf. Start it as:

qemu-system-ppc -machine mac99,via=pmu -m 512 \
  -vga none -device sm501 \
  -cdrom morphos-3.18.iso -boot d \
  -prom-env "boot-device=cd:,\mac_ppc32\boot.img" \
  -bios openbios-qemu.elf -serial stdio

Minimum required QEMU version: v3.0.0. Since QEMU v4.1.0-rc0 you can also use -device ati-vga,guest_hwcursor=true instead of -device sm501.

Make sure you type or copy&paste the above command correctly. The prom-env parameter has to be exactly like above with all the backslashes, quotes around it and without any additional spaces. If you see an error and it's not booting and screen remains blank a typo in this option is the most common reason so check your command line carefully.

Starting with QEMU 6.0 MorphOS also booted on sam460ex as:

qemu-system-ppc -machine sam460ex -rtc base=localtime \
  -drive if=none,id=cd,file=morphos-3.18.iso,format=raw \
  -device ide-cd,drive=cd,bus=ide.1

but there's not much reason to use it as it runs better on other machines such as pegasos2 and mac99 and also see problem 4. below for more details.

Known problems

1. USB devices such as keyboard and mouse don't work on mac99

   The OpenBIOS firmware does not correctly describe PCI buses of the emulated machine which makes MorphOS try to access devices on the wrong PCI bus. This OpenBIOS patch provides a workaround but is not in upstream version, a patched OpenBIOS binary is here.

2. Mouse movement periodically jumps and CPU usage is high on mac99

   This is caused by a high priority temperature.sensor task which presumably tries to access temperature sensors over I2C but this is not emulated by QEMU so this hangs waiting for an interrupt which is not delivered so it has to time out. You can see this in Applications / LogTool / LogTool. Workaround is to lower priority of this task from Utilities / Task Manager until this is implemented in QEMU which helps with mouse freezing but does not avoid possible performance impact of this. The sensor task can also be stopped by ikill temperature.sensor from a shell command window or some start up script. I have collected some information on what is needed to emulate this I2C bus in QEMU here so if someone wants to help implementing it this is open for contribution.

3. Network problems

   The default network card for the mac99 machine is sungem (emulating the on-board ethernet port of PowerMacs) which is supported by MorphOS but its DHCP client does not work well with the default user/slirp network backend of QEMU. Symptoms are hang during boot (especially booting from HD) or network not working. Better results may be achieved using tap networking and static IP address assignment. Some people found that resetting network config after installation by booting from CD and copying the relevant configs to EnvArc or just setting DNS address may fix this. See in Comments below.

   On pegasos2 there seems to be a conflict with sound: if audio driver starts before a PCI network card driver then network does not work. A workaround is to move MorphOS/Devs/AudioModes/PEGASOS to MorphOS/Storage/AudioModes/PEGASOS and add a line to S/user-network-startup to run MorphOS/C/AddAudioModes FILES MorphOS/Storage/AudioModes/PEGASOS to delay sound startup after network startup which should resolve this problem.

4. MorphOS does not boot on sam460ex

   Before QEMU 6.0 MorphOS cannot find PCI devices and cannot boot because of that. It either won't find SATA controller and thus boot CD or HD or if booting from usb-storage with the SD card image (which is prevented by a bug in Sam460EX's U-Boot firmware anyway) it won't find display device so there will be no output. This problem may actually exist on real hardware too according to this forum thread, where similar issues are reported but I don't have real hardware to test. It looks like MorphOS tries to access PCI registers in a wrong way which may be tolerated by real hardware or may wrap in some way and provide different results with some devices working and others failing or people just use PCIe graphics and avoid PCI devices on real Sam460EX. QEMU 6.0 has a fix up to allow booting MorphOS despite this bug. Later an unrelated change broke MorphOS boot again so it does not boot since QEMU 8.2 or older stable versions released after it (e.g. v8.1.2).

5. Bitmap fonts in apps using old gadtools are garbled with ati-vga

   This seems to use host data feature of ATI graphics cards which is not emulated by ati-vga. Use -vga none -device sm501 instead.

6. Graphics glitches on Apple silicon macOS

   There is an issue with pixman library on 64 bit ARM such as Apple silicon Macs running macOS which is "solved" in brew by just disabling the parts that don't compile. This causes missing graphics elements with sm501 and ati-vga. You either need to compile pixman with some patches or use at least QEMU 8.0 which has fall backs for this case for sm501. For ati-vga this was fixed in QEMU 8.2.

FAQ

How to add a hard disk image for installation

You can create disk images using qemu-img e.g. qemu-img create -f raw hd.img 1G that creates a 1 gigabyte image file. Don't use the -hda shortcut option to add it to QEMU when installing on this image because as the warning says in that case format is guessed and writes to block 0 will not be allowed which prevents the partition table to be written. Use short form of -drive media=disk,format=raw,file=hd.img instead which adds corresponding ide-hd device automatically or use the full detailed options such as -drive if=none,id=hd,format=raw,file=hd.img -device ide-hd,drive=hd

How to set up QEMU networking

The simplest is to use the slirp/user networking which can be enabled as e.g. -netdev user,id=net0 -device rtl8139,netdev=net0 (see the QEMU docs for more information). If you want to access services on the guest, ports can be forwarded with the hostfwd option.
For more advanced setups the tap networking can be used which is like a virtual network cable connecting a tap device on the host to the emulated card in the guest. This needs some setup on the host machine first. On Linux you can create a tap device as root (set username to your user name, otherwise QEMU needs to run as root):

# ip tuntap add user <username> mode tap
# ip link set tap0 up
# ip addr add 192.168.0.1/24 dev tap0

Then you can attach a virtual network card to that tap interface as -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -device ne2k_pci,netdev=net0 and set an IP address (i.e. 192.168.0.2) in the guest (adjust these IP addresses as needed). Then you can communicate between host and guest or set up routing on the host. Alternatively, instead of assigning IP addresses you can create a bridge on the host and add the tap device to that to allow the guest to access the same physical network the host is attached to as if it were a real machine.
See also KVM networking docs. On macOS you may want to look at vmnet networking or check the network section of the guides at emaculation.com for macOS or Windows.

How to share files with the host

There are several ways to get files into the guest. One simple way to exchange small files (max. 500MB) is to use QEMU's ability to export a directory as a FAT file system and mount that as a USB storage in the guest. These options do this:

-drive if=none,id=ufat,format=raw,file=fat:rw:/dir/to/export -device usb-storage,drive=ufat

Due to a bug in sam460ex firmware this does not boot with the device attached. To resolve that omit the -device option leaving only the -drive and after boot hot plug the drive from QEMU monitor with device_add usb-storage,drive=ufat command. Also when using PCI pass through (e.g. passing through a graphics card) having such USB drive attached may cause slow down for some reason. Because of that and for larger files you may want to use a network share instead.

Why not emulate Pegasos, X5000, etc. instead of Sam460EX?

The Sam460EX was a good first target because all OSes support it and emulation of most of its components were already present in QEMU or had previous work done or relatively simple to implement. Other machines either have some hardware or software parts that are not available or easily implemented so more work to write emulation of them or they don't support all OSes so do not provide the same results as Sam460EX (i.e. to run all Amiga like OSes on QEMU in a simple way).

But Sam460EX is slow, there are faster machines. Wouldn't emulating faster hardware result in better performance?

Usually not. Emulation speed and speed of the hardware emulated are not related and the more complex the hardware the slower its emulation would be because of the added complexity need to be handled and it's also more difficult to implement so would take longer to do. Also frequency values (such as emulated CPU speed) the guest OS sees on an emulator have no relation to speed at which code runs and does not relate to real hardware speed. That said, in some cases it might help to emulate a machine with a G4 CPU because then software using AltiVec instructions could take advantage of QEMU's ability to translate these to corresponding vector instructions of the host or on Power CPU hosts KVM virtualisation could be used. Also OSes may be better optimised for that CPU as these don't have the limitations of embedded PPC like the 440 based 460EX. Therefore Pegasos2 emulation was considered. This is more interesting for AmigaOS because MorphOS already runs on mac99 with G4 CPU.

Why is QEMU so slow and how could it be made faster?

Did you compile QEMU with --enable-debug option? If so this disables optimisation and enables some additional checks that makes it run considerably slower. Unless you need it for debugging try without this option. Apart from that, I don't know and no one would know for sure without doing some profiling and identifying where the speed penalties are. Generally, doing things from software that is normally done by hardware is going to be slow (that's why it's done in hardware on the real machine) and emulating one hardware arch on a different one is just doing that: implementing the hardware features in software so it is expected to be slower (unless the emulated hardware is much slower than the host). QEMU has some tricks to speed things up but these may not work for all workloads or it may be possible to optimise it further if someone would take the time to measure, identify and optimise bottlenecks. There are some known weak points too such as FPU emulation which is partly because QEMU prefers correctness over speed, partly because nobody was interested so far to contribute improvements so existing code while works may not be the fastest.

Can it use KVM and would that make it faster?

KVM is a virtualisation facility so it can only be used on a PPC host to run PPC code, it does not help emulating PPC on a different CPU (such as x86_64 or ARM). Moreover, on PPC it ideally uses virtualisation (hypervisor or HV) support which is only found in server or newer CPUs and only runs code for same CPU as the host which Amiga like OSes don't support. On PPC besides HV mode KVM also has a so called PR mode which also works on CPUs without hardware support but this can only run non-privileged user code natively and has to emulate all privileged instructions so it's slower than HV KVM but depending on usage it should still be much faster than emulating all instructions. QEMU can use KVM on PPC host but since PPC Linux is now more focused on PPC64 servers it's possible that older CPUs and KVM PR needs some fixes and mostly only works for BookS CPUs so supporting PPC440 virtualisation for sam460ex may need some Linux fixes. The pegasos2 is more likely to work on a G4 host or maybe on G5 but running a 32 bit Linux distribution. Running G4 code on G5 with 64 bit kernel did not seem to work but even with 32 bit kernel some instructions may behave differently which might need some support from the guest kernel. See this article for more details.

What else can be done to improve this?

Probably a lot of things depending on time and expertise available (both of which may be limited if only one person is working on this). Apart from profiling and trying to identify and eliminate bottlenecks (as already mentioned above) I think the interesting possibilities are: experimenting with KVM on PPC hardware, trying pass-through of physical devices to virtual machine (e.g. using a Radeon GPU for graphics) and support for paravirtualisation (virtio drivers) on guest OSes that could help disk and network speed or using QEMU's virtio-gpu to support 3D acceleration. For work in progress ideas I've created an open project at Project Qmiga to have a place where interested developers could join and cooperate to make this happen but interest so far was moderate, so to say.

QEMU development process is slow and complicated. Why not write/enhance another emulator just for this which could move faster?

QEMU is the most actively developed and maintained emulator where we get a lot of components and improvements from work done for other platforms for free. E.g. m68k for Macintosh Quadra 800 and NeXT Cube emulation are being merged into QEMU so we might get some useful components from that in the future. We also benefit from any improvement made in PPC emulation for PowerMac or server emulation. Also QEMU is supported on a lot of platforms and we get this for free as well. Finally, having support for Amiga like OSes in QEMU also increases its visibility among experts better than having an obscure emulator that only a limited number of people develop and use. So in the spirit of open source, with QEMU we get help from others and also help others at the same time working on a common goal (e.g. the sii3112 emulation I've added for sam460ex can be used on other platforms as this is a common PCI SATA controller and the sam460ex emulation is used to test Linux releases to ensure they still work on this platform; the sm501 graphics chip is also used on SH platform emulation and the work done to get MorphOS running on mac99 helped getting MacOS and OS X running as well.)

What about better graphics emulation?

The first and most mature option now is the sm501 graphics which works with all Amiga-like OSes as the default graphics hardware of sam460ex but it has some limitations so I've started implementing ATI VGA emulation. which is far from finished (it is a big project I'm not expecting to be able to finish any time soon without help) but can now partially emulate an ATI Rage 128 Pro since QEMU v4.1.0 which can be used with MorphOS and get picture with some 2D acceleration (video overlay is known to be missing so video playback will fail and rendering of bitmap fonts use an unimplemented feature so it is broken). There are several other possible options to improve graphics emulation, these are discussed on this page and depending on the host machine VFIO passthrough of a real graphics card may also be an option.