@white

@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).

@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.

@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.

@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.

@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.

@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.

@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

@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

@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.

@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.

@geennaam
If this is DNS problem then it may be worked around by not using the slirp DNS but set some other DNS server manually in the guest (only overriding DNS setting not the IP). I think some people on MorphOS who had problems booting also said using manual settings works better and this may be why tap can work better.

If this is an old bug it's probably not fixed because it's not reported to those who could fix it. libslirp is now a separate project not part of QEMU any more so this should probably be checked in their bug tracker and reported there to get somebody look at it.

@white
You can use --enable/--disable options with Linux as well they are not specific to macOS. The dbus and slirp options should be auto detected so if you have libslirp-dev (or what is's called on your distro) package installed then user network will be built. Adding --enable-slirp menas it will give error and fail when no slirp is detected instead of building without -netdev user so you can make sure that way tho config will be what you want. The --enable-lto option enables Link Time Optimisation which is a compiler optimisation that will take more time to compile and may be faster or break depending on compiler version. One may try to enable even more compiler optimisations with --extra-cflags=-O3 but not sure if that helps. Compiling from QEMU master has latest patches that may improve FPU a little but may need the disable dbus option if you get an error related to that.

For the network it may depend on your QEMU command line. When using -detdev user then the guest can only use the 10.0.2.x network that slirp presents to the guest and will NAT traffic from it to the host network. If you enable DHCP in the guest the it will get an IP address starting from 10.0.2.15 from slirp's built in DHVP server and it will configure other parameters to use slirp services. You can manually set another IP address such as the 172.18.x.x one you did but that won't work with -netdev user. It's like connecting a machine to a router that's set up to use 10.0.2.x but manually configuring that machine to use a different network.

With -netdev tap no NAT, DHCP or DNS services will be provided by QEMU, all it does then is to connect the emualted card to the tap device on the host and then you can configure it and route it how you like it. That means you'll either need to do NAT on your host with iptables to allow the guest to access the internet or bridge the tap device to your physical network card inthe host to allow the guest to access your LAN and get an IP address from your router or just use the tap device to communicate with the guest from the host like it was a virtual network cable on end plugged in the host and the other end in the guest.

I think the problem is that you don't yet fully understand these options and therefore not configuring these correctly. Either search for some docs and learn about this or just forget all that and use -netdev user with the hostfwd option I've told before to redirect guest port 6000 to host port 6010 and in AmigaOS do not set any network parameters manually just set it to use DHCP which should set everthing correctly.

@geennaam

Thank you for your answer.

@balaton

because even if i choose 172.18.1.1 as static ip
Then in "Ranger" for example I see 172.18.1.1
but I believe it's just masquerading as "TunTap"

but actually at the next restart of qemu I can also choose:

-device rtl8139,netdev=mynet0 -netdev user,id=mynet0

it gives me the same IP 172.18.1.1 without me choosing TunTap

while it should not accept the IP 172.18.1.1
why with:
-device rtl8139,netdev=mynet0 -netdev user,id=mynet0

should only work with 10.0.2.15
it is clearly not with an external IP

here is the reason for my question.

This is clearly not a criticism
Indeed it is a signal of something that perhaps should be fixed if possible in later versions of qemu (pegasos2) etc.

it's part of reporting small constructive bugs

@white

@balaton
@all

I have a question
With the Ryzen the commands for compiling qemu are standard
I am:
./configure --target-list=ppc-softmmu

or is it better:
./configure --target-list=ppc-softmmu --disable-dbus-display --enable-slirp --enable-lto

because I can't figure out if the command above is specific for "MAC" systems or is it also valid for Ryzen systems

Also I would like to know if anyone works AmiCygnix
also in the light of the functioning of the real Voodoo proven.

Because I am convinced that RTL8139 is currently unable to get an external IP for some reason.

And it actually always adopts 10.0.2.15 whatever configuration is chosen via "TunTap" too

because in theory I shouldn't be able to delete the configuration in use in DEVS/NETINTERFACES/RTL8139

while instead with the active connection I can delete the file
DEVS/NETINTERFACES/RTL8139

while it should reply that the file is in use and cannot be deleted.

Also I would kindly ask "geennaam"
if you can verify the correct functioning of Amicicygnix on your configuration.

A thousand thanks.

@geennaam
Quote:

That quite a lot for non-real hardware and just voodoo3. Sadly it's uknown why pegasos2 can't handle radeonRX/HD over bridges :( Even mA1 can (which is even older).

@balaton

The PM4_MICROCODE_ADDR, PM4_MICROCODE_DATAH, PM4_MICROCODE_DATAL registers have a different with the RV100 chipset, but they're essentially the same thing: they're used to load in microcode for the command processor. Here are the register definitions:

#define RADEON_CP_ME_RAM_ADDR 0x07d4
#define RADEON_CP_ME_RAM_RADDR 0x07d8
#define RADEON_CP_ME_RAM_DATAH 0x07dc
#define RADEON_CP_ME_RAM_DATAL 0x07e0

As for geennaam's actual Radeon 9250, the reason why it won't work on AmigaOS 4 but does on MorphOS is most likely down to the OS4 driver needing the firmware to do the low-level initialization properly. If the MorphOS driver includes code to do that, then it'll work even if the firmware doesn't. IIRC, AmigaOS 4 does have code to run the VGABIOS, but it's only included in AmigaOS 4.x for classic Amiga hardware (where it's needed if you have a Radeon card plugged into a PCI bus like the Mediator).**

Hans


** AmigaOS 4.1 for classic Amigas comes with an x86emu.resource.kmod.

@rjd324

I've been seeing that for years on my X1000 (I thought I was the only one...), ever since I upgraded from 4.1.6 to FE Update 1. I was hoping Update 2 would fix it, but no luck.

As with you, it seems random and completely unpredictable. I've only seen it on Workbench windows, but it's inconsistent as to when it happens, and which window is affected (usually just one window, but not always). It seems more likely after I've been using the system for some time, but that's inconsistent, too.

Sometimes it takes the form of a solid line under the entire title, as in your screenshot. Other times it's only part of the title that's underlined. And sometimes it's more like an irregular dashed line that's different each time I open the window. I've even seen it change while the window is open.

It seems harmless, and doesn't appear to affect anything beyond the window titles. I've never even considered reporting it, since it's so random and irreproducible. I recently upgraded to a new graphics card and driver, but I've gotten so used to ignoring the glitch that I can't even say for sure if I've seen it since the upgrade.

https://youtu.be/S_8hxwI-Xrk

First phase is just downloading mednafen and using it through the command line.

Second it using egame.

Third is ensuring that you set "sound.period to 100000" otherwise you will have bad sound. You should actually READ the README document to see which other variables you can set.

Other than the egame thing this is ALL in the README document already.

If this is not clear enough, I am afraid I can no longer help.