@Hans I've mentioned the emaculation.com build before somewhere in one of these topics but maybe you've missed that post. Even though the weilnetz.de build is linked from the QEMU page which makes it kind of official it's not built from upstream QEMU but from a fork with some patches. Its main feature that it has an installer but otherwise had some issues not present in upstream sometimes. The emaculation.com is colser to QEMU upstream and was tested to run PPC MacOS so maybe better for running Amiga like OSes but I don't use Windows so don't know for sure.
Sure, anybody who wants to use virgl on Windows host can take the task and make sure it's upstreamed. The point is that if nobody does it it may never happen. QEMU maintainers are busy enough with their owm projects so they won't go after supporting stuff they don't need so it depends on people who want it to be part of QEMU to make sure it happens.
I'm more interested in low level things and actual emulation so I'll ignore user interface issues adn more interested in what parts are slower on QEMU than in emulation. Benchmarks showed that with fast enough hardware QEMU can run at least some simple code as fast or faster than real hardware but there are other aspects which may be slower and I was more interested if you could identify some points. If your experience is between fastest hardware vs. running QEMU on an old laptop then that's maybe not the best comparison but if there's something that seems to be a main issue that could make it closer that may still be interesting.
The issues with network and sound may be interrupt related but I'm not sure how to debug those. This may need to be checked from the AmigaOS side when it happens. Somebody who can debug those drivers and AmigaOS interrupt handling could try to check what happens when it hangs and what could cause it in the emulated hardware. From the QEMU side I could enable logs and traces but it's hard to find out from those what the driver is trying to do or why it may hang.
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.
balaton wrote:@Hans I'm more interested in low level things and actual emulation so I'll ignore user interface issues adn more interested in what parts are slower on QEMU than in emulation. Benchmarks showed that with fast enough hardware QEMU can run at least some simple code as fast or faster than real hardware but there are other aspects which may be slower and I was more interested if you could identify some points. If your experience is between fastest hardware vs. running QEMU on an old laptop then that's maybe not the best comparison but if there's something that seems to be a main issue that could make it closer that may still be interesting.
The comparison between Qemu and real "AmigaNG" hardware doesn't matter because we already know that Qemu's CPU/write/read speeds are a strong competitor with current i9/Ryzen/ARM hardware.
But what speaks against Qemu is:
- complicated setup, not user friendly
- NVRAM support (AmigaOne)
- 16-bit screen output (no 3D acceleration)
- Network unstable
When I also compare WinUae with Qemu, Qemu is the clear winner.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
The comparison between Qemu and real "AmigaNG" hardware doesn't matter because we already know that Qemu's CPU/write/read speeds are a strong competitor with current i9/Ryzen/ARM hardware.
Hans said that using AmigaOS on X5000 is still a better experience so I wanted to know specifically what are the main issues that cause this. Also what is it like compared to real pegasos2 or AmigaOne (or Sam460EX but that still has speed issues so not the best comparison at the moment).
This does not matter to those who only use AmigaOS on QEMU like you but it may matter to some people so it's still interesting to know.
Quote:
But what speaks against Qemu is:
- complicated setup, not user friendly
- NVRAM support (AmigaOne)
- 16-bit screen output (no 3D acceleration)
- Network unstable
As said I won't care about UI so we need somebody to take care of that but copy&pasting a command should not be that difficult.
NVRAM would be easy to do and I've posted what's needed before so somebody could try to implement that before I get to that.
Gfx driver is taken care of by Hans (although not clear when and how will that be available).
The network issue is something that's really annoying and would be nice to fix but I don't know what causes that or how to debug it so somebody who can debug this from the AmigaOS side should find out what causes it then we can see where and how to fix it. Until somebody does that it will only be fixed by chance maybe.
To me the more important things at the moment look like:
1. Get this in QEMU first 2. Fix interrupt routing to get USB working (which may help with other devices too but since network issue also happens with sam460ex that uses completely different interrupt controller it's not likely to help with that). 3. Resolve to firmware issue to be able to include some firmware so users don't need to download it separately (but it's not vital, pegaoss2 also worked like that and could be usable) 4. Improve it further like fixing memory detaction to allow more valid memory sizes or maybe add NVRAM if nobody does it by then.
Quote:
When I also compare WinUae with Qemu, Qemu is the clear winner.
That's a broad statement which is only true under your specific requirements/use case. More generally WinUAE proabbly does a lot more, it has GUI, it can emulate all classic Amigas in great detail, etc. but it's mainly focused on running AmigaOS for classic Amigas so for AmigaOS 4 PPC it may not be the best and in that QEMU is better but in all others its likely not. (Just clarified it before somebody misunderstands it and starts a flame war. So for running AmigaOS 4.1 on Apple Silicon Mac QEMU is better but that's not a general win. And there's no winner as there's no competition in the first place, these just do different things.)
When I also compare WinUae with Qemu, Qemu is the clear winner.
??? - WinUAE is easy to set up. - No NVRAM support required since the classic Amiga version of AmigaOS 4.x uses a special nvram.library using a nvram.config kickstart module instead (the Pegasos2 version of AmigaOS 4.x seems to use the classic Amiga version as well, but no other versions, incl. the AmigaOne and Sam4x0 ones, do). - 32 bit screen modes with host 2D HW acceleration (DirectX) and 3D support (old Warp3D only, not Warp3D nova) using an emulated Voodoo3 or S3Virge. - No network problems. - Support for sharing files between host and guest. - Next to no speed differences according to the benchmark results, and the small differences are probably only because WinUAE uses an old version of the PPC emulation which could be updated.
I guess in 1-2 years QEmu will get better than WinUAE, as soon as AmigaOS 4.x virtio drivers for at least gfx and network are available, and the remaining problems in the QEmu emulation (NVRAM and performance monitor support, etc.) are fixed. Especially since WinUAE is currently limited to Windows and x64 CPUs, although that could be changed as well, it's open source, but I doubt that will happen. QEmu OTOH supports all common systems (Android, Linux, BSD, Windows, etc.) and even works on niche systems like MacOS/ARM. But currently the clear winner comparing WinUAE with QEmu for using AmigaOS 4.x on emulation is definitely WinUAE.
Edited by joerg on 2023/10/22 15:31:40 Edited by joerg on 2023/10/22 15:32:22
joerg wrote:@Maijestro [quote]But what speaks against Qemu is: - Next to no speed differences according to the benchmark results, and the small differences are probably only because WinUAE uses an old version of the PPC emulation which could be updated.
Maybe I expressed myself a little wrong, what I actually wanted to say is that Qemu currently only scores with pure speed. And AmigaOs4.1 runs very stable under this emulation, compared to WinUae.
Of course WinUae does the points you mentioned much better than Qemu, but we must not forget how long WinUae has been on the market, Qemu with AmigaOs4.1 has only been usable for 1 year.
But since we are already far from the actual topic, let's leave it at that.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
@Maijestro Not sure if you know it or not, but WinUAE emulation of PPC, just use a plugin, which is QEMU PPC put into that plugin. Of course not the very recent one, but it still same QEMU, mean that speed of emulation only may differ if in later version of QEMU were done some speed improvements which is not in the WinUAe's QEMU plugin.
kas1e wrote:@Maijestro Not sure if you know it or not, but WinUAE emulation of PPC, just use a plugin, which is QEMU PPC put into that plugin. Of course not the very recent one, but it still same QEMU, mean that speed of emulation only may differ if in later version of QEMU were done some speed improvements which is not in the WinUAe's QEMU plugin.
Believe me I am very familiar with WinUae, WinUae was the reason why I switched to Qemu.
I know that WinUae uses a very old Qemu plugin for PPC emulation that is no longer maintained, Toni also told me that he is not interested in ppc emulation. Nor is making it available for other platforms Linux/MacOs.
I've often seen videos of people showing something with WinUae and AmigaOs4.1 and I thought it was terrible to watch.
But to get back to the original topic, I found this @Hans but I'm not sure if it's interesting for you.
@Majestro What i mean, that emulation of PPC be it WinUAE or QEMU (if take the same old version of PPC code) are the same. Just other bits differs.
And when i talk with Tony (year ago), he says that updating at this time PPC plugin for winuae with latest Qemu code wasn't big sense, as nothing were changed mostly (but that was year ago). But he also was ok to update it in WinUAE for some deal, but he say it make no sense.
Maybe in last year things changes, and it make sense now.
kas1e wrote:@Majestro What i mean, that emulation of PPC be it WinUAE or QEMU (if take the same old version of PPC code) are the same. Just other bits differs.
And when i talk with Tony (year ago), he says that updating at this time PPC plugin for winuae with latest Qemu code wasn't big sense, as nothing were changed mostly (but that was year ago). But he also was ok to update it in WinUAE for some deal, but he say it make no sense.
Maybe in last year things changes, and it make sense now.
You could certainly do that, but then the target group would still be those who use Windows. It would not be a solution for all platforms.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
It is possible to make it work on Macos and on Windows, but it requires adding patches to QEMU. Currently, I think all virgl on Macos and Windown are stuck on qemu 7.2 (they may be waiting for the final version of branch 8), and patches need to be added to SDL and virglrenderer. I am still looking for a native solution for "ui/cocoa" under macos.
If you would like a patch that works for me because you prefer Windows, please let me know. I know you have more knowledge, but maybe it will be useful for you, If not, you have all the data you need here -> https://lore.kernel.org/all/YZvyf4h+8e1Kzwp0@KPLWX0-LT/T/.
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.
How and when to release the virtio.library + developer files is up to A-EON. I'm working under contract with them, so it's their IP. I've already recommended that they make it available to other developers.
I'm not sure if the normal Qemu builds include Virgl (Windows), for MacOs it had to be built in.
For people who want to use AmigaOs4.1 with Qemu and "3D acceleration" as a full system or developer system, it could be complicated to set it up and you would have to provide the Qemu builds in addition so that the user doesn't have to do everything himself as he has enough problems installing AmigaOs4.1 on the machines.
Balaton has submitted the patches for AmigaOne XE emulation and they just need to be accepted:
There is not much written about it in this forum anymore, but they are still working on it. I also don't want to offend anyone here or give the wrong impression that real Amiga NG hardware is not competitive with Qemu, because it is and should be.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
You have to remember that AmigaOne XE s emulation is not just based on AOS4. There are other systems as well. To report the addition of a board to QEMU you have to prove that the system runs on free software and what the minimum requirements were. This emulation meets 128MB as the minium for the system it is running on. A QEMU user for other systems can increase this for themselves. Here is the proof.
@smarkusg IIRC the smallest memory size complete AmigaOne XE systems were sold with is 512 MB. The µA1-C, which isn't emulated by QEmu, was available with only 256 MB (+32 MB VRAM), but no AmigaOne with only 128 MB RAM.
@joerg The default memory size of QEMU VMs is historically 128m which seems small today but a lot of machines still has this default. It seems to work with amigaone and at least boot AmigaOS but for pegasos2 and sam460ex the default is set to 512m for reasons I already forgot but maybe their firmware had problems with less. Just to match these machines I've now changed the default for the amigaone to 512m too in latest patch version. Having larger default is not wanted, QEMU default should work but not use up all memory of your host just by starting a few VMs but one can easily specify larger memory size on the command line.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
