Prometheus PCI bridge endian problem

[Hedeon]

Hi,

I am using the Prometheus PCI bridge and Prmscan returns as Class code for the Voodoo 0x1 and for revision 0x3 while on my very real Amiga with Voodoo3 it is the other way around (which it should be).

Seeing they are in the same 32 bit number, this is an endian issue?

EDIT for some more background:

I am talking about the PCI configuration space here. Gfx cards should identify with class code 0x3. The prometheus.library checks for this and sorts the BARs for gfx cards on a higher priority. That it currently works for version 3.x of the prometheus.library is probably by accident as somehow revision is read into Class code and vice versa (so it identifies as a mass storage device). It stopped working for prometheus.library 4.x where more checks are made for class code 0x3.

Prmscan lists the PCI devices per slot and gives additional info (Vendor/Device ID, class code etc).

[Toni Wilen]

[moved from beta thread]

Yeah, most likely endian problem. Some PCI bridges have internal endian switch, some don't. Some depend on size of access.

[Hedeon]

But is this a WinUAE issue? It works correctly on real hardware.

[Toni Wilen]

Yes

Quick test, too lazy to try newer drivers: https://www.winuae.net/files/b/winuae.7z

It seems BYTE size config accesses are not endian swapped (address XOR 3) but they are if G-REX.

[Hedeon]

Looks like the endian problem is fixed. PrmScan now gives the correct data and the debug version of prometheus.library 3.1 now indicates it has found a graphics card.

However, my updated lib is still not working correctly. I think the bug is in my library now, so let me check that

Thanks!

EDIT:

Fixed my own bug and now everything is working as intended on first sight. Thanks again!