sakura-it/prometheus

prometheus's Issues

GetCompatibleFormats() not implemented correctly.

Just browsing the code... the "GetCOmpatibleFormat()" function is not implemented in a correct way and may cause disruptions or color artefacts if the chip driver or card driver supports aperture switches.

First of all, the mask supplied here is (ULONG)~PLANAR, which is just binary %1111...1110, thus the remaining terms that are or'd are just superfluous. What that term means, however, is that if the chip or card supports both big and little endian access, then both can be accessed at the same time without an aperature switch for all modes (16 and 32 bit modes) in the same memory window. This is typically not true, and thus may result in false colors in some modes, in particular if a non-native endianness is used.

Some background information:

The video RAM typically sits behind a "bit-flip" driver that can, upon request, perform a big to little-endian switch. How that switch operates or is controlled depends on the chip and card design, of course, but there are two typical designs:

Design a) is that the switch is dynamically controlled through an I/O port. In that case, big and little endian modes cannot be on the card in the same time as their interpretation changes dynamically with how the switch is operated. In such case, the GetCompatibleFormats() call should only the bitmask of the modes that share the same aperture switch control as the mode passed in.

This design applies, for example, for the Cybervion3D in Zorro-II mode.

Design b) makes all modes (or a subset of the modes) available through multiple windows in the 68K address space, and depending into which window you write, an endian swap happens or not. In such a case, all modes are compatible, but thue card interface then also needs to supply a GetMemory() function that, upon the RGB format passed in, adjusts the memory pointer to point to the correct aperture window into which a write has to go.

This design applies for the CyberPPC and Cybervision3D in Zorro-III mode.

Which of the two designs applies to the graphics cards behind a Prometheus switch I can only guess, that is up to the card author (i.e. "you") to know. (-:

In either case, the interface is incomplete by missing a function or not providing a consistent mask of compatible modes. Please check (carefully!) the P96 API specification at icomp.

As always, I am happy to help through mail if you have further questions.

Greetings,
Thomas

Specific data send to Bigfoot Killer 2100 memory gets dropped by MPC8314E's CSB PCIe Bridge

Specific data send by the 68K to Prometheus over the PCIe bridge to the PCIe Bigfoot card gets dropped.

This is not address specific but data specific and 100% reproducable.

The following error bit is flagged: PEX_CSB_IBSTAT_BRGER = 1

For byte transfers, the following data is lost and the MPC8314E indicates an error on CSB inbound transfer (tested from $00-$C0, i guess I should test till $FF):

$31, $32, $34, $37, $38, $3B, $3D, $3E

Word transfers and longword transfers are harder to predict which ones get dropped, but at least a very vital longword gets dropped which is used in the reset procedure:

$52535445

Old data remains in the memory location the write was supposed to go. It does not lock the card and data can be continued to be send.

Another example; At a location the inital data is 0,0,0,0 in longwords. Writing the following longwords:

$806001E4, $38630001, $906001E4, $4BFFFFF4

Gives the following result:
$806001E4, $00000000, $906001E4, $4BFFFFF4

With further tests just writing $38630001 anywhere in the address range, the results are always that this longword gets dropped with a CSB inbound error.