[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