Maybe an improvement could be getting a virtio-net driver. Somebody could look at that if you at least published your virtio.library to avoid someone writing another version which then will be incompatible with your drivers. So for that having at least one standardised virtio.library would eb helpful for which a good way is to make it available for others to use and maybe contribute too.

Virgl should also work on windows but maybe you need to build it yourself. (Probably because nobody bothered to upstream the needed patch.) There are some tickets:
https://gitlab.com/qemu-project/qemu/-/issues/564
https://gitlab.com/qemu-project/qemu/-/issues/1461
and a blog post about it:
https://guanzhang.medium.com/running-a ... indows-10-11-4eea9be9a06b
If this works and want others to be able to use it without having to build a patched version consider upstreaming the patch by submitting it to the qemu-devel list following the patch submission guidelines.

By the way did you test the emaculation.com windows builds vs. the welnetz.de builds and is there a differentce between those?

Also if you have real hardware and also used AmigaOS on QEMU so you can compare the experience what are the points you think is still behind on QEMU (apart from slower FPU that I already know aobut and gfx which is being worked on).

Ok, thanks for the information...Hans ok, it looks like you prefer to use Linux as a test system.

For MacOs I found this, which should be pretty easy to install using the homebrew package manager. I haven't tested it yet. When this driver is released, 3D acceleration will be added with later versions, so it's not that important for now.

https://github.com/knazarov/homebrew-qemu-virgl

I don't understand much about it, but which dependencies under Qemu have to be fulfilled for the VirtIO GPU driver to be used under AmigaOs4.1. ?

I get what you say. What I meant was just in case it's more difficult to implement this with virgl then maybe gfxstream might be a better match. But since that's new and experimental in QEMU it may be less well documented and not so easy to use at the moment.

KVM and Virtio is only for Linux users.

but at the end its way more expensive then a classic system is, getting price down to a price people are comfortable is also important.

Will Qemu and virtio bring in a lot of fresh new users? Debatable, I guess the question really is how many OS4 classic licenses were sold because I would think that most of those users can't be happy with it and may want an upgrade. Obviously depends what they thought they were going to use it for before they found out it was slow.

What a depressing topic.... i feel sad, and will not accept.

Next thing, is about whole AmiWest fiasco: There wasn't anyone who can says about OS4 progress, because there weren't persons involved in. Matthew is against anything Hyperion, and he has no access to the progress of Hyperion to know about. Steven and he's facepalm presentation about nothing, seems just to be a cause that he also can't talk about progress on OS4 from Hyperion's side by any of reasons (I don't know why). And don't ask me why he's presentation were called with words "OS4 updates", he says nothing about, while there are OS4 updates. Just there also wasn't any real OS4 developer involved to talk about something interesting of late progress. Damn, even no one were able to make some “OS4 Gaming” presentation, it has no needs to have anything internal and new to know, to make some tasty presentations showing some of OS4 latest stuff of year, just there wasn't anyone willing to do so.

That’s latterly shame, hope any relationships between developers and Ben can be restored, then I hoper fore better cooperation between different companies, and less legal nonsense.

Although I am not quite convinced that this "new branch" will give us a big glut of new developers, since: this has been already possible using WinUAE and, yes, also QEMU.

Better colour depths and screen resolutions may be important for gamers. But for developers?

When considering cost alone, the first approach is definitely preferable, but there is a middle ground which can benefit everyone including people outside of the Amiga universe, and that would be open source hardware. That approach is working very well in the MCU/IoT world. It allows people with talent to design useful hardware and drivers, while people with enough funds can get the hardware mass-produced, and is typically done with some royalty scheme as it's important to keep the designers/coders on-board to continue improving/expending the product. It works quite well for companies like Sparkfun, Olimex, AdaFruit, and SeeedStudio to name a few.

Maybe that's how Amiga hardware will be produced in the future, I don't know, but I like the idea.

I don't know virtio-gpu but I think what's currently in master supports virgl and maybe shared buffers were already merged but I haven't seen patches yet to add Vulkan support so at the moment it's probably uses OpenGL. This is a bit old status report but maybe still mostly the case:
https://www.kraxel.org/blog/2021/05/vi ... gpu-qemu-graphics-update/

... So if you need something that's currently off-tree but has s signed-off-by already you can ask the author if plans to upstream it or take it yourself and do the upstreaming (see https://www.qemu.org/docs/master/devel/submitting-a-patch.html).

Anyway another way to use real hardware could be to buy an old powerpc mac, install some distro of linux ppc on it and hope for a full compatibility with kvm-pr mode.
I tried some months ago on my powermac g5 quad with an old linux ubuntu ppc distro and an old version of qemu (between 3.x / 5.x if I remember well).
The Sam 460ex virtual board emulated in quemu was not compatible with this feature.
I have never understand if the limit was inside linux kernel, qemu kvm or both.
Anyway it's for sure a software limit and it's fixable with some work.
With kvm-pr you can get a full speed and use real hardware, having fun with linux ppc, amigaos 4 and mac os leopard at same time.