What the fastest possible x64 emulation way of OS4 today ?

@balaton

Linux:
SSH service status
it clearly tells me that the "white" user has been accepted and is connected to port 22

NMap detects the connection on port 22

Amiga:
SysMon tells me that the "white" user is SSH using to port 22 my IP Linux machine.
And it detects that my graphics driver is using DISPLAY "0" or "10" depending on what I want to choose


to make a brief summary this can also be achieved with 10.0.2.15
but AmiCygnix will not work without an external IP using the graphic DISPLAY.

Because from the terminal I have full access to any Linux system from the Amiga terminal.

I can also access VMWare with Linux at the same time
Or on real Linux machine.

But the problem always remains that of the Display in practice I can not use firefox ffplay and other applications.

I always welcome any advice especially from you who are making qemu better and better.

When I see a user in this post who has been able to use AmiCygnix with DISPLAY then I will look into further options.

But I'm convinced that I'm not 'mistaking the configurations.

Indeed, because someone does not try at least you can have confirmation of its operation.

---------------------------------------------------------

@cygnusEd
It would be nice if you did some tests
with qemu to see if AmiCygnix works

Because I tried a lot but I couldn't

I had the same problem with WinUAE but as soon as "NPCAP" was installed, the external IP was obtained, it took me a few seconds to configure everything and it worked immediately.

@Hans
Yes the register names currently match Rage128Pro but I'll change CCE regs to use Radeon names as those are only used by MacOS for Rage and once we get Radeon working better probably that will be preferred. I've only included these in the logs as they clearly demonstrate the endianness problem. In the meantime I've found that some regs are accesssed via ther IO BAR and those should be little endian while the MMIO regs BAR is switched to big endian. In QEMU the IO BAR is just an alias to the MMIO region so I can't switch endianness separately but this is easy to fix and doing that I now get correct endianness values in register accesss. What I still need to find is when to switch modes as AmigaOS seems to enable dispay and DAC before setting up resolution, timing and pixel format so when later it does that again that's ignored by ati-vga because every guest does this differently and it causes flicker when later setting display parameters changing window size so ati-vga only enables display when writing some regs which worked so far for other guests but AmigaOS seems to do yet another sequence so I'll need to tweak this to get some picture.
Quote:
I think this may be related to some mixup with x-vga=on and adding an emulated VGA as well. It may happen that the BIOS is partially talking to the emulated VGA instead of the passed through one and that's why it fails to run? I think what should work is passing through the card with x-vga=on and only using bochs-display but this to work may need the issue mentioned in the comment in QEMU vfio-pci fixed. Somebody may want to look at that comment and find out what it means and if it's relevant for passing through a 9250.

@geennaam
What firmware output and BIOS ROM resutls you get when using x-vga=on with 9250 and bochs-display? Does the pegasos2 firmware runs the card ROM in this case, does it init the display? I think mixing passing through a VGA card without its VGA bits and emulating those separately does not sound like a good idea if the card ROM wants to talk to the VGA part too. ATI ROMs have VESA BIOS ROM so likely wants to use the VGA bits too so I think those should come from the real card as well but this may need some set up on the host. I've read somewhere thatusing i915 driver for on board Intel GPU on the host may have problems with passing through VGA so you may either need a kernel patch (which disables acceleration on host) or not load the i915 driver (which disables graphics altogether on the host so you only get text console). There may be some info on this is these posts (that I did not read yet but I think it might help):
https://vfio.blogspot.com/2014/08/vfiovga-faq.html
http://vfio.blogspot.com/2014/08/what ... with-vga-arbitration.html
https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF

@balaton

Hey, .. for the rest I'm not making videos because I don't really want to.

But the emulation is really satisfying and I'm very happy and thank you very much.

It's just amazing to emulate AmigaOS for me having used it for many years with WinUAE.

I am always convinced of the idea that bringing Voodoo3 even if imperfect would bring many more qemu users closer.

But you already answered that

Thanks again for your work.

And I hope you will receive many donations for your work because you deserve them

@kas1e
Quote:

Maybe because tryuing to pass through PCIe cards to a machine that has only PCI just can't work but if that's not the problem then maybe it could be fixed but needs to be understood better first. I don't know mA1 and how that can use HD/RX cards. What bridges you use there? Is there a way somebody solved it with real pegasos? The results I've seen so far suggest either the card ROM is not running correctly or the VRAM BAR is not mapped for some reason, maybe because it's not where older cards have it and firmware does not handle that or maybe it's too large for PCI? I don't know somebody who wants this to work should look at it and try to find out.
In the meantime I'm trying to figure out how PCIe works on sam460ex so I can emulate that then we can also try with that and compare the results which mihgt help us further.

@white
I've linked some docs before that says for remote X connections you need these things:
1. The X server where you want the window to appear (AmiCygnix in this case) should allow connections on port 6000 for its display 0. This may need adding -listen tcp on newer Linux systems but don't know how to check that on AmigaOS.
2. The X client (app you want to run) has to be able to access that port over the network. You either need the two machines see each other like through a tap device or via port forwarding in slirp. In the latter case you'd have host port 6010 forwarded to guest port 6000 so connecting to localhost:6010 on the host is like connecting to 10.0.2.15:6000 on the guest but you can't access that network directly as it's behind slirp's NAT so you need the port forwarding. It's the same as setting up a web server running on the LAN to be accessible from your router's IP for outside machines. To have X client connect to localhost:6010 set DISPLAY to localhost:10
3. The X server authentication must allow the guest to connect. You may either need to copy .Xauthority to the guest or disable X auth altogether with xhost + which is not recommended of your machine it accessible from outside becuase then everybody can snoop your keyboard but may be OK if it's behind a NAT and only accessible from the host.

All the above should be taken care of by ssh X forwarding so if you already can ssh from AmiCygnix to your host then just enable X forwarding in ssh server and client config and use ssh -X or ssh -Y which should set up authentication and DISPLAY itself and forward traffic over the ssh connection so you don't need to separately configyre port forwarding either.

@white
Quote:
Yes, I said I won't do that because it's enough for me to work on the machines emultaion and qti-vga but QEMU is fortunately open source so anybody who thinks it would be useful and has time to do it could take that up and contribute the results upstream just how I do with these machines
Quote:
So far I've only recieved one donation but I made it clear that while I'm happy to get donation if you want to give, but I don't think there are enough people interested that this could recover the costs so maybe donating time and helping out is more valuable and helps everybody.

@balaton
You are really very kind and thank you for the very detailed explanations.

But believe me I've tried everything but it doesn't work even if the procedures you recommend are right.

I'm convinced it's the RTL8139 driver that maybe doesn't fully work (maybe).


as I wrote above
only the author of "Amicygnix" could try to see if it works.

@whiteQuote:

If we're going to do it right, the GPU passthrough tests that are going on right now will share a lot of information that may help us understand things better.

I think @Balaton could also use the information gathered to improve the ati-vga emulation and eventually get the AmigaOs4.1 Radeon drivers working.

Otherwise you could alternatively use like @geennaam did via PCIe to PCI bridge and real hardware (Radeon 9250) graphics cards under QemuPeg2 and AmigaOs4.1. However, this will not be a solution for Macs with M1 chipset because it is no longer possible to use external graphics card solutions.

I am glad that I decided a year ago to test the Qemu Peg2 emulation extensively and with the help of @Balaton was successful.

I can also confirm that this emulation is the best experience for me at the moment to use AmigaOs4.1.

Again briefly to donate....

I have already donated, because I am convinced of this Qemu emulation and I am also aware of how much work has already been put into it.

@Maijestro

I agree with you.

-------------------------------

I don't know if this also occurs on real hardware
(voodoo3)
with WinUAE
Warp3D in the tests included in the package once the drivers for Voodoo3 are installed
the gears.ppc that turns now I can't think of the name
have the defect of being transparent in the "center"
it would be interesting to see if the same happens with the real voodoo3 card with the use of qemu.

Because if it doesn't happen it would be really good.

But from my tests carried out in emulation 70% between demoppc games
etc. they worked fine.

only that it only supported 16bit screens and not "composite" and other small glitches on the AmigaOS desktop update
but I always talk about WinUAE probably with qemu the approach is different (but I don't know).

@white

@balaton

I get the following messages on my terminal:

@geennaam
Quote:Only PCI versions are that "cheap", AGP versions are a little bit more expensive, about as much as a Sam460 🤣

@kas1e

Quote:

I was able to start QEMU with sm501 display while the RX 560 was in passed through.

@balaton

Radeon 9250 will always result in a segmentation fault. No matter what other display I use (or none at all). And on which bus it is connected.

@Balaton
Quote:

As far as i know, no one were able to made real pegasos2 works with RAdeonHD/RX cards over bridges , but with microA1 i was a little bit wrong, it was about AmigaONE XE, there is relevant article about from Salor : https://www.amigaportal.cz/node/159407

ps. If you need any tests on real pegasos2 i am ready to do fast tests if you need it

@geennaam

Quote:

A little too technical for me, but, is it fixable in drivers ? Will be good to be able to use PCI bridge to use RadeonHD/RX on Pegasos2 (that will help and real peg2 users and help quite much for emulation).

@geennaam
Correct, the first output above the blue bPlan logo is from the VGA BIOS the rest is SmartFirmware. You can see the same running cirrus-vga with the Bochs vgabios from here: https://www.nongnu.org/vgabios/ which does not crash under pegsos2's BIOS emulation as described here: https://osdn.net/projects/qmiga/ticket/47860 but I thikn it still prints some errors so not all errors you see may be fatal and these may happen on real hardware too.

I never had Voodoo so don't know much about it but I think itmay be different because unlike ATI cards it does not have VGA part so needs a separate VGA card so that's expected config and should work. However if the firmware can use a Voodoo card without needing a vga this may not be necessary. PCs need a VGA to boot as the BIOS can only handle that but it may be different on NG Amigas. Since there's no VGA part on the Voodoo I don't know if using x-vga=on for it would make sense. It may just enable some dummy registers which supress the warnings but it is works without x-vga=on then those warnings may be harmless.

But if you use VGA together with an ATI card that already has VGA itself those might clash. So I think for this config x-vga=on may be needed and if need a second display then use -vga none and sm501 or bochs-display which don't have VGA parts. It could be that as the comment in source suggests x-vga=on does not work for older Radeon cards so you just avoiding that problem by adding an emulated VGA so the ATI card's ROM thinks it talks to the VGA part of the card but those writes don't actually reach the card and if that's needed to init it correctly then it won't work. Therefore I think the x-vga option should be investigated and fixed if needed to make the pass through work correctly but I'd let somebody else handle that. I may be wrong about all the above as I don't know the details but that's what I think is happening unless I see more info to prove that wrong. I've asked what errors you get if you only have ATI 9250 with x-vga=on and no other VGA in the system, I know that does not work but I'd need the errors to find out why as I think that's how it sohuld work and not how you managed to get past it as then it did not work so that may not be a viable work around if the problem is elsewhere.

As for needing second card to get input it's just a simple way to do that as the emulated keyboard and mouse will be bound to that window but you could also pass through either a USB controller or input devices to the guest and use those for input. There's some info on this in the long Arch Linux page I've linked above. That's how it's normally done.

By the way some guides recommending to use OVMF is probabnly also to avoid problems with x-vga=on or cards not resetting properly as that will then run the EFI ROM of the card which probably does not need legacy VGA like the normal VESA BIOS does. But again I'm just guessing don't know for sure so don't take this as advice just thinking aloud.

@geennaam
For RadeonHD/RX cards I was suspecting it's a problem with 64 bit BARs and in that case I'm not sure it can be fixed because the pegasos2 is a 32 bit system so there may not be enough space in the memory map to map these even if the PCI controller may support these (which probably it doesn't as I did not expect it to be needed so maybe the Marvell emulation may also need to be checked for this). The X5000 and sam460 may use newer CPUs that at least have larger virtual address spaces which may be needed.

But @kas1e said this somehow works on microA1 which is similar to pegasos2 so maybe it's possible but I've found no info on that so I don't know how that's done. Maybe Hans can fix this in his Radeon drivers and already works on it. If it turns out there's some issue in the pegasos2 emulation I can look at that if somebody finds out what's needed.

@balaton
With microA1 i was a little bit wrong, it was about AmigaONE XE, there is relevant article about from Salor : https://www.amigaportal.cz/node/159407

@balaton
Quote:Voodoo 1 and 2 were 3D add-on cards only and need another VGA card, but Voodoo 3/4/5 are complete gfx cards incl. VGA: https://bochs.sourceforge.io/doc/docbook/user/voodoo-notes.html