[GEM Development] FreeGEM drivers updated

[John Elliott]

  There are a number of reasons why GEM in 256 colours may not be optimal. 
Firstly, it tends to put pressure on memory for things like offscreen 
bitmaps. Secondly, a lot of applications flatly refuse to believe in there
being more than 16 colours / 4 planes. And thirdly, I wrote the driver to
present the 256-colour linear framebuffer as eight mono planes, and the 
transformation to and fro slows things down.

  (At the time, I had never seen a GEM driver where the number of colours
wasn't 2^(number of planes). I have since seen two: the Trident 4-colour
drivers require four planes for four colours, where you'd expect only two. It
would be an interesting experiment to see how well GEM and its apps cope
with a linear framebuffer; I know my DJGPP bindings wouldn't like it at
all). 
 
> I'm, also, wondering why the GEM/3 _can_ support the higher colors but the =
> later and, presumably, more modern GEM/4 and GEM/5 are not able to. Hmmm.

  You'll see that there is a 1024x768x256 driver for GEM/4 in pack 2. The
reason it's there rather than in pack 1 is because Artline doesn't get on 
very well with more than 16 colours.

  The reason I didn't do it for GEM/5 is that all the GEM/5 drivers I've
done have been for 16-colour VGA-style hardware, since I only had a 
16-colour VGA driver to start from.
 
> When it says "VESA", that's like SciTech Software's VESA BIOS Extension (VB=
> E) TSR or manufactuer's ROM based one?

  Anything that implements those VESA BIOS calls the driver wants 
(INT 10/AX=4F02h to set the mode, INT 10/AX=4F01h to get information, and
so on).

-- 
John Elliott