What the fastest possible x64 emulation way of OS4 today ?

@Maijestro

Thank you.

It's not massively high-end hardware, but it's no slug either. I built it in June 2020. It has an AMD Ryzen7 3700X cpu 3.6Ghz, 8/16 cores, Boost to 4.4Ghz. I think the host OS is just running off an old 256GB sata ssd I had lying around because the main use of the machine is gaming so the main OS is on some super-fast NVMe drive. Host has 32GB of DDR4 3200 memory.

Main GPU is an RX6700, although that is completely invisible to OS4 and that's just seeing an old HD5450 I scored off eBay.

If qemu is only using a single core for the emulation then really, I'd consider the host to be mediocre in terms of modern PCs. For the record, none of the fans in the case ramp up when running the emulation so it is to all intents, silent.

@derfs

Yes, and not only do I think that's worth trying, but I'd like you to give it a go as it is in between the 5450 and my RX580 so a good next step. Your figures look almost identical to mine so I should be able to send you something this evening. It won't be until 8 or 9 BST though.

[edit] Do you have a ROM entry listed? I don't need to know what's in it, but it does need to be there, it seems.

@MartinW

good point!

@derfs
Hang on, that's just changed - there's a new entry there now! A 32bit memory region. Was the first one with romfile="" and the second one without? Or did something else change?

@MartinW

thats correct - 1st with romfile="", 2nd without.

@derfs

Ohhh. Thanks. That's interesting and gives me something to go back and look at on mine as I didn't check the values with / without rom file. OR, mine didn't add an extra region. I'm not sure which now. I keep calling them regions. They might be BARs. Frankly, at that point, to me, they're just numbers

@MartinW
Quote:

I think for now it would be enough to just document what is needed and maybe an example script and it's OK if people would have to make their own scripts now. On the longer term we could do this in C instead of Forth either in my boot loader or in QEMU itself after we got rid of pegasos2.rom so unless this would be something for real pegasos2 owners a generic Forth script to patch this may not be needed. Those few people who have both a pegasos2 and a PCIe bridbe can probably write their own script. Although generating the script externally based on info from the machine might also be an option so it's up to you what you want to spend your time with. It's doable in forth and probebly not more complex than finding out how do loop works and then deciode=phys and flip the bit with AND'ing the right number with a bit mask to change the mem space as but this may take a few days to write in Forth and won't be needed later for Virtual OpenFirmware in QEMU.

@MartinW
If there's no rom contents then it probably does not matter if there's a ROM area listed or not as it will also need the rom data not only the BAR so does not matter if romfile="" only disables loading the ROM or also the ROM area. If you look at the numbers in the .properties output the 3rd one is the BAR offset, the ROM BAR is 0x30 while BAR0 starts from 0x10 and each reg is 4 bytes so BAR1 is 0x14. With 64 bit BARs using 2 32BARs so if you have 64 bit BAR0 then you can't have BAR1 only BAR2 at 0x18.

Edit: That's why these newer cards moved the IO regs BAR from BAR1 to BAR4 which is causing problems with the x-vga=on option so this is what needs to be fixed for older Radeons that @geennaam tried with the 9250 as that driver may depend more on the card ROM than the newer ones. I'm not sure when the AtomBIOS that the drivers can parse was introduced, it's mentioned for HD2000 here: https://en.wikipedia.org/wiki/Radeon_HD_2000_series so cards before that may need the ROM to run but later probably just need the BARs to be visible for AmigaOS and apparently AmigaOS is not prepared to handle 64 bit BARs but fi they are shown as 32 bit and fit in 32 bit space then it should be OK.

@balaton

I mean, in pseudo-code terms, it goes something like this:


What I really meant by how far do I want to go, is do I pursue passing through more devices, or do I pursue real hardware. And independently of that, do I pursue furthering the Mac side of things.

Right now, I'm finding this extremely interesting so it's probably a mix of all three! If I pursue real hardware then that will have to be at the expense of this hardware as I simply don't have the room for a big box Amiga and a big box gaming PC.

@MartinW
Quote:
Just for correctness BAR stands for Base Address Register so it's really the config register that configures these regions but since they are closely related often the regions are just called BARs too. These can be either in memory space or io space but on PPC they'll all end up mapped somewhere in memory because PPC does not have io like x86 in/out ops so these will just be mapped either in memory window or io window of the PCI bus where the card is connected. (Or even more correctly they are mapped to the memory or io space of PCI and the windows in system memory provide a view to part of those PCI spaces.) Those windows are configured in the PCI bridge and this is what's not emulated correctly for the sam460ex PCIe controller currently and that's why the card connected to there does not show up.

I'll eventually fix PCIe emulation for sam460ex but after this testing with pegasos2 I wonder if the same could work with sam460ex? But I don't know how u-boot handles these BARs and if there's a way to patch that from u-boot prompt. It may be in the device tree passed from u-boots so not sure that can be patched the same way as it's possible with OpenFirmware. As u-boot for sam460ex is open source it can be patched there but I don't think I should break the distributed ROM image too much for this. But if somebody really wants to experiment it should be possible to build the ROM for sam460ex in QEMU sources after git submodule init roms/u-boot-sam460ex; cd roms; make u-boot.sam460 but it needs a ppc cross compiler.

Just to test this is the case, what shows with an HD card conneected to PCI bus with QEMU sam460ex? Does it have missing BARs like with pegasos2 so it may be the same 64 bit BAR issue? If enabling debug logs does the same Cannot handle SS=3 message show up? The proper fix for sam460ex would be to emulate the PCIe controller correctly which is a bit difficult without documentation but not impossible and eventually will do so maybe not worth patching the sam460ex firmware for this.

@balaton

Just so we're on the same page, and it might amount to the same thing anyway, but on Sam460 the VGA is recognised and the whole boot process plays out on the screen connected to passthrough GPU but once the kickstart roms have been loaded and OS4 starts to boot we just get DMA errors reported in the qemu window and the screen stays on the kickstart load screen. I'm not saying qemu is throwing the errors, it may be the sam460, but something is not happy about DMA errors.

Hmm. I tested that before I realised DVI was the output that was being activated for OS4. Maybe i'll try that again now that I have the DVI port connected! But all the same, there are still the errors so it's probably still a non-worker.

I believe geennaam reported this some way back so this isn't new info at all. I'm just not sure if it got missed as there's a lot in this thread now.

@MartinW
Quote:

Don't bother then, it will not work if warp3dnova not works

Quote:

I am on real pegasos2, so just have radeon9250 only for now, and no other one (waiting bridge to arrive).

But just in case that what i have on real peg2 when just do "ls /pci":

@MartinW
About sam460ex and DMA errors, I assume you tested that with passed through card connected as PCI as PCIe does not work at all at the moment because of missing memory windows as wrote above. I'm aware of that. Then that probably means 64 bit BARs is not a problem on sam460ex maybe because it has to handle it for PCIe cards too. So that also means the AmigaOS kernel can handle 64bit bars just not in the version for pegasos2. So code is there and maybe could be fixed for pegasos2 too within AmigaOS in an update if they wanted to do that but we can patch it at the firmware before AmigaOS loads so we can work around that.
I'm not sure what the DMA errors mean although I've seen these logs before we did not know at that time where this problem could come from. Now that same cards works with pegasos2 it probably is related to sam460ex emulation then. What's the command -device option used to passed through the card and what shows in QEMU info mtree and info pci after booting?

@balaton

I'll check tonight. I would need to double-check all of the sam460 config as really my effort has been concentrated on pegasos2.

@kas1e
radeon9250 does not have 64 bit BARs so all this is not needed for that. If you connect an HD card with a PCI to PCIe bridge to the PCI bus that will show up in /pci but your AGP card is on the other PCI bus. Try ls / and check the other bus which may be /pci@80000000 or something where display should show up.

@MartinW
Also I think later @geennaam said the sam460ex worked with an HD card but was too unstable but maybe I've lost some of the info. I don't know what unstable means though and now I wonder if it could be the same network issues that you saw which would mean it may be related to rtl8139 emulation or the AmigaOS driver for it. We'd need more info about these to understand it better.
The primary goal for now is probably the pegasos2 because sam460ex is slower due to different CPU in that so those who can should use pegasos2 now but for completeness and to have an alternative I'd like to also improve sam460ex eventually if time allows.

@balaton
Quote:I don't know what QEmu supports, but for example for rtl8029 and ne2k there are AmigaOS drivers as well.
If it's supported at all the QEmu emulation of one of those may have less bugs.
Of course those are much slower, but better stable slow network speed than random fast crashes

@balaton

About sam460.
No, both HD and RX show the Amigaos4.1 logo and then the driver fails loading. Most likely to do with the vfio DMA init errors.

Radeon 9250 causes a kernel dump.

A quick and dirty hack to comment out the bar4 quirks makes the Radeon 9250 show the uboot screen and amigaos4.1 boot logo but will robench is equally corrupted as on the pegasos2.

Probably have to change the bar instead of commenting out the quirk.

Interestingly, I don't get the 4.1 logo / loading screen. I'll have another look later but it's not really any kind of priority for me now the P2 passthrough works ok.

@joerg

As far as I know ne2k (rtl8029) corresponds under Qemu this driver can be included via "-device ne2k_pci" and is also recognized under AmigaOs4.1 as rtl8029 driver.

However, it is not possible to set up an internet connection via DHCP using Roadshow. There is no other solution like with the rtl8139 driver at the moment.