What the fastest possible x64 emulation way of OS4 today ?

@MartinW
Quote:

Sorry, I do not know how to add this patch to qemu to test my setup. If you can give a quick rundown of 'how to' then i can also check things.

First of all you need to be running Qemu built from source. If you're not already then there are some instructions here:
https://wiki.qemu.org/Hosts/Linux

Once it's built from source, tested and running as-is then all you really need to do is download the "mbox" file from the link posted in #787, check out a new git branch (if you like, I guess it only matters if you intend to contribute a pull request later) and then run the command:


This will patch the qemu sources and you then just rebuild again - a simple "make -j 8" was sufficient for me, I did not need to rebuild the whole tree.

When you build qemu from source, don't build it all unless you really want to, it's kind of huge, just build PPC with "configure --target-list=ppc-softmmu"

@LiveForIt
Quote:Possible, but the most common reason is that an application sends a wrong data pointer, for example something past the allocated memory buffer, to the file system.
It's a bug in the application, but the filesystem code will crash accessing it with a DSI.

@MartinW

That crash log doesn't make sense. Something is corrupted. Can't tell if it's missing hardware causing code confusion or bug in core ppc emulation. Also, could be crash reporter bug, as on X1000 some crashes don't match up with the register values it gives some times in DAR.

So the code is in DOS library relating to some clock process. I can tell it's converting a BCPL address to real address. Roughly translated:


It destroys r3 by moving r4 into it to test but r3 should have been 0x2963703B before that. And then this:


It falls through and executes the next instruction. But, CR0 (leftmost nibble of CR) should be 2 for zero, but has 8 for negative. Because r4 is zero. So by all accounts it should have branched off to 0x0194849C in LR. But instead continues and crashes by loading from an invalid address of 0xA58DC0E0.

Also:


That will likely be ignored as it should be "munge".

@MartinWQuote:

Thanks again for all the testing and providing information that can be used to improve Qemu.

Perhaps it would be advisable to first set up a complete AmigaOs4.1 system including update 1 and 2 to bring the system up to date and without GPU passthrough.

As file system you should not choose FFS for the installation of AmigaOs4.1 it makes things much slower. Choose SmartFileSystem instead, only the boot partition needs the filesystem FFS because the kernel is loaded from here.

If you then have a system that is up to date you could experiment further with GPU passthrough, so we can also exclude that broken things under AmigaOs4.1 have already been fixed in update 1 and 2. This guide might also be helpful for the installation.

http://www.amedia-computer.com/amiga/ ... _4.1_Pegasos2_English.pdf

Note: SmartFileSystem was ported by @joerg many years ago for AmigaOs4.1 it should not be part of the AmigaOs4.1 Pegasos installation CD and was added illegally without his knowledge. But as I read that you also bought Enhancer software of the last version it should be ok, because SmartFileSystem is included in this software package and you already have a legitimate license.

Edit:I just searched my YouTube collection and found a little tutorial on how to set up AmigaOs4.1 with FFS as boot partition and SmartFileSystem. Maybe it could be useful for you.

@MartinW

Patch added, qemu compiled, and I have working sound and network.

Graphics card (R9 270) monitor settings in aos4.1 changed to 'interrupt=no' otherwise still get crashes.

I have not had any random crashes yet, but i am using a sfs2 partition as sys:

Cow3d-os4 and cow3d-nova work, as does shaderjoy.

@Maijestro
Thanks - it would appear I'm already a subscriber!

@Hypex
Err, oops! Well spotted. That might mean all the times I've been saying "no useful debug output" was my fault and there could have been some. Damn. Well, I intend to carry on using this setup for now so if I find anything more of use then I can report back. Of particular note at the moment is that with this patched version of Qemu I tried to move the passthrough GPU to the bus pci.0 and I still could not get through workbench startup. I don't really know what's going on there but I didn't look in any detail at the patch.

@derfs
Quote:
How it speed wise ? How it if you check let's say 3 random shaders in shaderjoy on both real os4 hardware, and on qemu with passthrough r9270 , will it be the same, fast, or slower ? Pretty interesting to find out if we have some issues with speed in some places due to drivers, or hardware.

@derfs

Interesting that you still need to add interrupts = No in your monitor settings, however, probably worth noting what I said about bus pci.0 it may be that moving back to bus 1 would resolve that?

I moved my Data partition to SFS/02 last night and did not get any further random crashes, but it was getting late so I didn't do much.

@MartinW

Quote:

There still should have been some useful output. You might need to increase debuglevel to 5. 10 will be half way to a nightmare. I enabled munge on my X1000. I'm not sure what more it does. The best guide online I can find is Roman's debug guide. But that doesn't say what it actually does. I'm rather picky and like to know what every particular item does when I follow instructions. It's never in one place. Obviously this will need a debug kernel so would require a stable OS4 boot so the Kicklayout can edited to set kernel to kernel.debug. Or munge will still munge nothing.

Unlike the A1/XE the Pegasos2 is more standardised. Being supported in official PPC Linux releases with CHRP compatibility. So I don't know why it's being so difficult to engineer an emulation profile. I wonder if emulating an A1 would be easier. Or perhaps an X1000 since it should have less quirks than an A1 or Sam but a 64-bit CPU does present more demands for emulation.

@Hypex
Quote:https://wiki.amigaos.net/wiki/Debug_Kernel

@kas1e

qemu (R9 270)


X5000/20 (R9 270x)


Its not the same gfx cards, but they are close.

@derfs
Interesting … Looks more or less the same, but Video bug Read and Write 4 times slower on QEMU, probably due to disabled interrupts in tool types ? It shouldn't be like this IMHO, as it pass through, should be kind of fast … But if interrupts disabled, that can explain it, maybe..

@kas1eQuote:

It shows that 3d acceleration works and that real graphics cards can be used with Qemu.

I never thought that Qemu Pegasos 2 is able to do this. Apparently I should rethink my setup and invest in Pc hardware again, since this won't be possible with Mac M1.

Maybe we can increase the performance a bit, I think it should be possible. I am impressed.

So I spent a few hours this evening looking at my RX580. I didn't realise until afterwards that it was already reported way, way back in the thread that RX cards won't initialise because the driver is stuck in a loop with this message in the debug log:



Since the memory bars are defined as 64bit prefetchable I did try to remove the prefetch bit but it didn't help. If I'm honest, I don't really know what that message means. I also don't know if defining a region in the firmware that hasn't actually been probed by the firmware would even work? Rather than try to map my entire 8GB of video memory which clearly isn't going to work, I tried to just map 2GB at an address that would have fallen within the original 8GB but obviously sticking to the first 4GB of memory. It looked like AOS assigned the memory, but the driver wasn't happy about something anyway and stayed in that loop.

I probably won't bother again with the RX580 unless there's something specific anyone can tell me to try.

Would of course be nice to have a 3D card to try but half the cheap R270 cards on eBay seem to be faulty!

@Hypex

Quote:

I don't really know or want to know PPC asm (it's sooo ugly), but after a bit of google'ing, maybe the "beqlr" tests r9, because the "." suffix causes the rlwinm to update condition registers while no such suffix used for "mr" instruction, so condition registers does not change after that.

Quote:

Theoretically you can't be sure that the execution sequence was as shown in the disassembly above (rlnwim -> mr -> beqlr -> lwz -> crash). Could also be (even if unlikely) a jump from somewhere else to 01947B8C (the lwz instruction).

I have a question about the graphics card.
Though still experimental with qemu.

But with my current setup
this is the motherboard:
Asus Tuf Gaming Plus B550:

https://www.asus.com/motherboards-comp ... ing/tuf-gaming-b550-plus/

can I take an ati 9.2.xx for example or is it possible to have some more information for example an "adapter"
I'm not very knowledgeable on the subject.

Thank you.

At the moment, there are only 3 GPU's that have been proven to work:

1. Voodoo of some description, probably page 20 or so of this thread if you want to check, but unless you have one, they are collectors items so you will not want to buy one. They are also expensive.

2. Radeon 5450. This is the one I personally use. It works fully but has no accelerated 3D. That is just the way this card is and will not change.

3. Radeon R9 270. This has been tested by Derfs. It supports 3D but has only been proven to work on pci.0 bus by disabling the interrupts for the card so the performance is not as good as it could be. I have not been able to get my card to work on the emulated AGP bus (pci.0) so I would like to see this card tested on pci.1 with interrupts enabled to see if that works.

For now, that's it. I also have an RX580 but there are a number of problems with that card. Firstly it's memory does not fit into 32bit address space so you have to fudge it in open firmware which may or may not be leading to the fact the driver will not initialise, it gets in an infinite loop. Unclear at this point if that could be sovled or not. I can get an RX550 to test but I expect it to be the same as the RX580.

Also worth noting that if you don't already own it, you will need to buy the Enhancer 2.2 pack for the video drivers.

As for the motherboard, the detail is all in the BIOS. Your CPU will probably support VT-d (although you don't say which CPU you have), but it all depends on the BIOS and the IOMMU groupings. You have to pass through the entire group that your GPU is in and if that means that other stuff is in that group, then you may well run into trouble as to date we have only tried to pass through a GPU (i believe this is correct).

You will also manually need to calculate the correct addresses for your setup and generate a script to execute at every startup. It is possible to ensure these addresses do not change, but at the moment it is not possible to automate the startup process.

Hopefully thats a reasonable summary? Right now, none of this is at all "user-friendly", it's all very much at the "does it work at all" stage. Where we go from here is TBD. Balaton is working on some improvements to Qemu that will massively help but there are no indications how long that might take, nor should we (IMO) put any expectations on him! (I assume Balaton is a he - apologies if not, I don't know)

[EDIT] Personally, I'd still like to see some VIRTIO drivers for OS4 but certainly for GPU that's a very big ask and I'd imagine if it happened at all, it would be a long way off. I have said that I'd be happy to look at a network driver but I'm still in the information gathering stage. And I've never coded anything like that before so it's probably not realistic. You don't know until you try though.

@MartinW

I couldn't figure out if the answer was for me
I guess so.

I have the ryzen 5800x so it doesn't have the integrated graphics card like the 5600x for example.

In the bios in addition to AMD V-T support
i also have this option i guess is for graphics card.
pci sub-system settings
if system has sr-iov capable pcie devices this option enable or disable single root io virtualization support.

But I wanted to know if you need a specific adapter etc.
To be able to insert one of the graphics cards you mentioned into the second slot.

Thank you.

@joerg

Thanks. Yes I actually found that in the meantime. But I needed to search the wiki as nothing was turning up on Google.