🚀 go-pugleaf

Henning Percy (ssu94081@reading.ac.uk) wrote:
>I run the topspeed compiler of modula 2, and I want to start coding 
>graphics properly, making my own libraries. I know it is possitble to 
>create an array and place it over the memoery location for the screen and 
>then copy this to save the screen in textmode.
>Does anybody know the data structure for the array to use for doing this 
>in graphics mode?
>I was told there are two different ones depending on whether it is 16 or 
>256 colour graphics.

Actually there are more than two; it almost boils down to having
to use a different strategy for every different mode.

Mode 19 (or 13H, if you prefer) is the simplest case.  It's a
256-colour mode which uses one byte per pixel, i.e. each pixel has
an 8-bit colour code.  To do a "screen copy" operation, you
merely have to do a block copy between your array and the video
memory address, just as you would have done in text mode.
The only difference is that the video memory address is
different from the address used in the text modes, but I guess
you already knew that.

The other 256-colour modes also use one byte per pixel, but
have the extra complication that a complete screen uses more
than 64K bytes.  The hardware uses bank switching, where each
bank holds a 64Kbyte section of the screen.  To do a screen copy,
you have to copy one bank at a time; before copying each bank,
you have to do a "bank select" operation on the hardware.  If
you have a VESA driver then there's a standard way to do the
bank select.  If you don't, then you're stuck with the sad fact
that each SVGA card uses a different method for bank switching,
so you're stuck with writing non-portable software.  To make
matters worse, the available documentation for SVGA cards is
very poor; most manufacturers seem to have the attitude that
the programming details are an industrial secret, and that you
should switch to using Windows (a fate worse than death) so that
you can use their own buggy video drivers.

The 16-colour modes are completely different.  Here a pixel is
specified by a 4-bit colour code, but the 4 bits are not packed
in the obvious way.  Instead, they're distributed over four
"bit planes".  Each byte in the video memory contains one bit
for each of eight adjacent pixels.  To get at the other three
bits, you have to address the hardware registers in such a way
as to address the desired bit plane.  The hardware interface is
a complex one, and it would take a VERY long posting to even
start on describing how to program it.

The bottom line is that to do any low-level video operations on
the PC you either have to put in a lot of study (it took me many
months) into understanding the hard-to-find and confusing hardware
documentation, or you have to put a lot of study into understanding
someone else's source code.

If you want my own source code, take a look at
       file://ee.newcastle.edu.au/pub/PMOS/PMOS.html
That's a WWW reference.  If you don't have WWW, use anonymous ftp
to the same site and directory and fetch either the file
graf004.zip (graphics drivers written in Modula-2) or the file
pmos220.zip (a later version, but it's bundled in with a lot of
other sources that you might or might not want).  You'll probably
also find it useful to fetch the file graphics.html.

Afterthought: before initiating a huge ftp operation, check the
site dutiba.twi.tudelft.nl to see whether the files are there
(they were some time ago, but I haven't checked lately).  That's
closer to you, so probably will give a faster transfer.

>	 replies please to :- ssu94081@rdg.ac.uk

I'll mail a copy of this as well as posting it ... but I should
warn you that some people get quite shirty about responding to
requests that seem to imply (rightly or wrongly) that you're not
going to read the newsgroup.

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           file://ee.newcastle.edu.au/pub/www/Moylan.html