[GEM Development] Video mode - bitplane vs packed pixels

[Cyprian Konador]

On Thu, 1 Feb 2024 at 14:34, John Elliott wrote:

> You can get the number of planes using vq_extnd(), but I don't think
> there's any way to determine the native pixel format used by the screen
> (short of drawing on the screen, using vro_cpyfm() to read the bits, and
> making deductions from what you get back). Back when GEM was being sold
> commercially, almost everything was either mono or 16-colour in 4
> bitplanes; I think the one 256-colour driver was for the 8514/a, which
> used 8 bitplanes.
>

Fortunately GEM is bitplane based plus one (I think) 8bit packed-pixel
format, It seems recognizing the screen format would not be a difficult
task. I will try to use vro_cpyfm or vr_trnfm (to transform from standard
to device format).



The 256-colour drivers I wrote use packed pixels on the display, but
> still present video memory to vro_cpyfm() as eight planes. The older
> ones do a lot of shifts and rotations to do this (so the first "plane"
> maps to bit 0 of every byte, the second "plane" maps to bit 1 of every
> byte and so on). The newer ones avoid this by saying plane 0 is bytes
> 0,8,16,24... of video RAM, plane 1 is bytes 1,9,17,25... and so on.
>

Do you mean "sd256.VGA" - I downloaded it from somewhere but now I'm not
able to find it in Google.
Does this mean the screen data in RAM is in linear format?
A)
    1st byte - 1st pixel, 2nt byte - 2nd pixel, 3rd byte - third pixel, and
so on.
Or 'interleaved':
B)
    1st byte - 1st pixel, 2nd byte - 9pixel, 3rd byte - 17pixel
    .....
    n byte - 2nd pixel, n+1 - 10pixel, n+2  - 18pixel
    .....

Thanks


Regards

Cyprian
https://260ste.atari.org


--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.simpits.org/pipermail/gem-dev/attachments/20240202/f6959e64/attachment.html>