Graphics card emulation for AmigaOS

AmigaOS 4 drivers exist for different graphics cards but each platform specific version of AmigaOS only inlcudes a limited number of drivers for cards supported on that platform. Also QEMU can emulate a number of graphics devices but most of these are not supported by AmigaOS. Therefore it is a problem to find a combination that works and provides good results without much effort from users. This page discusses the different options for graphics card emulation and meant to be a place to collect information about this topic and to give inspiration for potential contributors who may want to look into one of these. Also see DeveloperTips for help with starting to work with QEMU sources.

There are two approaches to solve this problem: emulating a graphics card in QEMU for which AmigaOS already has a driver or writing new AmigaOS drivers for already emulated cards. A special case of the second are paravirtual devices that require guest support or drivers so discussed together with the second option too.

TL;DR:

I think the two best options at the moment are emulating an ATI Radeon device or writing an AmigaOS driver for QEMU stdvga or ultimately virtio-vga. These two are independent and could be worked on and progress in parallel if there were enough people for that but currently there aren't.

Emulating real graphics chips

This approach uses existing drivers for real hardware already supported by AmigaOS and implements emulation of these cards in QEMU. The advantage is that no AmigaOS code needs to be written and the resulting emulation may be useful for other guests or machines as well so it's not AmigaOS specific. The disadvantage is that these GPUs may be complex thus hard to emulate correctly and also might have limitations that real hardware has which cannot be overcome easily or at all.

AmigaOS for PegasosII includes a PCIGraphics.card module that can detect PCI and AGP graphics cards and start the corresponding *.chip drivers. The supported cards are mostly ATI Radeon devices with at least an RV100 GPU, some 3dfx Voodoo and Permedia cards. Updated versions of PCIGraphics.card can also detect and load drivers for Silicon Motion SM502 and Cirrus Logic CLGD 5446 based cards. The Sam460EX version is similar but includes the siliconmotion502.chip driver on the CD which can also be used for pegasos2 as described here.

If we want to be able to use these AmigaOS versions without any changes (or only minimal changes) then the card to emulate should be one of these. These are further discussed in the following subsections.

sm501

QEMU already partially emulated sm501 for an SH4 machine before, which is the same as the sm502 found on Sam460EX and the AmigaOS driver works with it after some fixes to the emulation and it can also use advanced features of the device such as 2D acceleration for blits and fills and some raster operations which are now also supported in the QEMU model after my changes. Currently this is the easiest and best option that works with all guests and machines that can run Amiga like OSes but there are some limitations in available resolurions and color depth under AmigaOS. While MorphOS can use 32bit screen modes AmigaOS only shows 8 and 16 bit modes. This makes graphics slower because QEMU prefers 32 bit modes that match modern systems, otherwise it will convert guest screen on every screen update. I'm not sure if this limitation is also present on real hardware, so it is a limitation of the AimigaOS driver itself or something still missing from or wrong in QEMU. Checking with Ranger on AmigaOS 4.1FE, the SM502 driver shows R8G8B8 as supported but these modes are not showing up in ScreenMode prefs. I don't know enough about how AmigaOS graphics and RTG works to be able to tell why these modes are not added so if somebody has an idea or wants to investigate and find out if it's fixable that would be up for contribution. Currently all I know is that enabling logging through os4_commandline firmware env variable I get some logs from the SM502 driver:

SYSTEM_CTRL 00100000
MISC_CTRL 00100001
MISC_TIMING 00000000
Scanning bus 'vga'
                                                                
                                                                
0000: 00 FF FF FF FF FF FF 00 49 14 34 12 00 00 00 00  ........I.4.....
0010: 2A 18 01 04 A5 20 14 78 06 EE 91 A3 54 4C 99 26  *......x....TL.&
0020: 0F 50 54 21 08 00 E1 C0 D1 C0 D1 00 A9 40 B3 00  .PT!.........@..
0030: 95 00 81 80 81 40 EA 29 00 C0 51 20 1C 30 40 26  .....@.)..Q..0@&
0040: 44 40 45 CB 10 00 00 18 00 00 00 F7 00 0A 00 40  D@E............@
0050: 82 00 28 20 00 00 00 00 00 00 00 00 00 FD 00 32  ..(............2
0060: 7D 1E A0 FF 01 0A 20 20 20 20 20 20 00 00 00 FC  }...............
0070: 00 51 45 4D 55 20 4D 6F 6E 69 74 6F 72 0A 00 3B  .QEMU.Monitor..;
EDID V1.4
ManufacturerID RHT ProductID 1234
SerialNo 0 Manufactured week 42 of 2014
Input type digital
Display gamma 2.20
Maximum Image Size 32x20cm
PowerManagement Standby no Suspend no ActiveOff no
Monitor Name  QEMU Monitor

Established timings:
	800x600@60
	640x480@60
	1024x768@60

Standard Timing Identification:
	2048x1152@60hz (16:9)
	Not Found: 2048x1152@60hz (16:9) - calling CVT(RB=1)
	1920x1080@60hz (16:9)
	1920x1200@60hz (16:10)
	Not Found: 1920x1200@60hz (16:10) - calling CVT(RB=1)
	1600x1200@60hz (4:3)
	1680x1050@60hz (16:10)
	Not Found: 1680x1050@60hz (16:10) - calling CVT(RB=1)
	1440x900@60hz (16:10)
	Not Found: 1440x900@60hz (16:10) - calling CVT(RB=1)
	1280x1024@60hz (5:4)
	1280x960@60hz (4:3)

Mode 1280x800@75hz 62khz
	DotClock 107300000hz
	HTimings 1280 1600 1638 1728
	VTimings 800 804 808 828
	Image Size 325x203mm
	Flags progressive -hsync -vsync

Monitor Range Limits:
	Horizontal frequency 30 - 160khz
	Vertical   frequency 50 - 125hz
	Pixelclock not given!
Where it reads and parses the EDID information provided by QEMU where the available modes supposedly come from, so it may be something is different in that EDID info than what the AmigaOS driver expects. The error about missing pixel clock at the end looks suspicious and may be related to missing resolutions or modes but I don't know where this should come from. QEMU seems to add a pixel clock value in the EDiD but maybe AmigaOS does not like that. The EDID is generated in QEMU in hw/display/edid-generate.c but that's all I know about this. Also the above log is with AmigaOS 4.1 Update 3, I think there were changes in RTG in later updates so in 4.1FE and later it may work differently but the issue with no 32 bit modes is still the same. One difference I see is that older AmigaOS versions are limited to 640x480x8 mode with the sm501 driver while AmigaOS 4.1FE and newer does have higher resolution and 16 bit modes which seem to be built in Picasso96 even without a Devs/Monitors/SM502 file. I could also not add modes by creating a Devs/Monitors/SM502 file as shown here which seems to be ignored and even works without that setting but again this is something I don't know about AmigaOS so some help from somebody knowing this better would be needed for overcoming this issue or understanding what is happening here.

ati-vga

Second best option would be emulating a supported ATI GPU which would allow booting the install CD without any changes and could provide support for a lot of advanced features as these cards are well supported by all guest OSes. This would also be useful for other guest OSes and machines as these cards were popular so hopefully others would be interested to test and contribute fixes but I could not yet reach a level where it would work enough to reach that as this device is quite complex and takes a lot of work to emulate. Current version works with MorphOS driver for !Rage 128 Pro but not with AmigaOS drivers yet. This emulation is discussed in detail on its own wiki page at SubprojectAti.

cirrus-vga

The Cirrus Logic CLGD chips were popular on classic Amiga graphics cards as well as on PCs of that era so it was also the default VGA device in QEMU for a long time before it was changed to stdvga (mostly to avoid security issues with the more complex Cirrus emulation). While cirrus-vga is not the default in QEMU any more it's still retained for backward compatibility and could be used for AmigaOS. Also WinUAE uses code from QEMU for CLGD emulation but in UAE it is used for Zorro cards, unlike the PCI card emulated in QEMU, and UAE may also have some chagnes not upstreamed in QEMU. The PCIGraphics.card in AmigaOS 4.1FE Update 1 and newer can detect the cirrus-vga card QEMU emulates and can load a driver named CirrusGD5446.chip for it, however that driver which works with QEMU's cirrus-vga is unreleased so not available. There is a 68k driver with the same name in the Classic version of AmigaOS that can be loaded by the Pegasos2 version and it seems to talk to the emulated card but it does not produce picture, likely because it is for a PicassoIV Zorro card which works differently than the Cirrus card emulated in QEMU. This driver also seems to have no logging or error handling so the only info about its working can be found by observing the accesses to the card which can be done by enabling tracing in QEMU. To try this, use -vga none -device cirrus-vga,romfile=VGABIOS-lgpl-latest.cirrus.bin -trace enable="vga*" after adding the CirrusGD5446.chip driver from the Classic version with a new enough PCIGraphics.card that would load it. Also see ticket #47860 for details on why the bios is needed. Also the CLGD driver seems to need a card bios otherwise it does not even talk to the card. I've found that P96 driver sources for a similar CLGD card was published as example code at the P96 support page so maybe the 5446 driver is similar or that driver could be used with minimal changes instead with the QEMU cirrus-vga. This seems to be doable but not something I want to play with so this is again up for contribution for anyone interested.

Voodoo

There are several open source projects that already emulate 3dfx Voodoo cards so code could be taken from one of them with a license comatible with QEMU's GPL2+ and implement Voodoo emulation in QEMU based on that. The main appeal of this option is that it could provide some 3D support amd was proven to be working in other projects but this is not something I plan to do, as I think there are better options than adding yet another incomplete or limited graphics emulation. It could be a not too difficult task for somebody willing to start working on this and a good way to learn the needed stuff, but consider other options first. To start with this I'd look at a simple PCI graphics device such as hw/display/bochs-display.c as an example that shows how to define a PCI card in QEMU and what a graphics card needs then start from there and add the Voodoo emulation from an open source project of your choice. I think this goes back to MAME which was the first to have it then PCem adapted it finally WinUAE also got it from PCem (but I may be wrong about who was the first). It can be a problem if ROMs that are not freely distributable are needed, unless it also works without a ROM with at least a Linux or other guest because QEMU likely doesn't want to take an unusable device. So if it only works with non-free ROMs that cannot be included in QEMU, then it may only be merged in the Qmiga project but not upstreamed to QEMU. Therefore I don't think this is a really good option, considering all the others discussed on this page, but I won't stop anyone who wants to try to add Voodoo emulation and see where it goes but I think effort is better put elsewhere.

Writing AmigaOS drivers and paravirtualisation

Another possible approach is to add new drivers in AmigaOS for one or more of the cards already in QEMU which does not have to be emulating a real hadware but may also be paravirtual such as virtio-vga. The advantage is that this could achieve the highest performance and most features without any legacy limitations. The disadvantage is that it is specific to AmigaOS and QEMU so would only help this combination, therefore the scope is limited. It also needs AmigaOS programming skills, which may limit the available developers, but for some this may also be an advantage as it does not need changes to QEMU.

Adding new AmigaOS drivers was not an easy option until recently, because the driver APIs were not open (which is still the case for CGX used on MorphOS) but now the P96 API docs were published by iComp so this is now a viable option which may be easier than emulating real hardware and achieve better results.

The uaegfx which is already built in AmigaOS and P96, and therefore would mainly need QEMU changes, is also a form of paravirtualisation so it is discussed in this section as well.

uaegfx

The main problem is that it seems to be completely undocumented so to implement support for it in QEMU one would need to reverse engineer it to find out what actually is needed from the emulator and how the guest driver would detect and use it. This work seems to have been already done by some FPGA Amiga accelerator projects such as FPGAArcade or Vampire/Apollo SAGA so information may be available in those open source projects and driver sources. This may need a simple guest side driver to bind to a card and the rest of the support needs to be implemented in QEMU which could use code from WinUAE, but that code may need to be cleaned up first to reach the standards required for inclusion in QEMU so it needs to be more well documented and cleanly implemented than a random hack for QEMU to consider taking it upstream. Thus, I'm not sure it's worth the effort. I don't know what features uaegfx has and if it were any better than implementing an AmigaOS driver for any other QEMU card such as stdvga or virtio-vga.

stdvga or virtio-vga

This would be the best option now in my opinion, as it could reach higest performance and may also allow 3D later but it may need relatively complex guest side support for all that to work. However it can start small as just a frame buffer driver and grow from there, so starting with it would still be a good idea and can be simple at first and gradually get more complex if needed. The existing open source AmigaOS driver sources mentioned above for uaegfx could be used as inspiration or even to write a simple driver for stdvga as a first step.

Several cards in QEMU - including stdvga - support Bochs VBE dispi interface so the driver does not actually need to care about legacy VGA, just switch the card to linear frame buffer mode and use it that way, so it can be very simple. Probably much simpler than supporting uaegfx or cirrus-vga so I don't know what the advantage would be with those if existing drivers for those cannot be easily made to work.

A driver for stdvga could be usful in itself but it could then easily be changed to detect a virtio-vga card and start using it as a simple framebuffer first. Then can implement hardware cursor and more complex features and ultimately 3D. This can become another subproject hosted on this website but I did not try to start with it yet as I still have enough other tasks in subporjects already. Thus contribution is welcome and interested people are encouraged to join and work together to make this possible or you'd have to wait a few more years until I get to it.

Even before any code is written, elaborating on the above ideas, researching needed information and making designs of what needs to be done to make a working AmigaOS driver could help or that's where somebody interested but not knowing yet where to start should begin: learn about AmigaOS/P96 drivers, virtio in general and virtio-gpu, virtio-pci, virtio-vga in particular to get an idea what this subproject would need. Then come up with a design, which is only when coding could start so don't give up before even trying saying "I can't write code" - nobody is born being able to write code but anybody could learn it if interested enough. Writing the code is often the smallest part of the job, getting the design and learing the needed stuff takes up most of it. Those who already know how to write C and know AmigaOS of course have an advantage so they would only have to learn about virtio and QEMU with which I may be able to help.. I've collected relevant info in links from this page so follow and study those as well.