I didn't write such obvious things that the amigaone installation CD must contain the Silicon Motion driver. It must. If you want you can install from the ES2 installer or do it manually (drivers alone)
I'm very sorry but I don't have the skills to write detailed guides/HOWTO and I can't give you everything step by step.
qemu-system-x86_64 = QEMU PC System emulator Try to run a "second ubuntu x86_64 iso" on your installed Ubuntu, but to benefit from vfio-pci. Same vfio-pci data as you run qemu-system-ppc. Preferably without the "kvm" option (Kernel-based Virtual Machine) You will find examples of how to do this everywhere. I don't want to paste the exact command line for you because I have no way of checking it at the moment.
The steps are basically the same. What I get written in the qemu window for the sound is this after many checks: Once I try to save Prefs/AHI/AC97 stereo++ etc. etc.
couldn't open play stream: Non-existent file or directory sndio: failed to open device audio: Could not create a backend for voice `via-ac97.out'
once the RadeonHD.chip are activated in kicklayout the sound disappears
using the original ones from AHI and not those from ES 2.2
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
@white Which audiodev backend are you using? What was the configure output for audio_drv_list? The errors don't make much sense as I don't think it should use sndio on Linux and I can't find the error before that that says "couldn't open play stream" in QEMU so no idea where that comes from but maybe it has something to do with you have to run QEMU as root for passthrough and maybe it can't connect to your sound server in that case? This may be different on every distro so I don't know what to do with that but may try using
-audio alsa,id=audio0,out.try-poll=off
option. This is normally not recommended if you have a sound server and does not always work well but as a fall back it may work until you find out the issue.
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
are these the drivers that I have to use the 2.1 ?
I can't comment on specific graphics card models. In general, a Radeon R9 280x is a Southern Islands GPU, and that's supported by the RadeonHD.chip driver all the way up to v5.
I see no reason why you'd have to use specifically v2.1.
Hans
P.S., For 3D you need Warp3D Nova. Best get NovaBridge too for legacy 3D support (i.e., old MiniGl & Warp3D games).
@white Have you perhaps checked what @Balaton wrote ? You ask a lot of questions to which you get answers. But there is also sometimes no feedback as to what you tested and what the result is
Thanks for your help
ps - if you had checked "qemu-system-x86_64" you wouldn't have to reinstall AOS4. It would show that it is not a problem with the RadeonHD driver under AOS4.
@All I'm sorry, but the suggestions provided by you and @Balaton do not work. installing the drivers as you suggested the card is not recognized with Hardware acceleration for example Emotion does not work in YUV and is without acceleration.
The feedback is interesting the audio continues not to be heard. And I can't blame anyone.
The only thing that I regret is that no one tries to help those who are trying to carry on with this emulation.
@smarkusg Now I don't see dozens of people who are doing this emulation. I only have 2 examples yours is that of @germann
I don't see other examples. And so it is clear that you are trying to share what you have managed to do. I have been using KMV for a long time I have also emulated FS-UAE with Amilator with a single card and other systems.
I don't want software or programs or licenses.
I just need to understand the steps you have done. All the other answers are useless.
I'm sorry but it's like this. I have always demonstrated that I have no problems sharing what I do and even more than what I do.
I need a .raw file without any license without updates but that starts since there are no tutorials.
Mine is a polite answer and is free of any offense towards anyone. And only my answer to the answers try this way or try this other way.
At least a basis is needed, if this is not there, everyone can say what they want but it is unfounded.
I just can't figure out what it means do these steps: 1) example 2) example 3) example
OR I said I want to get another GPU Advice is welcome this is the only site to ask about AmigaNG
Edited by white on 2025/4/22 13:10:03 Edited by white on 2025/4/22 13:13:27 Edited by white on 2025/4/22 13:40:25 Edited by white on 2025/4/22 13:40:47
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
But we would need results from the same machine with the same benchmark on host, Linux guest and AmigaOS guest to be able to compare and I don't know who could get those results.
Btw, why not do some tests with AROS x86. If one downloads a live distribution like "AROS One 2.4" one can use it directly with
qemu-system-i386 -cdrom AROS-One-ISO-DVD-2.4.iso
and does not need to install anything and with it's vesa driver it shows you the framebuffer address (sys:system/hardware/pcitool) and it comes with gcc so you could directly type in some benchmark that pokes and peeks directly in VRAM and run it.
You could then see the difference between emulated cpu (qemu default? smiliar to cpu emulation of PPC hardware?) and hardware virtualiziation/cpu emulation (start qemu with -enable-kvm).
And I guess the AROS vesa driver should work with passed through radeon gfx card? So you can then compare those results with AOS4 with same passed through radeon gfx card.
In case this kind of tests is more difficult/annoying in Linux guest and/or Linux host ...
Btw, why not do some tests with AROS x86. If one downloads a live distribution like "AROS One 2.4" one can use it directly with
qemu-system-i386 -cdrom AROS-One-ISO-DVD-2.4.iso
and does not need to install anything and with it's vesa driver it shows you the framebuffer address (sys:system/hardware/pcitool) and it comes with gcc so you could directly type in some benchmark that pokes and peeks directly in VRAM and run it.
I guess that could be done with a Linux guest as well but testing x86 guest may not bring much.
Quote:
You could then see the difference between emulated cpu (qemu default? smiliar to cpu emulation of PPC hardware?) and hardware virtualiziation/cpu emulation (start qemu with -enable-kvm).
I guess that could also be tested with trying to run a Windows guest with TCG if somebody already has one set up or a Linux live CD or anything but this won't give too much info on VRAM speed or PPC emulation. I'm quite sure the problem is not with VFIO as that's used for gaming setups but much more likely either something with PPC emulation (using optimisations that are not optimal on QEMU) or something unusual the AmigaOS gfx driver does and is not optimal on these machines.
Quote:
And I guess the AROS vesa driver should work with passed through radeon gfx card? So you can then compare those results with AOS4 with same passed through radeon gfx card.
I don't want to make it work at all costs and just interested in if it's possible so I will do as much testing as I feel like and have time for so if others do tests and share results it may help, otherwise it may take a while for me to find it out alone.
Quote:
In case this kind of tests is more difficult/annoying in Linux guest and/or Linux host ...
I think it would be easier to test with a Linux guest than with yet another OS that is not directly comparable to what AmigaOS does. I already have the benchmark compiled for Linux (I think I've posted it somewhere on the QEMU list a while back) and used that to test with qemu-ppc which was optimised for RAM but not VRAM. I could try the same with qemu-system-ppc but I had no time for that yet.
@white We don't know why sound is broken on your machine so can't really help. You said it worked until tried to use passed through card. I said it may have to do with running QEMU as root so you could try removing passed through card and run it with -device sm501 first as normal user and confirm sound works then as root and see if you get the issue. If so it has nothing to do with the pass through card but with running as root. Then if that's the problem find out how your distro handles that. If that's not the problem I have no idea. I don't even have pass through set up so can't try and works for smarkusg with sound and he never had this problem so what do you expect? How could we know how to fix it?
I dug up the benchmark we got before that does what the Gfx2D benchmark does and did a quick test on current QEMU. This is just copying between two malloc regions, not to actual VRAM but it can test the emulation overhead.
Running with just CPU emulation with qemu-ppc (user emulation that runs a Linux executable complied for different arch) I've got:
So whatever tricks FromVRAM does can slow it down and I think that was dcbz.
Looking at the benchmark it looks like ToVRAM uses dcbt which does nothing on QEMU so no problem but FromVRAM does dcbz which is still a problem. Maybe it does not really need to zero the destination before overwriting it but could be that dcbz was supported on more CPUs so that's why that's used and not something else that may not be available everywhere. In any case I think dcbz is also the same issue why the Tricky test in RageMem is bad and it also affects MacOS so this should be solved for all.
Maybe it does not really need to zero the destination before overwriting it but could be that dcbz was supported on more CPUs so that's why that's used and not something else that may not be available everywhere.
Ideally it should use dcba instead like for example my newlib memcpy() and IExec->CopyMemQuick() implementations did on supported CPUs without AltiVec. No idea if any of my old code is still in use in current newlib.library and/or ExecSG versions.
On CPUs with AltiVec the vector streaming instructions should be used instead. As an alternative simply using 2 successively 128 bit AltiVec register writes to RAM, without any other CPU instruction between them, and without using the streaming instructions, works as well.
All 3 methods avoid the read cache line, modify cache line, copy back cache line cycle, which is used on 32 bit PPC CPUs for all smaller (32*8 bit char, 16*16 bit short, 8*32 bit int and 4*64 bit double) accesses to write a complete 32 byte cache line to RAM and just write the data to RAM, which is important on real PPC CPUs, but all 3 methods should work with QEmu without slowdown as well, unlike using dcbz.
dcbz has to be used as replacement for dcba on some CPUs which neither support dcba nor AltiVec, but it's additionally wrongly used for "security reasons" as dcba replacement even on CPUs which do support dcba. Even if it may not be stated in the PPC user documentations dcba doesn't only allocate a cache line, which could be a possible security problem if old contents would still be in it, but does clear it to 0 as well, just like dcbz does. At least on all 32 bit PPC CPUs supported by AmigaOS. The only difference is that dcba is a no-op on cache inhibited memory like VRAM while dcbz causes an exception and is emulated by the kernel exception handler, which is of course very slow.
@joerg According to QEMU dcba is available on embedded CPUs (440, e500, e5500) and G4 so only G3 and classic Amiga accelerators might need dcbz. But that also means that all old software will likely use dcbz so even if it's fixed in AmigaOS now (which then we will also need to get as an update eventually) it won't fix all problems with existing software, and the same problem also exists with MacOS running on QEMU. So the dcbz needs to be optimised in QEMU anyway for those.
I'm not sure about the exception you mention. I did the test on Linux guest, no AmigaOS so unless that would do the same this isn't the problem. Also target/ppc/mmu_common.c#L322 says it will do nothing so I'm not sure the guest would get an exception on QEMU. It's just the current implementation of the dcbz helper goes through probe_write or an even slower loop which is very inefficient. It might be faster just to translate dcbz to a loop writing cache line size zeros which my patch attempted and without being too much optimised it was a bit faster. Some of that inspired some optimisations that at least helped the user emulation case but also means my patch does not apply any more and I don't want to redo it. Somebody interested in this could do that, QEMU is open source and anybody could contribute, it's not something that only I could fix.
The benchmark is in the message I've sent to QEMU list linked above so anybody could also modify it to test VRAM on any guest OS they like and see if that's worse or same as accessing RAM (to verify how much of it is dcbz and how much is the overhead of smaller transfers). That's also not something that only I could do. That's why I'm sending these to here and to the QEMU list so if somebody wants to help this is open for experimenting and sharing ideas and even code with open source. I may do it eventually if have nothing better to do but it would be faster if more people helped.
According to QEMU dcba is available on embedded CPUs (440, e500, e5500) and G4 so only G3 and classic Amiga accelerators might need dcbz. But that also means that all old software will likely use dcbz so even if it's fixed in AmigaOS now (which then we will also need to get as an update eventually) it won't fix all problems with existing software,
Benchmark tools like RageMem and GfxBench2D, with own implementations of such functions, are very rare exceptions, 99.99% of the AmigaOS software simply uses the C library bcopy()/memmove(), memcpy(), ... or kernel IUtility->MoveMem(), IExec->CopyMem[Quick](), ... or IGraphics->ReadPixelArray(), IGraphics->WritePixelArray(), ... functions instead of trying to implement more than 5 different versions of each of those functions for the various different PowerPC/POWER CPUs themselves.
Quote:
and the same problem also exists with MacOS running on QEMU. So the dcbz needs to be optimised in QEMU anyway for those.
Strange. At least Apple's G4 code uses dcba as well, not dcbz, and in a similar way than I did in my AmigaOS 4.x C library and kernel functions: https://git.saurik.com/apple/xnu.git/b ... k/ppc/commpage/bcopy_g4.s (Main difference: My functions were 99% C code, with only some asm inline("dcba"), asm inline("dcbt"), etc., instructions, while Apple's slightly slower code is 100% assembler instead.)
Just make sure you use a suitable CPU for MacOS PPC emulation as well, and not some junk like the 7400 as you initially did for the Pegasos2 emulation
Benchmark tools like RageMem and GfxBench2D, with own implementations of such functions, are very rare exceptions, 99.99% of the AmigaOS software simply uses the C library bcopy()/memmove(), memcpy(), ... or kernel IUtility->MoveMem(), IExec->CopyMem[Quick](), ... or IGraphics->ReadPixelArray(), IGraphics->WritePixelArray(), ... functions instead of trying to implement more than 5 different versions of each of those functions for the various different PowerPC/POWER CPUs themselves.
I guess benchmarks were written to test something that's used by AmigaOS. If not then they aren't quire measuring what they should. According to the above there might at least be 3 or 4 different routines in AmigaOS and depending on which one is used we might get different results. I don't know what AmigaOS uses but we were investigating GfxBench2D results and Hans posted the benchmark for that so it should be similar and GfxBench2D was written to test what AmigaOS does so it should be similar to at least one of those routines in AmigaOS too.
At least one particular version. I haven't tested it but I had the reference in the message where I read about that. I did test that having dcbz in the benchmark from Hans is slowing down QEMU and so probably GfxBench2D too.
Quote:
(Main difference: My functions were 99% C code, with only some asm inline("dcba"), asm inline("dcbt"), etc., instructions, while Apple's slightly slower code is 100% assembler instead.)
Maybe you used a newer C compiler with better optimiser and Apple had older compiler. I guess they did an assembly version for a reason and it was faster for their use case.
Quote:
Just make sure you use a suitable CPU for MacOS PPC emulation as well, and not some junk like the 7400 as you initially did for the Pegasos2 emulation
I'm not sure that would make a difference. The comments in the above quoted bcopy source say that these would be patched to nop for 7400 and dcba is nop in QEMU anyway so it should not matter.
I went back to using Arch it works better than Ubuntu for me.
Now everything works hardware acceleration demo etc. But the audio is still missing with Arch I do not receive the audio error sndio ac97.
I think I understood the problem but I have not yet found the solution on Arch
Initially during the installation with the USB stick for the installation in SETTINGS / SCREENS I have the possibility to choose how to set the two monitors but at the end of the installation the option disappears and I can no longer choose the monitor with Radeon.
At the moment for Nvidia I solved it this way: GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet nvidia-drm.modeset=1 rd.driver.pre=vfio-pci amd_iommu=on iommu=pt vfio-pci.ids=1002:6798,1002:aaa0"
THIS allows me to have on the main screen with the Nvidia GPU all controls from the BIOS to the main Arch screen this is the command:
/etc/default/grub
nvidia-drm.modeset=1
It would basically need the same command for the Radeon GPU to make it work in (modeset=2)
But I can't find the command or a program to split the two GPUs that's why the sound is NOT heard on the Monitor where AmigaOS opens because there is no active option for the second Monitor.
Suggestions ?
Thanks
I'll leave a link if someone finds the solution quickly or I need a program to manage the two monitors
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
Initially during the installation with the USB stick for the installation in SETTINGS / SCREENS I have the possibility to choose how to set the two monitors but at the end of the installation the option disappears and I can no longer choose the monitor with Radeon.
This is expected as you assign the Radeon to vfio-pci driver so it won't be visible to the host any more. You can't use a card on the host and pass it to the virtual machine at the same time so it's removed from the host and given full control to the guest. So after vfio-pci is set up you can pass through the card to the guest and the guest can drive it but the host won't see it as a GPU only in lspci as a device using vfio-pci driver.
Quote:
At the moment for Nvidia I solved it this way: GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet nvidia-drm.modeset=1 rd.driver.pre=vfio-pci amd_iommu=on iommu=pt vfio-pci.ids=1002:6798,1002:aaa0"
This should also work. You likely don't need amd_iommu=on as that's the default and amd_iommu does not take "on" as a valid value so it is just ignored. What makes this work is rd.driver.pre=vfio-pci which may do what softdep pre lines do in modprobe.d/vfio.conf and gets vfio-pci loaded before the GPU drivers so it can bind to the card. It does not matter what way you reach that point, what's important is to have the card and all other devices in that IOMMU group assigned to vfio-pci.
Quote:
THIS allows me to have on the main screen with the Nvidia GPU all controls from the BIOS to the main Arch screen this is the command:
/etc/default/grub
nvidia-drm.modeset=1
It would basically need the same command for the Radeon GPU to make it work in (modeset=2)
I'm not sure that makes sense but I don't know what this option does. You don't need a graphics driver for the Radeon but have to assign it to vfio-pci if you want to use it in the guest. Then it's normal that you won't see it on the host.
Quote:
But I can't find the command or a program to split the two GPUs that's why the sound is NOT heard on the Monitor where AmigaOS opens because there is no active option for the second Monitor.
I said this before but maybe wasn't clear enough. You can either use via-ac97 and then sound should play on the host like any other apps. If it doesn't it may be an issue with running QEMU as root. You can test this without pass-through: just run AmigaOS Install CD with -vga none -device sm501 like before any pass through then if that works try to run the same command as root still without pass through. If sound is gone when you run as root it may be an issue with security settings of the host Linux that does not allow QEMU to connect to the sound server if not run as your user.
Another possible way that should work is to pass through the sound function .1 of the sound card as well such as -device vfio-pci host=x:y.0,multifunction=on.x-vga=on -device vfio-pci,host=x:y.1 then you should see an HDMI output in the AmigaOS guest and then can set AHI to use that then you should hear sound on the monitor where the Radeon is connected.
Now try to see if with ( sudo ) with Silicon if the audio is not heard.
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.