Running Amiga like OSes on QEMU

Disclaimer

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 require building it yourself, sometimes with additional patches. See developer introduction for instructions. I don't provide binaries or help building it. These patches get in official QEMU releases eventually so these should become more widely available in the future but sometimes that 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 runs better on the mac99 Macintosh emulation so that can be used for it instead. Since QEMU 6.1 there is also a pegasos2 machine which can run MorphOS and AmigaOS but the latter has no graphics driver for the emulated cards on the install CD so it does not produce video output.

News

Further info by category:

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 bacause 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

Only the AmigaOS 4.1 Final Edition install CD for the Sam460 (tested Sam460InstallCD-53.58.iso) is expected to boot. 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).

Starting with QEMU v6.1.0 there is also the pegasos2 machine that could run the appropriate Pegasos II version of AmigaOS (tested with Peg2InstallCD-Upd1.iso) but that version does not include graphics drivers for any emulated card so booting the CD will show nothing on screen. Modifying the install CD by copying PCIGraphics.card and siliconmotion502.chip from the Sam460EX boot CD and adding them to Kicklayout may work but it's untested and may not be easy to do for most users. Also booting AmigaOS on pegasos2 needs a firmware ROM, see development page for details.

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

   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

   Some programs may crash sometimes when QEMU is compiled without --enable-debug option. 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 are not implemented yet. This was somewhat improved in QEMU 5.1.0 but there may still be missing features that could cause different results than on real hardware. If you have a CLGD driver (not on the Sam460 boot CD by default) it may work with the cirrus vga emulation in QEMU but I haven't tested that.

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.15). Start it as:

qemu-system-ppc -machine pegasos2 -rtc base=localtime \
  -device ati-vga,guest_hwcursor=true,romfile="" \
  -cdrom morphos-3.15.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. Start it as:

qemu-system-ppc -machine mac99,via=pmu -m 512 \
  -vga none -device sm501 \
  -cdrom morphos-3.15.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 What about better graphics emulation? FAQ entry for limitations.

See problem 1. below for openbios-qemu.elf. 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.15.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.

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.

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 -hda 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 file=hd.img,format=raw instead or use the full detailed options listed above for sam460ex to specify drives.

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. On PPC besides this 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 still 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 would need some work.

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 originally emulated sm501 graphics was a quick way to get graphics working but it is limited so even after optimising it it would not provide all features of better GPUs usually used on real hardware. So instead of spending time improving sm501 further, I've started implementing ATI VGA emulation. It is far from finished (it is a big project I'm not expecting to be able to finish any time soon without help) and can only partially emulate an ATI Rage 128 Pro yet but as of QEMU v4.1.0 it can be used with MorphOS and get picture with some 2D acceleration (although video overlay is known to be missing so video playback will fail and there could be other problems as well). To try it, replace -device sm501 with -device ati-vga,guest_hwcursor=true,romfile="" in the MorphOS command line. (This only works with MorphOS for now as AmigaOS does not have a Rage 128 Pro driver and the alternative RV100 emulation is not complete enough yet.)