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 (
--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
emulation can be used instead.
Patch merged on QEMU master fixing exception with lwsync.
Patch merged on QEMU master that allows using 2GB memory on |
Patch merged on QEMU master that fixes a bug reading status of
device connected to |
|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|
Updated page with info on lower performance with |
|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:
--enable-debugoption? 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.
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.
m68kfor 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
sii3112emulation I've added for
sam460excan be used on other platforms as this is a common PCI SATA controller, the
sm501graphics chip is also used on SH platform emulation and the work done to get MorphOS running on
mac99helped getting MacOS and OS X running as well.)