Running Amiga like OSes on QEMU

Disclaimer

These are some notes on how to run Amiga like OSes (like AROS, AmigaOS and MorphOS) on QEMU that I've written to have some up to date info on the status and help new users. All this emulation in QEMU comes without any support and it's not expected to be complete or do everything one may desire or dream about. It's not a commercial product with a roadmap or any goal and still a work in progress which may never get finished. I'm doing it for personal interest and in my (limited) free time, no donations are solicited or accepted. So don't expect it to be anything more than a curiosity at the moment and its future depends on what the open source community makes of it. Keep this in mind when trying this.

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.

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 currently does not work with it so the mac99 Macintosh emulation can be used instead.

News

2019-04-24 QEMU 4.0.0 is now available
2019-03-26 QEMU 4.0.0-rc1 is now available
2019-02-19 Patch merged on QEMU master fixing exception with lwsync. Also sungem network is now default on mac99 instead of ne2k.
2019-02-04 Patch merged on QEMU master that allows using 2GB memory on sam460ex.
2019-01-28 Patch merged on QEMU master that fixes a bug reading status of device connected to ide.1.
2018-12-11 QEMU 3.1.0 is now available No changes relevant to Amiga like OSes in this release
2018-08-20 Emaculation.com has Windows and OSX binaries of QEMU 3.0.0 (also check their guides)
2018-08-15 QEMU 3.0.0 is now available
2018-07-18 Windows binaries of QEMU are updated to 3.0.0-rc1
2018-07-17 QEMU 3.0.0-rc1 is now available
2018-07-15 Updated page with info on lower performance with --enable-debug
2018-07-10 QEMU 3.0.0-rc0 is now available
2018-07-09 All required patches merged on QEMU git master

Further info by category:

  • AROS
  • AmigaOS
  • MorphOS
  • FAQ
  • Comments
    •

    AROS

    AROS Screenshot
    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. (Not sure if this is something missing from emulation or an AROS problem.)
    2. Sometimes seems to hang during boot at a grey screen. (This may be a race condition in AROS, booting again helps.)
    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 more likely to be AROS side.

    AmigaOS

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

    Known problems

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

      For some reason AmigaOS does 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.

      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 confirm to the license of AmigaOS and you're not allowed to distribute the iso.

    2. Update1 cannot be installed and some programs crash with Update1 installed.

      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 it to work but then some programs seem to crash with Update1 installed when QEMU compiled without --enable-debug option. More testing is needed to identify why this is happening.

    3. 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 this is not optimised yet and some features are not implemented yet. This may be improved in the future or if you have a CLGD driver (not on the Sam460 boot CD by default) it may work better with the cirrus vga emulation in QEMU but I haven't tested it.

    MorphOS

    MorphOS Screenshot
    At least version 3.8 is required, latest (tested 3.11) is recommended. Start it as: 
    qemu-system-ppc -machine mac99,via=pmu -m 512 \
  -vga none -device sm501 \
  -cdrom morphos-3.11.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.

    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.

    Known problems

    1. USB devices 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, 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.

    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 may fix this. See in Comments below.

    4. MorphOS does not boot on sam460ex.

      For some reason it 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'm not sure. It looks like MorphOS tries to access PCI registers with an offset of 2 for some reason. This may not happen on 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.
      If you have a real Sam460EX can you please share output of MOSSYS:C/PCIScan and/or test it with booting from a CD drive connected to a PCI card and without any graphics card using only the on-board SM502 graphics and let us know if it works?

    FAQ

    Why not emulate Pegasos, X5000, etc. instead of Sam460EX?
    The Sam460EX is a good 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 or don't support all OSes so may be more work to implement them and does 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 Hz values (such as emulated CPU speed) the OS sees on an emulator have no relation to speed at which code runs and does not relate to real hardware speed.
    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.
    Can it use KVM and would that make it faster?
    KVM is a virtualisation facility so it does not help emulating PPC on a different CPU (such as x86_64). It can only be used on a PPC host to run PPC code. Moreover, on PPC it ideally uses virtualisation (hypervisor or HV) support which is only found in server or newer CPUs. On PPC besides this HV mode KVM also has a so called PR mode which 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 maybe implementing a few things for PPC440. I could not test this so I'm not sure if it works or what is needed for it.
    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 paravirtualisation (virtio drivers) on guest OSes that could help disk and network speed or using QEMU's virtio-gpu to support 3D acceleration.
    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, 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.)