[DEV] VirtioVGA Driver for QEmu / AmigaOS4.1FE

With the help of AI and actually zero knowledge of programming, I once tried the VirtioVGA driver.

Update (DEV Build 5): (03/15/26)
- Archive updated
- previous bugs fixed

Bugs/Todos:
- no screen modes
- Crash during shutdown/restart
- Return code 20 at startup
- Use crash during VirtioVGA screen mode

Installation:


Screenshot: https://mega.nz/file/YTYyjAjI#SRkJ5w3I ... 6i7pk3NkbtYtRHOIXuzehoRGE

Help is welcome!

Download (15.03.26): https://mega.nz/file/8Xwn0JZC#5tQ33Vjc ... nswaEe4JgZ4iw7pL4eUD2rQTE

@Falke_34Quote:

So what does this mean?

@n3m3
"nach" means "to" as in copy to if that's what you mean. Otherwise it means what the post says. Falke_34 used an AI code generator to try to make a virtio-vga driver but it does not work. It is not helped by that the graphics driver API of AmigaOS 4 is not public but maybe it's similar to the P96 API so you could start from there but there could be differences.
If you ask me I'd trash most of this code and start by patching PCIGraphics.card to load a virtio-vga.chip driver for the PCI IDs of the virtio card and try to find out what it needs to set the frame buffer parameters enough for AmigaOS to be able to draw into it. The code as generated by AI does not seem to do any of that and you see all parameters are still wrong about the card and connected monitor modes which should come from DDC but it does not seem to read that so no idea where the modes come from. Maybe the only parts useful from this code are the communication with virtio PCI devices and the skeleton to make a driver but the actual graphics driver code is probably mostly wrong.

@balaton
Quote:The API for the .card and .chip drivers is still the same as in P96, with 2 exceptions: There is one additional, optional .chip function for HW accelerated compositing (only implemented in the ATIRadeon.chip, RadeonHD.chip and RadeonRX.chip drivers, maybe partially in the siliconmotion502.chip as well but I'm not sure, all others don't support it) and PPC native drivers are supported.
m68k drivers still work as well, most classic Amiga Zorro II/III gfx drivers are still m68k, they were implemented in m68k asm and never ported to PPC.

Quote:No need to patch anything, you can set the name of the .chip driver in the TOOLTYPEs of DEVS:Monitors/PCIGraphics. May need to be moved there from SYS:Storage/Monitors.
.card driver: Hardware bus access, different ones required on classic Amigas with Zorro II/III, CPU module (CyberVisionPPC), etc. gfx cards.
For all PPC Amigas with PCI, AGP and PCIe slots, even classic Amigas with a FireStorm, Prometheus or Mediator Zorro III<->PCI bridge: PCIGraphics.card
.chip driver: GPU specific driver, for example 3dfxVoodoo, ATIRadeon (R100/R200), RadeonHD, RadeonRX, siliconmotion502, virtiovga.

Quote:I didn't check much of if, but already the struct EmuTrap m68k->PPC stubs are complete nonsense.
Unless the virtiovga.card is an emulated m68k instead of a PPC native driver, but that wouldn't make any sense either.

@joerg
If I understand correctly, the main difference between AOS4 and ASO4FE (PPC) is the new graphics.library API.
The old P96 drivers are unable to load during system boot.
You can add entries to DEVS:Monitors/ (for example, VirtioVGA) for P96 and set the correct values for the new “chip,” but the system still checks during boot (graphics.library) to see if the card is in PCIGRAphics.chip and won't start.
I checked this driver, the VirtioVGA Driver for QEmu, and it seems to me that the concept is more based on a dual graphics card.
The card used at startup is sm501, and there’s also virtiovga.
The VirtioVGA initialization itself crashes on startup with an error related to graphics.library (something is initializing from the host side QEMU).

I think, as @balaton wrote, the best thing to do if nothing else works is to have VirtioVGA “pretend to be” some card that supports the PCIGRAphics.chip and see what’s going on.

@smarkusg

I created a 'fake' SM502 driver based on linux code (not released as it was proof-of-concept) so you could do that, however the route I was looking at for a VirtioGPU driver was to have it loaded by PCIGraphics.card via SetMethod hooks to give Workbench full RTG support on the VirtIO GPU. It uses a VirtIOGPUBoard NT_RESOURCE resident that runs before graphics.library to hook PCIGraphics.card's FindCard/InitBoard methods. I may pick it up again in the future.

@smarkusg
Quote:There is next to nothing left from P96 in AmigaOS 4.x, everything P96 did is implemented in graphics.library instead, except for:
- The .card and .chip driver API.
- The overlay/PIP related functions in Picasso96API.library, which are only supported by very few old gfx cards anyway (Merlin, Voodoo, Permedia, ATIRadeon).
Can help with video playback for example if YUV modes are supported. The other Picasso96API.library functions just call graphics.library functions now.

Quote:Would be strange. May need specific settings in Kickstart/p96Config, but should work.
In case there really is something hard coded in PCIGraphics.card not changeable with ENV variables or p96Config simply use for example ATIRadeon.chip, 3dfxVoodoo.chip or 3DLabsPermedia2.chip as the name of your virtio .chip driver

The main problem with this VirtioVGA driver is that it seems to be a replacement for PCIGraphics.card accessing the virtio VGA directly instead of using OS functions (expansion.library PCI functions), not a GPU, even if framebuffer only, .chip driver.
Can be done, but doesn't make any sense to me. The AmigaOne, Sam460 and Pegasos2 parts in QEmu emulate everything required for PCIGraphics.card, and it shouldn't make any difference if it's a real PCI(e) gfx card (a passed through RadonHD/RX for example), an emulated one like the SM502, or a virtio PCI device.

@derfs
Quote:Why? PCIGraphics.card should find all display class PCI devices and call all installed .chip drivers with each of them.
The .chip driver init function has to return TRUE or FALSE (or maybe some other defined return values) depending on if it's a driver for this gfx chip, checking the PCI IDs, or not.

@derfs
Quote:
It’s great that you’ve been working on this. I hope you’ll get back to it and manage to finish it.
I'm currently using your two Virio drivers and they're working well for me
I've had a look at your new qemu-runner project – it's/will be brilliant!!!
The remote console (seralshell) is a blast :D

Thanks

@smarkusg
Quote:What's the difference to using "newshell AUX:" on AmigaOS and a serial terminal program on a system connected to the Amiga serial port?
Or "newshell TCP:host/port" using a network connection instead of the serial port?

@joerg
I’ll explain what I use (QEMU) and what the limitations of the AUX/TCP newshell are. Not everyone will need this, and everyone has their own preferences.
Serialshell is part of the qemu-runner package.
"Automated QEMU lifecycle + cross-compile + deploy + run + capture for AmigaOS 4 development on Windows.
Build your AmigaOS 4 program, upload it to the guest, run it, and capture the output — all in one command."
I don’t have a compilation environment yet, and from the qemu-runner package I only use serialshell.
I have QEMU running with “serial stdio” and “-append ‘os4_commandline serial munge debuglevel=7’”, which ensures that all information goes to the serial port and stays there.
I don’t need anything else there. In this case, I can already type “newshell AUX:”
Serialshell can send individual shell commands to the system and run a program if necessary. It can send commands like upload, download, etc. The main command for using it is “serial_client”
You can also open it in “interactive” mode, which is similar to “newshell TCP:host/port”
Because of its additional features, Serialshell is more useful for me.

Here’s an example of how I’ve been using it lately: I’m testing virtio-net.device.
I run QEMU with debug options and serial output. Additionally, I don’t run QEMU with the “-display” option, but with “-vnc”.
The screen doesn’t open for me; everything goes through VNC (this might minimally affect interactive functions—don’t move the mouse or keyboard…). For this test, I don’t need a graphical interface at all.
In the Linux/KDE console (konsole), I have three separate consoles: one for serial output from QEMU, one for sending commands via serial_client, and a third free one.
I send the “upload” command with a large file and wait for an error to appear in the QEMU/AOS4 debug window. When the driver reports that it has crashed, I can still log in via the “interactive” Serialshell, change something (for example) using RoadshowControl, modify the QEMU configuration (options for the virtio-net.device driver), etc.
Quickly restart the QEMU instance (you can also do this via qmp_client)—start it up and repeat the process. Except… it happens quickly! These tasks are performed faster than clicking around the window.
When I log in to QEMU via a VNC client and have the screen open, I’m sure it would be possible to automate something as well
Currently, under ideal conditions, I can sometimes use virtio-net.device to transfer a 700 MB CD image to AOS4 seven times without the driver crashing. But this isn’t consistent, and I’m trying to figure out what’s causing this inconsistency.
It might be a silly test, but sometimes silly ideas are the best ;-D
This is just a quick, incomplete overview of how to use serialshell, but I hope it shows what it can be used for.

Here is the link to qemu-runner -> https://github.com/derfsss/qemu-runner