What the fastest possible x64 emulation way of OS4 today ?

@kas1e

I doubt that this will work. It doesn't even comply to the minimum requirements of a 10W slot. The adapter can only supply 12V/6W. My R9 270x refuses to work without proper power supply through the PCIe slot even when I had the 2x6pin molex connected to my PSU.

For cards without external power supply connection like a RX560 this will not work for sure.

@geennaam
I may try some extender as you do for sam440 (i.e., just to add a layer between with additional power). And i also ordered the same bridge from startech as you did before (just in case first one will not work even with psu-extender). For me will be even OK if any HD card will work, as Radeon9250 on pegasos2 make it unusable for today's 3D even on os4

@Maijestro
I thought it was a limit with YT.rexx on 18 (360p)
instead it worked (by chance)
with 22 (720p)
strangely YT.rexx doesn't seem to always "lock" to 720p
indeed almost never on my system and certainly not because the Ryzen is slow because when I hook it it is fluid.

Yet I use your own "mplayer"
i tried 7457 and G3
nothing changes
I see you use -vo sdl

I would like to know your settings in SDL(prefs)
and what SDL are you using (version).

Thank you.

@balaton
Also back on topic yesterday I compiled qemu 8.0.3 with:
configure --target-list=ppc-softmmu

but for Ryzen systems only the line indicated above is needed?
should this enable everything properly?

Thank you.





@derfs

I am aware of the limitations of Voodoo with the (4.1)
WinUAE uses (1gb) of ram and Voodoo(16mb)
never had memory problems for the applications I use
in practice the memory never ran out and I used all possible applications including AmiCygnix with Firefox and used Games etc.
(if you look at Voodoo you don't have to compare it to an ATI because it is clear that they are two different things.
Your observation is correct but sm501 doesn't do the same things Voodoo would do.


@Hans

I'm glad to have received your answer.
Of course I meant Voodoo emulation.

And this is precisely the times debugging tests etc.
It will probably be a long time.
And it is clear that the work that you or "balaton" would do must be respected.
And I don't even know if you're feeling and how you want to set things up as mentioned via A-EON if I understand correctly.

So I ask you why not do a little survey for Voodoo emulation
Market research is also done this way.
And if there are other alternatives in the short term, that's fine.

Furthermore, donations to "balaton" could take place with the emulation of Voodoo by releasing the "separate package" as I said for 50 euros.

But if we are talking about 2-3 years, market research has no value in this case.
Because things change.

Thank you.

And thanks for your portings too
For example, AlienVSPredator also works with Voodoo with WinUAE+Voodoo

@whiteQuote:

I am using the latest SDL2 version of Os4depot 2.28.0 in the prefs of SDL I have the renderer set to software, the rest I have left as specified in the settings.

It is correct that I run yt.rexx with -vo SDL, that has the advantage that I can change the windows in the height and width arbitrarily.

All videos that support 720P on YouTube will be displayed in 720P, videos that don't support 720P will be displayed in the highest possible resolution that is available on YouTube. So it also depends which resolution was chosen when uploading videos. Many old videos do not support 720P and will be played in somewhat lower resolutions.

Also about the Voodoo GFX, you should stop comparing Qemu with WinUae, Qemu emulates AmigaNG hardware and WinUae 68k and PPC Classic hardware. To be as backwards compatible as possible it would be interesting of course, but it would not bring Qemu forward and be on the same level as WinUae is. We can do much more with Qemu.

As Hans and also Balaton mentioned the better way would be to provide Virtio-GPU drivers.

@Maijestro

Perfect now the videos open at 720p
I have chosen some more recent ones
Thank you.

use -g3

https://youtu.be/QPHWaIW2lxg

@white

Quote:

You have many jerks in streaming, remedy could bring here to increase the cache with "-cache 8192".

Since we both use almost the same configuration from me again a comparison with the same video

https://www.youtube.com/watch?v=ueOwpo0XU0s

Maybe it brings some improvement when playing videos via YT.

@Maijestro

You won't believe it but I'm still looking for a solution with AmiCygnix and sometimes I try but without success.

And I let everything else go

Yes you are right the cache options and other things need to be fixed.
Also the video capture software I use is "Kazan"
Without "Kazan" everything is smooth.

"Among other things one of the most beautiful endings ever made for a TV series" and beyond"

Just as a quick update: In the past days I've put together a proof of concept of the replacement boot loader I'm working on and now I could just boot AmigaOS with it but at the moment only using the pegasos2.rom not yet with QEMU's virtual OF. This at least proves that it could work but something is likely missing from QEMU's virtual OF so I still need to find that out and work on fixing that to be able to reach the goal to be able to use pegasos2 without the rom binary.

I also wanted to ask to test some patches for the IRQ issue but currently osdn.net seems to have some network problems from here so I can't upload them there and also did not prepare the patches yet as I was spending my free time with tho boot loader. Does the current patch solve the issue or is there still a problem when using that patch? Maybe I'll just submit this for the 8.1 release if it works as I may not have time to do a more proper fix now.

@balaton

RE: The IRQ level patch, for me, I have had no further issues with devices on bus pci.1. It doesn't help to allow me to move the GPU to bus pci.0 - if I do that then I get an instant freeze as soon as AOS starts. Performance for me is pretty bad. If it wasn't for the higher resolution and colour depth, I would be better off using my MacBook Air but I think this is just down to the terribly low-end GPU I have at the moment.

I have two, supposedly better cards arriving tomorrow hopefully that I scored very cheap on eBay. We will see what happens (one is an R9 270X which should work).

As far as I know derfs is still having to disable interrupts for his card in order to avoid freezes but he is using bus pci.0 which doesn't work at all for me. I don't know if he has tried pci.1 but I can test the R9 270 on bus 1 when it arrives.

I did have a look at the code as I figured maybe the levels needed to be tracked independently by bus number but as far as I could see, internally it was all the same bus so tracking levels per bus didn't change anything (I did try). Bear in mind I also don't know what I'm doing

[EDIT] I should add that since I'm building from source and already on my own branch I can easily test anything you need.

@MartinW
I also have no idea why it won't work on pci.0 as all PCI interrupts are tied together but the twp are different buses (these are created in hw/pci-host/mv64361.c that models the Marvell Discovery II system controller which has two PCI buses). So maybe the current way of keeping track of interrupts that relies on the irq counter in PCI fails. If you read the links in post #812 it was discussed there how we got to this solution but maybe it's not quite clear from all the emails. I wanted to test my original solution what I first posted but that does not apply any more so I had to port that to current master or maybe you can go back to the version before th ecurrent fix was committed and try to apply the original series on that, this was somewhere this January I think but if you can't do this easily then don't spend too much time with it as that series would need to be rewritten anyway so maybe I should do that first and only test that. But it's not likely to get that in 8.1 so either it will stay as it is or I can try to submit the work around you're using now as that may still be better tha nleaving this broken. If we found this eariler we could have try to rewrite this but that's now only possible after the freeze for 8.1 is over so I don't bother much but maybe if I'll have some time I'll try to make a patch to test and see if that can be submitted still.

I experimented some more with my boot loader and I think the problem is that AmigaOS does not seem to scan and map PCI devices itself but relies on the firmware to do that. Both Linux and MorphOS would do that themselves so they work with current virtual open firmware but for AmigaOS looks like I'll need to do that from the boot loader also. This is more work but if I do that patching 64bit bars at the same time will be easy so I had to do this anyway sometimes just hoped it would work without this but it seems it doesn't. The kernel probably starts but does not find the gfx card when it does not have mapped BARs. This might also be similar issue when a PCIe card is not mapped by the firmware so you may need to take care of that from the Forth sctipt or wait for me to finish this in the boot loader.

I'd say you are right. The firmware would need to initialize devices. I was reading up on the VOF but forget if it supported machine routines to reset hardware. While you could do it in a boot loader, doing it as part of firmware or some machine specific extension would reset the hardware state so it could boot anything after normally. There needs to be a device tree so to me it makes sense the devices are reset. I can see that qemu is a machine emulator so machine specific firmware is seperate and non-free binary blob only,

I wonder if qemu could be configured to emulate an X1000 with VOF? One can dream dream. Next decade perhaps.

I don't know if this relates to graphic card issues, perhaps not, but I found qemu is somewhat rigid when it comes to screen modes. At least in qemu 6.1 I had managed to set up a Pegasos config but it just would not let me use the native screen mode of the host. Instead the emulation forced this other resolution upon me which it did not scale well and the result was not usable. The fonts were barely readable. Other modes looked better but I couldn't chose those on boot. I thought qemu was rather useless at emulating machines after that if they weren't headless.

@Hypex
Doing this from firmware should not be necessary as neither Linux nor MorphOS need the firmware to find and drive PCI devices so it's something that's missing from AmigaOS and thus needs to be patched up in the boot loader (the same way as support for 64 bit BARs but that may only be missing in the pegasos2 version because they did not expect PCIe cards used there). The QEMU built in VOF is very minimal and does not support most of OpenFirmware just enough to boot some boot loader to bring up the OS which then should handle stuff itself so it only provides the client interface, the device tree and runtime services (RTAS) but no full scripting or support for operating devices that OF can do.

There's no need to reset devices in the boot loader becuse that's done by QEMU and maybe we only need to care about display and ide to get them mapped. We also don't need to scan the PCI bus as the device tree is provided by VOF and the devices are listed there so the boot loader just needs to check the device tree for pcu devices and map the BARs for those that the OS needs but does not map itself (it can also fix up 64bit BARs at the same time). I have most of what I need for this but this needs to be implemented which takes some time to do.

It's not a question of configuration to emulate something else such as X1000 but heving device models for the componentes that machine has. QEMU can emulate PPC64 and the necessary ISA levels (BookE version) that may be needed but otherwise it may be difficult to get info on what other hardware that machine contains and likely those are not emulated so you'd have to write emulation for those before you can connect them the way they are connected in the machine (which may be handled in an undocumented FPGA so you may have a hard time finding that out). And what would that bring you anyway that you can't achieve with already existing machines? Could it run any more OS or sofrware? I don't think so so just improving existing machine emulation would make more sense than doing yet another emulation.

I don't think QEMU has any limitations on graphics and using other OSes you can use other resolutions and color depths but the AmigaOS sm502 driver seems to be limited partly by graphics.library partly by itself as far as I got from the comments here earlier so that could be solved by either improving ati-vga to by at least minimally usable or write a minimal driver to drive any of the QEMU emualted gfx cards at least as a simple frame buffer and that should solve this problem but this needs somebody who knows AmigaOS and can write a driver for it (or it takes me time to learn it which I don't have when still working on somethnig else).

@balaton

SM502 gfx driver should be fixed/improved soon by @m3x (ACube).
I don't know if this will solve 16bit depth and low memory limits with QEMU, but I really hope sources will be exposed to community.

@MartinW
Quote:

I've ported my original series to current master and uploaded it in the pegasos2 branch here:
https://osdn.net/projects/qmiga/scm/git/qemu/summary
It's the 3 commits (2 reverts + 1 patch with the rest of the changes) on top of current master. If you cloning from that repo make sure to checkout the pegasos2 branch. (OSDN has been very slow for me recently at least the web, do you get the same? The git part still seems to work.) So this was my original approach which was then not accepted but simplified (maybe too much). So I'd like to know if this worked. Can you please test this removeing the current work around patch and using this instead? Try everything that caused a hang so far, including using pci.0 or more devices on pci.1 such as network vfio sound and usb (e.t. -device usb-mouse) together to see if it's stable. Please let me know which version is better, the current workaround or these 3 patches.
Edit: If you have problems getting the patches from the OSDN repo let me know and I can upload the mbox somewhere.

Anybody who has a real pegasos2 and a PCI network card (any PCI network card that has a driver may do) could please help to test if this problem reported here works on real hardware: https://osdn.net/projects/qmiga/ticket/48376
The real pegasos2 has two on board network ports which we don't emulate so maybe that has something to do with it but maybe also nobody tried with a PCI network card as there are already enough ports without that so could be this also happens on real machnine.

@balaton

I will give that a try later this evening.

Right now, I'm trying to get an R 270X card to work and I'm not sure how to handle one of the values:



That first xp3 value in "reg" enters above the first 32bit number. Consequently the firmware has not allocated a bar for it. I can make something up and map, say 0xF0000000 for len 0x80000000 but the video driver doesn't see it, it reports



Although with the 5450 I did not need to, this makes me think that I need to "commit" this information in some way as "show-pci-full" does not reflect the updated values.

@derfs - how did you get your R290 working? Did it have 2GB of video Ram? I would be interested in the values you ended up entering.

@geennaam
Quote:

As for what the quirks do you'd need to check source and maybe some VGA docs but if you look at info metree outputs (like those posted by @derfs above) you can see that these overlap some of the io ports and the register BAR to fix up some issues. I did not look closer but comments suggests there are some ways in ATI cards to access io regs in memory BAR and that is not handled by vfio apparently with some help from QEMU but I'm not sure if it's because these are mapped at different address on the host or something else.

@MartinW
I have no better idea than to check info mtree and info qtree or info pci in QEMU monitor and try to map the BAR in the appropriate pci1-mem or pci0-mem window. The machine and OS would only see the part of VRAM through the window so you could try to fit the most of it and the regs BAR in the window which is where using pci.8 may help becuase then you don't need to care about other PCI devices only the memory BARs of the gfx card. Info mtree shows what's mapped where and info pci shows what the BAR registers are set to. If they are ffffffff then it's not mapped and you had to write something there to map them. There's some way to do this from forth maybe using map-in but I don't know how that works so you have to search for docs.

@flash
Quote:Only if ACube would create a special QEmu SM502 driver, which can't work on real SM502 hardware any more.

@MartinW
Quote:???
0xF0000000ULL + 0x80000000ULL = 0x00000001 70000000 > 32 bit = can't work on an OS only supporting 32 bit PCI address space.