[GEM Development] Video mode - bitplane vs packed pixels
Cyprian Konador
cyprian.konador at gmail.com
Fri Feb 2 08:57:21 PST 2024
On Fri, 2 Feb 2024 at 16:36, John Elliott wrote:
> In RAM it's straightforward: Byte 0 is the first pixel, byte 1 is the
> next pixel and so on. But when you're using my 256-colour drivers, what
> vro_cpyfm() gives you isn't in the same order as it is in video RAM.
>
ok
> The 256-colour drivers can be found in the FreeGEM VESA driver pack at
> <https://www.seasip.info/Gem/drivers3.html>. My initial release of the
> 256-colour driver was called SD2569.VGA but later releases are called
> SDW109.VGA (1024x768), SDW869.VGA (800x600), SDW649.VGA (640x480) and
> SDVLF9.VGA (320x200).
>
ok, I just checked this driver with "FreeGEM 3.2.3-pacc10a, August 2005".
Currently sd256.VGA works fine for me and I have a problem with
SDW109.VGA/SDW869.VGA/SDW649.VGA - the white color is replaced with black
(in the GEM menu and a window background). Perhaps that is an issue with
DOSBox which I use with FreeGEM.
BTW, I have another problem - available RAM. In 1024x768 8bpp video mode my
application sees 306kB free RAM, but one screen frame 1024x768 8bpp takes
up 768kB. I haven't used memory above 1MB yet (XMS?), but I'll probably be
able to store image data there, but I suspect the GEM's vro_cpyfm won't
reach that memory.
Regards
Cyprian
https://260ste.atari.org
>
> --
> John Elliott
>
> Cyprian Konador wrote:
> > 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
> > .....
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.simpits.org/pipermail/gem-dev/attachments/20240202/c9d0b735/attachment.html>
More information about the gem-dev
mailing list