Video output corruption on Picasso II with 1MB VRAM

[superfrog]

Here's another RAM allocation issue...

Picasso II/II+ with 2 MB VRAM works fine [SS-01]. But if I drop it down to 1 MB (the default amount of RAM the real board originally shipped with) the display is corrupt to the point of being almost unusable [SS-02]. It's more usable with the original Picasso software [SS-03], and much worse with Picasso96. [See screenshots]

I also notice that with most of the RTG boards, when configured with the lowest possible amount of VRAM, ShowConfig reports that the board has the next-higher possible amount. For example, for Picasso II configured with 1 MB VRAM, ShowConfig reports that the board contains 2meg. For boards that have a 2 MB minimum, with the 2 MB setting ShowConfig reports 4meg. The higher amounts of configured RAM always report correctly. The UAEgfx boards do not have this issue. The amount of RAM is always reported correctly.

Perhaps there is some connection between the incorrect amount of RAM the OS sees and the display corruption?

https://eab.abime.net/zone/Picasso%2...0Corruption.7z

[Toni Wilen]

It is correct that autoconfig board size equals max supported VRAM size. (It makes board design simpler). Picasso IV is a special case (but it is also quite complex board), it supports both 4M and 2M board sizes.

Main problem is VRAM mirroring that happens when board has less RAM than Cirrus Logic chip can access and this mirroring is not fully correct in all situations. (Partially because emulation is from QEMU and it wasn't even attempting to support any weird edge cases..)

[superfrog]

Thanks for the explanation. It makes sense that the board allocates the maximum allowable amount of address space, even if not all of it is used. I notice with the Z3 boards that ShowConfig reports explicitly the size of the allocated address space, along with a "subset" value reflecting the actual amount of allocated space that is used by the currently installed VRAM.

With Picasso IV, I notice ShowConfig reports 1 allocated 2meg segment for board with 2 MB configured, and 2 allocated 2meg segments for board with 4 MB configured.

If the display corruption is a consequence of incomplete emulation of how the CL-GD542x chips behave when less than the max usable VRAM is installed, is it unlikely to ever be fixed, or can/will it be fixed at some point?

I only ask because, while it's mostly a non-issue that can be circumvented by simply allocating more RAM to the board, if it's a known issue that will never be fixed, then it should probably be noted in the release notes as a known issue with the emulation of these boards, just to save confusion for anyone who encounters display corruption when running with less than the max usable amount of VRAM. I searched the changelogs and found no such notation.

[Toni Wilen]

It will be fixed someday.

Main problem is driver size detection which is not simple, it basically configures CL chip memory controller using different parameters and checks how RAM works. Which means emulation most invalid memory mapping side-effects which is really complex and usually not worth the trouble.

Having driver sources would make it much easier to find out what it tries to do. Then developing a hack that passes the test should be relatively simple.