@Maijestro

If it's indeed all related to smartfirmware then we are out of luck. The OS4 drivers rely on the firmware to init the card.

I've just read on an old amigans thread that a PCI Radeon HD card will also not work on a real pegasos2. Because it's behind a PCI to pcie bridge. But now we know that it wouldn't have worked if this problem was solved.

@joerg

Quote:

Ah, forgot about that one. So the missing extended opcode is probably an issue with the x86 emulator in the pegasos2.of. The interrupt issue can also be related to the pegasos machine emulation. Either way, this looks like a dead end for now.

Those old Radeon 9250 should be supported by both the pegasos2 and Amigaos4. I'll have to get me a PCIe to pci adapter first before I can test this. But I'll probably run into the issue that the pci bridge will be in the same iommu group.

Quote: Turns out that this vbios is necessary for nVidia cards who will only present their bios once. Without the vbios, a reset within the emulator will not work properly.

Tried the HD4850 again with passing through both devices in the IOMMU group and now the error is similar to the RX560.

No unimplemented extended opcode this time but only the interrupt issue.



Maybe zbalaton knows what is going on here.

@derfs

Error with RX560 is a bit different:

@derfs

Unfortunately I do not know who throws this error and what it means.

CS:IP = 0000C000:00000F5A means code_section:instruction_pointer

Googling for "READ ACCESS FROM UNEMULATED IOPORT" doesn't result in any hits.
But I can think of different meanings:
- QEMU-system-ppc is not VFIO aware?
- Pegasos target missing VFIO functionality?
- QEMU tries to connect VFIO device to a non-existant/emulated PCI root complex inside the emulated pegasos target?
- Pegasos target can only handle VFIO passthrough from PCI ports?

Maybe we can cross-check the issue with the QEMU SAM460 target? This system is PCI-e aware. Unfortunately I do not own OS4 for a SAM460.

@derfs

I doubt that this is the issue. This looks more bios/UEFI vs vbios issue. But I'll try a RX560 instead tonight.

Edit: I do have to pass through the Radeon audio device as well (02:00.1). So I will try this first.

@derfs

VFIO with HD 4850 doesn't work:

As you can see, the GFX card and it's audio are attached to VFIO-PCI


When you passthrough a GFX for windows in QEMU, you must also pass the gfx card bios rom for initialisation. Not sure if this is also necesary for OS4 emulation.

@Maijestro

You are not annoying me. On the contrary, I am curious where this might lead to.

It's just this thread gives the impression that you can emulate an Amigaos4 system on modern PC hardware. And in my opinion, this is not the case.
So it's just a fair warning to anyone with an Intel Core i3, i5 and I7 from the 11th generation and older. You'll get a system that works but it will feel slower than a sam440. The 12th generation made a bigger step in performance and is on par with the Ryzen 5000. So if you have one of those then it might work better for you.

The shell is a command line interface and works just like the window cmd or powershell or whatever you use on macos.
Open it by clicking on the shell icon in the docky bar. Change directory to where you have stored CPUbench. Then type CPUbench.script and press enter. Once finished, you can either type the command again or press "arrow up" and run the script again. Like Linux, use can use "tab" to complete a command. Unlike Linux, you do not need to use "./" or sudo.

@Maijestro

The fact is that the bulk of PC users do not have the top of the line processors. The i5-10400 was only released 3 years ago and I own one since two years. Its successor (11th generation) is only marginally faster and was only launched two years ago. My work laptop is a 9th generation i7 which is still more than capable of running all the (CAD) software that I have to use for my profession. I think the life cycle of a laptop in my company is 4 or 5 years. PCs aren't updated as frequent anymore in households because a phone and tablet fulfill their role nowadays.
Another fact is that MAC computers are niche and your M1 MAX even more so. Buying a MAC with M1 MAX to run an amiga emulator isn't a viable approach. But if you happen to own one than you're just lucky in this specific case. Given the long PowerPC history and recent x86 history of apple, I wouldn't be surprised that their ARM cpu's contain some features to assist emulation.
I bet that a POWER9/10 will be able to emulate a PegasosII even better. Because a lot of PowerPC instructions have a direct counterpart on POWER and therefore don't need nearly as much instruction for emulation as on other ISAs. And it's big endian too. But buying a POWER9/10 to have a good emulation experience doesn't make sense either. Unless you happen to own one just like you and your M1 MAX.
So I stand by my conclusion that emulation is too slow for the average PC owner unless you happen to own a very powerful one. If I'd known up front that the experience is acceptable on only the fastest hardware then I would not have bought AmigaOS4 for PegaososII.

About the choice for PegasosII emulation:
The PegasosII was originally developed for MorphOS. Not for AmigaOS. So not many amigaOS4 users will own a PegasosII.
It is also openfirmware based which is also different from recent NG amigas (mostly u-boot based).
The hardware is also very limited compared to recent NG Amigas.
In other words, you're trying to emulate a niche within a niche.
This is the reason why we cannot really help you debug a pegasosII emulator.
Radeon HD/RX gfx cards need to be initialized by the firmware. I doubt that the pegasosII firmware is capable of initialising a RadeonHD or RX. Even the more recent SAM440 can't initialize a RX (yet). So an iommu solution for a pegasosII sounds very challenging to me.

Reproducing the issue on my system is easy: Run CPUbench.scipt in a shell. Once it has completed run it again in the same shell. The second or third time, it will hang at the drystones benchmark. The system will not freeze. It just will not finish the test anymore. But this can be related to the windows build and might not happen on your MAC.

@joerg

That's why it's not high on my priorities list. Actually, nothing is. I have an Amiga summer dip with temperatures approaching 30 degC atm.

@Maijestro

I consider my PC with it's 4GHz 10th generation Core-i5 as averaged spec'ed. But apparently this is not nearly sufficient for QEMU.
The Ryzen 5600 of derfs is ~30% faster in PC benchmarks. I see the same difference with the CPUBench test script. So it doesn't look like there's a specific benefit for Ryzens. But it could be that the QEMU TCG and JIT will benefit from the much larger caches in Ryzens in certain scenario's. I have only tested the basic workbench experience.
Yet, I doubt that this 30% processing power difference would make that much of a difference overall. It's looks like the GFX part is the issue in my case.

And this is comparing with my sam440/Radeon9200. The X5000/RX580 is completely in a different league. Even while running with 3440x1440 resolution.

But I also observe stability issues. Like Walkero already mentioned do I also observe ethernet issues. Communication simply stops. Especially when I transfer megabytes of data with for example youtube. But also running the CPUbench.script multiple times will result in an endless execution of the Drystone test. Doesn't matter if the emulated CPU is G3, 7447 or 7457.

For me, QEMU is nice if you want to check out what OS4 is about. For now, it's more like a CyberstormPPC experience then a SAM460 experience imho. But I will monitor the progress of QEMU and I'm sure that it will get there eventually.

Tested Amigaos4 Pegasos II on Qemu 8.0.2 with a Core i5 10400F and Windows 10. Raw cpu seems to have potential. Cpu intensive task like unpacking feel fast enough. File access and copy is also acceptabel (SFS).
The overall experience feels slower then my Sam440 with Radeon 9200.

Would it make sense to install Linux instead? Does it bring any benefits?

@tonyw

Small sized, single command transfers is the Achilles' heel of NVMe. Small sizes are fine as long as you overload the drive with them (the more IOs, the better). Alternatively, large transfers are fine because they are broken down in multiple small transfers (Size depends on NVMe controller) and fed to the submission queue.

Currently, my driver is optimised for large transfers. A future release will include independant submission and retire queues in order to create a true pipelined flow. But this will also require a filesystem which is capable of sending multiple IOs.

@eliyahu

This is it for now. There will be no new public release in the near future.

@eliyahu

It looks like there's some DDR3 memory cache benchmarking going on.

I can assure you that the X5k is SATA2. Hence a 300MByte/s theoretical limit. However the raw read speed is about 250MB/s with my SATA SSD. With larger transfer sizes, the P50x20sata.device starts chopping up the transfer to smaller sized chunk (the driver informs this with debug ouput on terminal). As a result, the read speed drops a little. I will post the benchmarks later today with my scsispeed alternative.

EDIT1:

X5000 Sata:


X5000 NVMe:

@tonyw

Weird. This is what I can find in pci.h inside the latest SDK:


I thought that this was the ground work for MSI support in new kernel versions. But apparently not.

@Rolar

I've seen some reports of drives that fail to work with my driver.

I've tried to search if other platforms have similar issues and it looks like the issue might be related to legacy interrupts (emulated pin interrupts). I've encountered multiple websites which recommend to use MSI/MSI-X interrupts only with NVMe. Windows even offers a tool (LOGO) which checks which type of interrupt work for an attached NVMe drive and which don't.
The publically available OS4 kernels supports legacy interrupts only. But the latest SDK contains traces of MSI support. So if a new kernel will ever be released, this might solve that issue.

The driver on os4depot is really interrupt based. If an interrupt is not received within the timeout window then it will generate an error. In your case, this error likely occurs during initialisation and therefore shows the symptoms as if there was no NVMe drive found at all (bug in cleanup routine).
My current beta driver checks for an active interrupt inside the NVMe drive itself. But since the NVMe completion is much faster then the interrupt response, I might as well simply poll the completion queues. So stay tuned

Edit1: The good news is, it works to ignore interrupt and check the completion queue. The bad news is that it has a negative impact on performance because I need to flush caches during polling.

@sailor

I think the idea of using KVM enabled qemu is to create an Amigaos4 system out of a faster Powerpc platform. For example the G5 or Power9. This way you could leverage the raw cpu power of this faster platform without emulation like on x86 or ARM. But as Joerg mentioned, the Exec releases for each platform (X1000, X5000, sam460..) only contain (cpu) support for that specific target platform. So apparently kernel needs to be G5 or Power9 aware for it to work with KVM. And that is on top of emulating everything else.

@Hans

As far as I understand, the KVM based virtual machine uses the CPU directly. This means that the kernel must be able to handle the specific CPU of the host. And I doubt that ExecSG "speaks" e6500, PPC970 or POWER9 yet.

@Hans

Maybe because he is running at a smaller screen resolution of 1280x720?

A quarter screen will then result in only 640x360.