Running Amiga like OSes on QEMU
This page provides information on how to run Amiga like OSes
QEMU. I've written this to have a source of
up to date info on the status of this project and help new users. Amiga NG
emulation in QEMU is something I did for personal interest and work on it in my
(limited) free time. It 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 may eternally remain a work in progress
which may never get finished. Its future depends on what the open source
community makes of it. Keep this in mind when trying this.
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
Clicking the above button or
following this link
takes you to stripe.com to pay securely. The payment is processed by Stripe, no
information is collected or saved by this site. This is the only way to send me
money, do not use any other link or info from anywhere else. This is solely to
show appreciation of the considerable amount of work I put into this in the past 8
years and does not give you any advantage or entitle you to demand anything. As
stated in the disclaimer above, the project is without roadmap or specific goals
and I will work on what I like. I'd like this to become a collaborative effort so
If you want some new feature or improvements then a better way is to start
contributing to the project. See the
development page for
details on how to do that or you can contact me via email (address can be found in
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 (
--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
Power Macintosh emulation. Since QEMU 6.1 there is also a
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.
See further info by OS: AROS, AmigaOS, MorphOS
or read FAQ or Comments.
from the AROS Nightly Build
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 \
Minimum required QEMU version: v2.12.0.
- 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.)
- 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.
- 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 has different versions for each supported machine so the
appropriate version matching the emulated hardware is
the AmigaOS 4.1 Final Edition
install CD for the Sam460
) 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 \
Minimum required QEMU version: v3.0.0 (at least v5.0.0-rc2
Starting with QEMU v6.1.0 there is also the
machine that can run the appropriate Pegasos II version of AmigaOS but
that version does not include graphics drivers for any 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
for further details.
- 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
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.
- Crash while or after installing Update1 on sam460ex
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.
- 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.
- 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.
- 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
ati-vga. You either need to compile pixman with
or use at least QEMU 8.0 which has fall backs for this case. For
ati-vga there is no work-around currently other than fixing pixman.
For more information see discussion
on this page.
Since QEMU 6.1 at least MorphOS version 2.6 can be run with the
machine but only tested with latest MorphOS
(version 3.17). 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
is the Pegasos II boot file copied from
the CD (mount the ISO, copy
from the top level
directory, unmount the CD and use the copied
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.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
See separate page
Make sure you type
or copy&paste the above command correctly. The
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
qemu-system-ppc -machine sam460ex -rtc base=localtime \
-drive if=none,id=cd,file=morphos-3.15.iso,format=raw \
(but there's not much reason to use it as it runs better on other machines such
See problem 4. below for more details.
- USB devices such as keyboard and mouse don't work on
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.
- Mouse movement periodically jumps and CPU usage is high on
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
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
so if someone wants to help implementing it this is open for contribution.
- 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
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.
- MorphOS does not boot on
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.
- How to add a hard disk image for installation
- You can create disk images using qemu-img
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
instead which adds corresponding
ide-hd device automatically or use
the full detailed options listed above for
sam460ex to specify drive
-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
for more information). If you want to access services on the guest, ports can be
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
See also KVM networking docs.
On macOS you may want to look at
or check the network section of the guides at emaculation.com for
- 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
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
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
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
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.