Once again I ask to opensource some existing AmigaOS software, just like gfx drivers, bios roms and others important keys of Amiga OS system to help community improve/expand existing compatibility and let dream continue.

There exist PCIe to PCI bridges to connect PCI cards to modern systems. I've heard fhat those using a Pericom chip might be the best but this is not confirmed, just rumors. Also I'm not sure if the guest really has to support PCIe to pass through a card but it seems likely that having a PCIe card appear as a PCI card in the guest might cause problems and the driver could get confused so that's less likely to work.

The issue with the BIOS might not be fatal though as long as it works enough for the driver to find and init the card so I would not give up on that yet.

As detailed on the qmiga development page on ati-vga the emulated Radeon 7000 is missing emulation of the micro-engine (aka CCE or PM4) so while the driver detects it and starts to talk to it it stops working when the driver enables the command processor. This could be emulated to make it work but somebody would need to port code for that from Xenia emulator as I haven't got to that yet because it's quire some work and so far I had enough to do on pegasos2 emulation and improving what's there. This is explained in https://osdn.net/projects/qmiga/ticket/40018

If we are only concerned about one guest OS like AmigaOS then wrting a guest driver for QEMU's virtio devices may be easier and get better results.

I've ported ATOMBIOS into Sam460 U-boot version, and ASICInit indeed seems to initialize correctly the card but ATM I cannot get any videomode working. Do I need to call the classic x86 BIOS emulation before calling ASICInit, or something else need to be done to have a basic 640x480 screen mode ?

I'm not sure if I understood correctly, but if we had a radeon rom that would initialize the atiradeon.chip could you use it with Qemu as an emulated graphics card?

All of the detection etc is part of the ipp everywhere spec.

The bigger issue is compatibility with the printer.device for legacy software. Finalwriter uses its own print system so we’re able to choose how we communicate.

You don’t need all of cups just enough to support ipp correctly. ipp everywhere requires all printers to support pwg raster format so therefore implementing ipp proper with pwg raster output you now support all of the modern “driverless” printers.

https://ftp.pwg.org/pub/pwg/candidates ... er10-20120420-5102.4.docx

- Fix: it is crucial for good framerates to reduce Nova submissions to a minimum. However, certain operations require a submission. ogles2.lib's internals try to get a good balance here. However, the last time I optimized things here I introduced a bug where I made such a necessary submission due to certain state changes but falsely marked the used-objects list as empty - which in turn caused another required follow-up submission not to be executed. The results could be anything from textures at wrong places or whatever because e.g. Nova would then use a newly bound texture for a PREVIOUSLY issued draw-call. Yes, be glad that you don't have to use Nova directly...

Other than still selling Turboprint for Amiga, have they ever mentioned any type of support for Amiga? Just curious.

I did write an ipp.device some time back. That should work with an IPP-supporting printer and the PostScript driver, although it was based on old (even at the time) CUPS sources so might not be very compatible.

I suggested a port of CUPS already two years ago, when I got my X5000.
The question is: is there any developer who would have a look into it (and who could be motivated maybe by some donations...?).

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.

I am somewhat pleasantly surprised that these results are so different.....es shows once again how strong this ARM Cpu is, but also shows its weaknesses in some areas.

Not possible since 32 bit CPUs don't support 64 bit integer loads/stores, 64 bit accesses are only supported for double (and 128 bit accesses for vector on some CPUs).
64 bit C integer loads/stores have to be executed as two independent 32 bit assembler loads/stores, and you have the results for 32 bit integer accesses in the READ32/WRITE32 results already.

Question: does QEmu exists ont Power architecture?

Would QEmu on a Talos II system ( https://www.raptorcs.com/ ), for example, be really fast since PowerPC architecture derivates from Power arch ?