<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 2 Feb 2024 at 16:36, John Elliott <span class="gmail_default" style="font-family:courier new,monospace"></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In RAM it's straightforward: Byte 0 is the first pixel, byte 1 is the<br>
next pixel and so on. But when you're using my 256-colour drivers, what<br>
vro_cpyfm() gives you isn't in the same order as it is in video RAM.<br></blockquote><div><br></div><div><div style="font-family:courier new,monospace" class="gmail_default">ok</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

The 256-colour drivers can be found in the FreeGEM VESA driver pack at<br>
<<a href="https://www.seasip.info/Gem/drivers3.html" rel="noreferrer" target="_blank">https://www.seasip.info/Gem/drivers3.html</a>>. My initial release of the<br>
256-colour driver was called SD2569.VGA but later releases are called<br>
<span class="gmail_default" style="font-family:courier new,monospace"></span>SDW109.VGA (1024x768), SDW869.VGA (800x600), SDW649.VGA (640x480) and<br>
SDVLF9.VGA (320x200).<br></blockquote><div><br></div><div><div style="font-family:courier new,monospace" class="gmail_default">
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.<br></div></div><div><br></div><div><div style="font-family:courier new,monospace" class="gmail_default">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.</div><div style="font-family:courier new,monospace" class="gmail_default"><br></div><div style="font-family:courier new,monospace" class="gmail_default">Regards</div><div style="font-family:courier new,monospace" class="gmail_default"><br></div><div style="font-family:courier new,monospace" class="gmail_default">Cyprian</div><div style="font-family:courier new,monospace" class="gmail_default"><a href="https://260ste.atari.org">https://260ste.atari.org</a></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
--<br>
John Elliott<br>
<br>
Cyprian Konador wrote:<br>
> On Thu, 1 Feb 2024 at 14:34, John Elliott wrote:<br>
><br>
>     You can get the number of planes using vq_extnd(), but I don't think<br>
>     there's any way to determine the native pixel format used by the<br>
>     screen<br>
>     (short of drawing on the screen, using vro_cpyfm() to read the<br>
>     bits, and<br>
>     making deductions from what you get back). Back when GEM was being<br>
>     sold<br>
>     commercially, almost everything was either mono or 16-colour in 4<br>
>     bitplanes; I think the one 256-colour driver was for the 8514/a, which<br>
>     used 8 bitplanes.<br>
><br>
><br>
> Fortunately GEM is bitplane based plus one (I think) 8bit packed-pixel<br>
> format, It seems recognizing the screen format would not be a<br>
> difficult task. I will try to use vro_cpyfm or vr_trnfm (to transform<br>
> from standard to device format).<br>
><br>
><br>
><br>
>     The 256-colour drivers I wrote use packed pixels on the display, but<br>
>     still present video memory to <span class="gmail_default" style="font-family:courier new,monospace"></span>vro_cpyfm() as eight planes. The older<br>
>     ones do a lot of shifts and rotations to do this (so the first "plane"<br>
>     maps to bit 0 of every byte, the second "plane" maps to bit 1 of every<br>
>     byte and so on). The newer ones avoid this by saying plane 0 is bytes<br>
>     0,8,16,24... of video RAM, plane 1 is bytes 1,9,17,25... and so on.<br>
><br>
><br>
> Do you mean "<span class="gmail_default" style="font-family:courier new,monospace"></span>sd256.VGA" - I downloaded it from somewhere but now I'm<br>
> not able to find it in Google.<br>
> Does this mean the screen data in RAM is in linear format?<br>
> A)<br>
>     1st byte - 1st pixel, 2nt byte - 2nd pixel, 3rd byte - third<br>
> pixel, and so on.<br>
> Or 'interleaved':<br>
> B)<br>
>     1st byte - 1st pixel, 2nd byte - 9pixel, 3rd byte - 17pixel<br>
>     .....<br>
>     n byte - 2nd pixel, n+1 - 10pixel, n+2  - 18pixel<br>
>     .....<br>
><br><br>
</blockquote></div></div>