@joerg
This can be tested with QEMU which emulates SiI3112 and it boots fine with "U-Boot 1.1.1 (Mar 3 2005 - 16:42:53), Build: 03/03/05" so I think it should work on real machine too. But maybe there could be some other issues unrelated to the controller and U-Boot such as newer drives implementing different ATA standard versions which may cause additional incompatibility with some drives. Maybe it's not without bugs though as it only recognised a CDROM on first port. When connected to second port with first port empty it did not find it but connecting to first port and then selecting SII Serial CDROM from boot sequence booted. Here's the command to emulate this setup that I've tried:

The ide.0 and ide.1 are the VIA southbridge PATA ports, ide.2 and ide.3 are the SiI3112 SATA ports (you can find this with info qtree -b in QEMU Monitor). It did not find CD with bus=ide.3 but works on ide.2. (You won't see graphics without -device sm501 and boot.iso with SM502 driver added but it's enough to test booting.)

@joerg
Quote:
The latest A1XE U-Boot still available can be found on Hyperion's site and is version 1.1.1. If there are later versions those are not published. As can be seen in this picture this U-Boot has a Hyperion copyright at the bottom although that may only be for the menu system. However even the files not related to menu that were in upstream U-Boot (but removed a long time ago and never really worked) had copyright headers saying:

So this does suggest Hyperion has the copyright for this. When I asked about the sources Thomas Frieden answered that these were in the Hyperion SVN but that's not around any more and nobody seems to know if it was back up and where that backup is. If somebody at Hyperion can find it it would be nice the publish these sources according to GPL.

@smarkusg
Quote:
OK so you see some improvement but there are still some questions. Is it really necessary to patch out via-ac97 from QEMU or is it enough to just use a passed through card instead without any patches to QEMU? Have you tested that? Also it may be because of different drivers and not emulation vs. real card so have you tested -device ES1370 instead that uses another driver in AmigaOS? That driver that ES1370 uses can also be tested against a real SB128 so that way it could be found if the problems you saw are related to via-ac97 or emulation. You should see no latency on AmigaOS when sound is not playing even with via-ac97 but it may have some effect when sound is playing.

@SinanSam460
Quote:
Maybe that -drive if=none only defines a logical drive but no device for it. Normally you could add -device usb-storage,drive=fat16 to the command line but the sam460ex u-boot has a bug that it cannot boot with usb drive attached so you have to attach it later from QEMU monitor with device_add usb-storage,drive=fat16 after AmigaOS booted. This is not very convenient but that's what works currently. Also this vvfat drive is limited to about 500MB and changing it from the host while the guest is running is not supported so it's better to use a network share instead.

@white
If the Radeon card is assigned to vfio-pci driver there should be nothing displayed on it until QEMU starts. Do you do the vfio-pci setup in some script running when you log in or how can you get picture on it when you don't even have drivers for it installed on the host? If you set up the modprobe config as I described it on my vfio page there should be no picture on the Radeon card from the host as it's assigned to vfio-pci from the start. If the bootup during BIOS/UEFI happens on that card then there could be an option in the setup to change that or you can swap the cards until you get your primary display on the NVidia card.
The bochs-display is just to get mouse and keyboard input in case you don't pass through those to guest but you will not get output on the host in any way. The guest is using the Radeon card and outputs via that, the host is using the NVidia card and outputs via that. You have two separate outputs which you can view on a single monitor if you plug both into inputs on that monitor and then you can switch between them on the monitor.

@Mlehto
Unless you use the yet unreleased fixed kernel on a real PegasosII then the kernel up to and including 4.1FEUpdate2 has a known problem with configuring interrupts on PegasosII that BBoot does fix. This was found on QEMU but affects real PegasosII as well so using BBoot on that might help too (and it also boots faster). This can lead to lost interrupts if multiple devices use the same interrupt and that happens more on PegasosII due to how the firmware assigns interrupts. The BBoot README has some info on how to use it on real PegasosII. Removing a card may only help by reducing number of interrupts so the problem happens less frequently but it's not really fixed. Only updated kernel or BBoot fixes that config issue.
On QEMU this problem is fixed using BBoot too but interrupts still don't seem to work with passed through graphics cards so that's a different and unrelated issue that is not fixed yet which likely does not affect real machines but specific to vfio-pci.

@joerg
AC97 is old and only supports a few fixed frequencies between 8 and 48 kHz and stereo. Additionally only single PCM output channel is implemented in QEMU. But that's probably enough for most users who just want to listen to usual sound output. How higher bits, freqs and Dolby surround is relevant in most applications? Is there even anything in AmigaOS that supports that? The other card emulated by QEMU that AmigaOS has driver for is ES1370 which works with the SB128 driver and it may be a more complete emulation but I don't know its limitations.

But the whole starting point of this was that smarkusg added a sound card on the assumption that it's better than using the emulated one. I'm trying to find out if that assumption is true and the emulated sound card really adds an overhead that can be avoided this way. I haven't seen any proof of that yet. It may be true but this should be verified and not just assumed.

@white
If you only use the Radeon card for AmigaOS then you don't need drivers for it on the host. To be able to pass it through to the guest, it has to be unbound from host drivers and assigned to vfio-pci driver so the host won't use it anyway and the drivers are blacklisted to not load before vfio-pci, so it does not matter if they are installed or not. That driver won't be used anyway, but better not to install them at all, just to make sure they won't interfere with vfio-pci. So no, you don't need Radeon drivers for Linux.

I don't understand what is your problem. You said your monitor has 2 HDMI inputs (and some others). Can't you just plug in both cards in different inputs and select which one to view in the monitor's menu? It's documented in the monitors manual and if you search for it there are other detailed docs on how to do this so why do you make your life more complicated with additional switch box? But if the cats need it or you find your life too boring otherwise then it's up to you.

@smarkusg
Quote:
So does that mean that no patching of QEMU is needed and no changes to installed drivers like moving some to Storage are needed but it's enough to just select a diferent driver? And does that make any difference? Is it faster to use a passed through sound card than using the emulated via-ac97? If there is a difference how much or why is passed through card better?

@white
Quote:
So ChatGPT suggested this but it can't explain why? Can it even tell you what the opion does or where it got it from? It looks like ChatGPT managed to help you by chance and not because of any intelligence. The 'set | grep QEMU' verified that you have no enviroment variables related to QEMU so this has nothing to do with QEMU_AUDIO_DRV mentioned by ChatGPT. Also all the other env variables it mentioned are irrelevant. Pipewire or Pulseaudio or whatever your distro uses may depend on some environment variables though to know where and how to connect and these are not preserved in sudo unless using this option. I don't know which variables may those be but one of the lot printed by the 'set' command without |grep. And it's not '--preserve-env qemu-ppc' but 'sudo --preserve-env' as it's an option to sudo, the qemu-system-ppc is another argument to sudo here which is the command to run.

@white
Did your monitor come with a manual? Maybe try reading that. As I said think of it like having two machines each with their own graphics card. You can connect two machines to this monitor and then you can view one of them by selecting the input you want to watch. Some monitors can even show multiple inputs at the same time often called picture in picture but that only happens in the monitor so you can't record that in the host that way.
You get lost because you're not specifying your goal clearly. Is your goal to view both machines on one monitor (then a monitor with multiple inputs will do but you can only view one at a time) or view both without having to switch on the same screen (then a monitor that can show multiple inputs is needed) or is it to record the guest (in that case you need to digitise the output of the virtual machine and show that on the host so you need a capture card in the host for that).

@white
Quote:
Apparently you did not understand the explanation. How would you make a video on one machine of the monitor of another machine? So this won't work the way you might think. You would either need to make video on the guest but vokoscreenNG does not run there or maybe you need a video capture card where you plug the guest's GPU so you can view it on the host in a window then you can make a video of that. Remember that you have two separate machines with their own video cards. Forget that one of these is a virtual machine in the host, it still behaves like a separate machine.
Quote:
I don't even understand that. You can't use a single monitor with vfio-pci as the guest uses a dedicated GPU different from the GPU of the host. I doubt you did that with FS-UAE as it can't use vfio pass through of real GPU as far as I know. The only way to use a single monitor is to use separate inputs on the monitor and you then can switch between the two machines but can't view them on the same screen (unless your monitor does picture in picture but you can't record that).

@white
Quote:
Only if your monitor have multiple inputs or you use a monitor switcher because the two GPUs have their own outputs so you'll need to plug them somewhere to see their picture. You have two machines: your host and the virtual machine that now uses it's own graphics card so you need two monitors to view the output of two machines or any other way you would use to view two machines. That's why it's called a virtual machine, because it's like a real one just lives inside the host machine and not a physical one.

I think the QEMU_AUDIO_* env variables were removed in later QEMU versions and won't work in current version regardless of what ChatGPT told you. To configure audio backend in QEMU now you have to use the -audio option but that's not normally needed. If you haven't set any QEMU_AUDIO variables then they aren't there. You can check with set | grep QEMU and if that returns nothing then it's some other env variable needed by pipewire that needs to be preserved for sudo.

Edit: Here's the commit that removed QEMU_AUDIO_DRV almost 2 years ago.

@Reynolds
I don't have experience with the real machine, only know some things about it from writing emulation of it but I recommend studying @sailor's articles at https://intuitionbase.com/tag/amigaone-xe That should answer some questions about accepted memory.
As for sound I think some of the motherboards omitted the codec chip as they could not make the AmigaOS driver work with the VIA chip so it was thought to be useless. I think this is the small square chip inline with the AGP slot near the edge of the board next to the ports at the back. There are two pictures at https://intuitionbase.com/system/amigaone-xe and one of those does not have a chip there. These are not too high resolution so hard to see but here's another picture where that chip is missing. If your board does not have that codec chip then on-board via-ac97 audio won't work. A sound card that AmigaOS has a driver for should work.
I had no problem with emulated USB so I think it's supposed to work. Does your USB port work with a keyboard or mouse? Maybe it's just the devices you plugged in were not recognised for some reason but it could be real machines has some issues I'm not aware of.

@white
Glad that you solved it finally. Apparently the sound server you're using needs some environment variables that were lost with sudo. As you see it has nothing to do with QEMU or AmigaOS but with your Linux host and pipewire/pulsaudio or whatever that uses.

@white
Maybe because you're not asking questions that I can understand. What is CHANNEL 1?
You can set the default device in /etc/asound.conf. I have there:

where you can list the available devices with aplay -l but I've already told you that before. Your distro may also have some way to set it but if you get audio from your host normally and it's not through the card you're trying to pass through it should just work the same way with pass through. It's not possible to get sound from the passed through card with AmigaOS.
(It's also possible to select alsa devices on QEMU command line and documented at https://www.qemu.org/docs/master/system/invocation.html but I'm not trying to explain that. Set the default alsa device to the card you want to use and it should work. You can check what is the default device in alsa with aplay -L)

@white
When compiling QEMU check the configure output. I have:

and the compiled executable

Without any -audio options this defaults to alsa and works. You don't need jack support either, I just happen to have that too.

@white
I'm still not sure what you're trying to do but in case you want to use the HDMI audio part of the card you pass through that's not going to work. As long as you don't pass it through and have the host driver loaded you can use that output but to pass it through you have to unbind the host driver and assign vfio-pci driver to it so you can't use it from the host for audio output any more even if you don't pass it through to the guest. It would only work if the guest could drive it but AmigaOS does not have a driver for the audio function of the card so you can't use it for audio.
You have to use another sound output on the host (either your motherboard's internal audio or another sound card). If you have another sound card that AmigaOS can use you can also pass that trhough with vfio and select that in AmigaOS. If you're using you motherboard's audio (which up to know everybody assumed you're trying to do) then make sure you get sound from that also when running programs with sudo then it should also work with QEMU.

@Mlehto
The freezes with fully loaded pegasos2 you mentioned was with real PegasosII or emulated? The interrupts are configured by the firmware and AmigaOS could change this but does not seem to do that and just uses what the firmware gave it. I could change the default in QEMU but then you would get different results when booting with original firmware or without so it would be inconsistent. Currently pegasos2 needs BBoot with or without original firmware to fix up an interrupt related problem which may be fixed in an upcoming Update 3 in AmigaOS so if you get freezes without BBoot that's a known issue. If you get a freeze with BBoot it may be a different issue.
Vfio and virtio are different things. Vfio is passing through a real card to the virtual machine so it can use it. This works if you pass through an ATI/AMD card that AmigaOS has a driver for (these drivers are a separate purchase for newer RadeonHD and RadeonRX cards but they are available). This allows using hardware accelereated 3D but needs a dedicated card for the virtual machine and a Linux host. Virtio is an emulated device that is like emulating a real disk controller, network card or GPU but it does not have to care about hardware specific details of a real card thus can be faster in a virtual machine but needs a driver in the guest OS. The virtio-gpu driver for AmigaOS was developed by Hans but it seems to be shelved by his employer and not published yet. This also allows using faster 3D in the guest but unlike vfio it does not directly use a GPU but pipes the 3D commands to the host where it is executed by the host's GPU. So with this you don't need an additional card on the host to dedicate to the guest and don't need a driver for it in the guest so can even work with NVidia cards or newer Radeons that don't have AmigaOS drivers. The guest only needs to talk the the emulated virtio-gpu and the host drives the real GPU.
Theoretically you could use vfio even on a laptop if it has a suitable ATI/AMD GPU which is in an iommu group that can be isolated without losing to many other devices in the host and you can live without the host having a display so you'd need to interact with it via serial or network only as the screen would be driven by the guest. But maybe it's not easy to find such laptop or set this up so for most it's probably not an option.

It was a bad idea to block white's thread. I can't reply there and now he just posts the same again in another thread. Can you undo that? What's wrong with that thread?

QEMU supports different audio backends, including pipewire but since that did not work for you I thought using ALSA is the simplest as that's the most low level audio driver that should work on any Linux after you disable all other higher level sound servers.