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. Latest changes may only be in QEMU sources from git and need building it yourself, sometimes with additional patches. See developer introduction for instructions. I don't provide binaries or help building it. These changes get in official QEMU releases eventually so these should become more widely available in the future but sometimes may take some time to reach your source of binaries or you can try binaries provided by Emaculation.com

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 MorphOS did not work with it before QEMU 6.0 and ran better on the mac99 Power Macintosh emulation. Since QEMU 6.1 there is also a pegasos2 machine which can run MorphOS and AmigaOS better since QEMU 8.0 but the latter has no graphics driver for the emulated cards on the install CD so some changes are needed to install AmigaOS on pegasos2.

News

See further info by OS: AROS, AmigaOS, MorphOS
or read FAQ or Comments.

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 -rtc base=localtime \
  -drive if=none,id=cd,file=aros-sam440-ppc.iso,format=raw \
  -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 for each supported machine so the appropriate version matching the emulated hardware is needed. The first machine in QEMU that could boot AmigaOS was sam460ex for which the AmigaOS 4.1 Final Edition install CD for the Sam460 (tested Sam460InstallCD-53.58.iso) is needed. Start it as:

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

Minimum required QEMU version: v3.0.0 (at least v5.0.0-rc2 recommended). The sam460ex machine runs slower so other machines below are preferred.

From QEMU v6.1.0 there is also the pegasos2 machine that can run the appropriate Pegasos II version of AmigaOS but that version does not include graphics drivers for any QEMU emulated card so booting the CD will show nothing on screen without some changes. See separate page on installing AmigaOS 4.1 on pegasos2 or development page for further details.

From QEMU v8.2.0 there is also amigaone machine that can run the AmigaOne SE/XE/microA1 version of AmigaOS. Internally this shares most components with pegasos2 as these two machines are very similar but those who only have the AmigaOne version can now also use it with this machine. For amigaone and pegasos2 machines the easiest way to install AmigaOS is described here.

Known problems

1. Initial graphics mode is incorrect which results in strange blue white colors

   For some reason AmigaOS may not select the right graphics mode on boot and falls back to PAL LowRes which results in strange color dithering. Workaround is to select the last option to boot into LiveCD and select a better board specific mode from System / Prefs / ScreenMode. (ScreenMode prefs may take a long time to launch so wait some time like a minute or so after you've double clicked on it before trying again.) See screen shots showing the problem and workaround steps.

   Alternatively, you can patch the boot iso to change screenmode.prefs to use only a 16 bit mode so the selected mode and colors will be correct. This can be done by this binary patch kindly provided by Sebastian Bauer. This patch applies to iso with MD5 sum a9be88ab08c5883d6a6f14a12cd5b32f and should result in iso with MD5 sum 06ce410a7fc5f7dc236488f8ee76ad47. One can use

   bspatch Sam460InstallCD-53.58.iso Sam460InstallCD-53.58-patched.iso Sam460InstallCD-53.58.iso.bsdiff
   

   to apply the patch. Please note that you are responsible to comply with the license of AmigaOS and you're not allowed to distribute the iso.

2. Crash while or after installing Update1 on sam460ex

   The libstdc++ included in Update1 has a bug that it uses lwsync instruction which is invalid on embedded PPC but only causes exception on e500 cores on real hardware. There's a patch to QEMU to allow this to work which is included in QEMU v4.0.0 so you should not see lwsync related crashes with newer QEMU versions.

3. Some programs randomly crash on sam460ex

   Some programs may crash sometimes. This happens less frequently in QEMU v5.0.0-rc2 so at least this version is recommended for AmigaOS. This seems to depend on speed of emulated CPU and only happens on fast systems but the exact cause is not yet known so it couldn't be fixed.

4. 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.

5. Graphics operations are slow and there may be some glitches

   AmigaOS uses the hardware features of Sam460EX more fully than other OSes which means more needs to be emulated but some features may not be implemented yet.

   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 ati-vga this was fixed in QEMU 8.2.

   For more information about ways to improve graphics see discussion on this page.

MorphOS

Since QEMU 6.1 at least MorphOS version 2.6 can be run with the pegasos2 machine but only tested with latest 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. See separate page for more information.

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 boots 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). 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 preferred 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).

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 at least -drive media=disk,format=raw,file=hd.img instead which adds corresponding ide-hd device automatically or use the full detailed options listed above for sam460ex to specify drive with if=none and -device ide-hd to refer to that drive.

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 limirations 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 there could be problems on ARM CPUs due to missing support in pixman library). There are several other possible options to improve graphics emulation, these are discussed on this page.