Programmer 7500/MAX_PROGRAMMERS.iso/PASCAL/MCGA#02.ZIP/LESSON02.TXT

Text File | 1992-06-11 | 5.5 KB | 106 lines

                           MCGA Graphics Tutorial
                                 Lesson #2
                                by Jim Cook

I have to apologize a little bit.  The first lesson contained code for
setting a pixel by directly altering video memory.  This probably was a
strange sight for those of you that do not understand video memory, how
it's layed out and how to address it.  I do hope you did get excited by
workable code in the first lesson.

Video memory in the MCGA Mode we are using is far simpler to understand
than even Text mode display memory.  Those of you that know all about
text screen addressing, just scoffed.  No, seriously, it is as simple.
I will try to make this easy to understand, because it really is.

There is an area in your computer's memory that holds the program that is
currently running, as well as, COMMAND.COM and other system drivers.   s
Most of you realize that there is also a section of memory that holds
all of the information regarding your video screen.  In the MCGA #1 you
will notice that we changed the value of a byte in memory to change the
color of a pixel on the screen.  This may seem magical to some, but it
really isn't.  The logic driving a video card is simply this:

    1. Scan video memory and write the bytes you see there
       to the screen.
    2. Repeat Step 1.

Unlike COMMAND.COM and the program that's running, whose starting address
in memory could be different depending on a multitude of factors, video
memory is always at the same location.  In MCGA mode, video memory begins
at the 655,360th byte of computer memory.  You may say that my computer
only has 655,360 bytes of memory total (640K).  Where does that memory
reside?  Don't quote me on this, but I believe that the video memory
wholly resides on your graphics card.

So, the graphics card is responsible for scanning this piece of memory
many times per second, and displaying on the screen whatever color
values are stored starting at byte 655,360.  By the way, in hex (base 16)
that number is $A0000, and we'll refer to it like that from now on.
These color values that I referred to are numbers from 0 to 255.  If we
store the number 0 in every byte of screen memory and the computer
thinks that 0 means black, which it usually does, the screen will
instantly clear to black.  That's how you do a screen clear in MCGA.

The resolution of our screen is 320 pixels horizontal by 200 pixels
vertical.  That makes up a total of 64000 pixels per screen.  A normal
text screen only has 4000 bytes of screen memory, so you can see why we
sometimes use assembly language.  So, a very prehistoric screen clear
procedure could look something like:

                Procedure ClearScreen (Color:Byte);
                var
                  I  :  Word;
                begin
                  For I := 0 to 64000 do
                    Mem [$A000:I] := Color;
                end;

You'll notice I had to break the number $A0000 into two numbers.  This
is called segment-offset addressing, and it is a throwback to the days
when the engineers felt we would never need more than 640K of memory.
Let me briefly explain.  The memory address $A0000 and $A000:0000 are
synonymous.  To compute a virtual address from a seg:ofs address you
perform the calcualtion: virtual := seg * 16 + ofs.  This lets a
programmer access over 1 meg of memory using 2 word size values.  Don't
ask...

OK.  Since we are pretty much all hackers at heart and I don't have a
chalkboard, I'll illustrate video memory:
              0   1   2   3   4   5   --->  up to pixel 319
            +---+---+---+---+---+---+---+---+---+---+---+---+--
        0   + 0 | 1 | 2 | 3 | 4 | 5 |   |   |   |   |   |   |
            +---+---+---+---+---+---+---+---+---+---+---+---+--
        1   +320|321|322|323|324|   |   |   |   |   |   |   |
            +---+---+---+---+---+---+---+---+---+---+---+---+--
        2   +640|641|642|643|   |   |   |   |   |   |   |   |
            +---+---+---+---+---+---+---+---+---+---+---+---+--
        3   +   |   |   |   |   |   |   |   |   |   |   |   |

Assume, (I know, bad word), that this is a extreme closeup of the upper
left corner of a MCGA screen.  As a matter of fact the box 0 is the
first pixel (the uppermost leftest most pixel) on the screen.  Say, we
want to make it white.  In the default palette the color white is 255.
All we have to do is say:       Mem [$A000:0000] := 255;
If we want to make the pixel below it white also, we type :
                                Mem [$A000:0320] := 255;
As you can see, segment:offset addressing actually comes in handy in
addressing pixels on the screen.  Since there are 320 pixels across and
200 Pixels up and down, the following formula returns the address of any
pixel on the MCGA screen:       (Y * 320) + X
This is assuming the upperleft pixel is (0,0) and the lower right pixel
is (319,199), and we will.

Understanding screen addresses is essential to comprehending any of the
code we will be developing, so if a point is not clear...POST a message.
Don't be bashful about asking questions.  Just a quick point...I did not
go to school to learn this.  This is something everyone can learn.
Graphics is a subject that a lot gets written about, but not the guts of
programming it.  Many of you may opt for the easy way out (canned
libraries) but to really understand your computer you have to know
what's going on under the hood.  Also, for laughs, try implementing a
good animation program or GUI with the BGI.

hack on
jim