GetCompatibleFormats() not implemented correctly.

[sakura-it]

GetCompatibleFormats() not implemented correctly.

[DvdBoon]

@thorfdbg Sorry for the late reply and thanks for looking at this. This part of the code I have no clue about. I took the source over from Tobias with the intention to add the PPC cards as their BARs behave differently to normal PCI cards.

Now, he had a HD crash so the sources were (much) older than the binary of library version 3.1 as his got lost, so I tried to reverse engineer it back into the source and called it 4.0. I haven't look at the .card side of things as I haven't seen color issues present itself (yet)

So that being said, I love to fix it. But I don't own P96 myself and so I don't have the API (it is part of the download, right?).

[mheyer32]

Even though this function is present in the Prometheus' card driver code, it is as far as I can see not actually being used. It seems, the card driver relies on the chip driver to implement it and link their own function into the boardinfo structure. At least that's how I did it for the Trio64 driver.
WRT aperture switch: I'm surprised you mention an aperture switch on the Cybervision64 which register would do such switch? (disregarding planar mode) . The Trio32/64 has AFAIK no such switch and exposes its memory (in chunky mode) as linear piece of LE memory.

The Trio64V+ and later models, however, have two apertures and expose the same memory through both windows at the same time. In this case CalculateMemory() can report either window to access the framebuffer depending on the requested format, while GetCompatibleFormats would claim that all formats can live on the board at the same time.

[thorfdbg]

To provide a bit more technical background to what Mathias said: The "GetCompatibleFormats()" function provides a bitmask which RGB formats can co-exist with the given format in the memory of the graphics card without changing the (CPU-visible) data in the video RAM. This sounds a bit abstract, so maybe some examples: Consider a card where the data path from the 68K to the video RAM goes through a (programmable) endian switch: BGRA is "little endian" and requires one configuration of the endian switch, ARGB is "big endian" and requires another configuration. Now, if the code switches from big to little endian, the data in the video RAM "seems to change" as seen from the CPU, and thus, the two modes are not compatible. Consider now the same card, but the endian configuration is not due to a flag, but rather due to the address at which the video RAM is accessed. At low addresses, it is little endian, at high addresses it is big endian. As the image data always stays the same when addressed through its window, both modes are now compatible to each other. To avoid unnecessary data migration, P96 furthermore assumes that modes that are "endian-swaps" of each other (e.g. 16bitPC and 16Bit, or ARGB and BGRA) are converted to each other when switching between such incompatible modes. Thus, to render an ARGB bitmap on a BGRA screen, it is sufficient to switch the RGB mode to ARGB, perform the rendering, and it will end up in video RAM as BGRA. As a rule of thumb: *) Planar is never compatible to anything, and nothing is compatible to planar. This is due to the way how planar works on VGA, namely accessing video RAM through the (legacy) graphics controller, which performs another conversion - or put it around, enabling "chunky" usually enables the chain-4 mode, which re-interprets data according to the address, and thus implements another form of aperture. *) If different endiannesses are addressed through windows in the address space of the card, the modes that are accessible simultaneously through two different windows are compatible. If one mode requires to switch one window to another mode, the original mode and the mode switched to are not compatible. *) If different endiannesses are realized through an aperture switch (and not by an address selection) the two modes are not compatible to each other.

The Trio64V+ and later models, however, have two apertures and expose the same memory through both windows at the same time. In this case CalculateMemory() can report either window to access the framebuffer depending on the requested format, while GetCompatibleFormats would claim that all formats can live on the board at the same time.

In that case, see above, the modes that coexist through the windows are compatible, and the modes that require a switch of the mode of one of the windows are not compatible. Example: Consider the first window can be switched between little endian and long-word endian change. Consider the second window is fixed to big-endian word switch. Then: 16bit hicolor (in the second window) is compatible with all other modes except planar as it always has its own window. chunky, 16bit PC and BGRA are compatible as they are all accessed through the first window. BGRA is not compatible to chunky, 16bit PC or RGBA as it requires a reconfiguration of the first window, but it is compatible to 16bit hicolor as the latter has its own window. HTHH, Thomas

[DvdBoon]

The Voodoo works this way, I think. I noticed it on the Mediator, the memory list gets corrupted during an endian switch (to e.g. a PC mode) as the Mediator adds part of the VGA memory to the system as usable memory, but also places the memory header of this memory in the memory of the VGA card.

[thorfdbg]

Am 10.02.24 um 00:10 schrieb DvdBoon:

The Voodoo works this way, I think. I noticed it on the Mediator, the memory list gets corrupted during an endian switch (to e.g. a PC mode) as the Mediator adds part of the VGA memory to the system as usable memory, but also places the memory header of this memory in the memory of the VGA card.

Adding VGA memory to the system memory list is a fairly stupid idea - for the reasons given. Also, a switch to planar will corrupt memory, and in planar this will likely not work at all as data goes through the GCR.