🚀 go-pugleaf

In article <1929@uw-june.UUCP> roper@uw-june.UUCP (Michael Roper) writes:
>Can anyone recommend a good reference book providing in-depth
>programming information for the various video controller types?  I am
>looking for something in the style and price range of say, Norton's book
>or Advanced MS-DOS (as opposed to the Options and Adapters Manual).
>It should do a thorough job of sorting out the current state-of-affairs
>in video adapters, especially the various EGA and PGA standards -- which 
>are given the short shrift in both of the aforementioned books. 

Well, I'm afraid I can't quote you a definitive, readable, understandable
etc. source. For myself, I took the sparse information in Norton&Co. and two
articles quoted there (?) and started trying. I think that these two
articles are a fair beginning point for dealing with the EGA, but they are,
of course, just an introduction and bare-bones hardware/BIOS listing. No
PGA there, either.
If you want to try them, here are the article quotations (your favorite
library ought to have them):

	*Graphic Enhancement*
	PC Tech Journal, April 1985
	pages 58-77
	- gives a good summary of hardware and BIOS calls for the EGA -

	*Programming The Enhanced Graphics Adapter*
	BYTE magazine, fall 1985 issue ("Inside The IBM PCs")
	Pages 209-220
	- gives an introduction into the hardware of the EGA -

For both articles, it helps a lot if you have already done some video
programming before.

In the meantime, here are the answers to your questions:

>1)  Since only 128K of main memory is reserved for display buffers (from
>    A0000 to BFFFF), where do EGA's with "a full 256K of RAM", put the 
>    other 128K?  Or is it just bank-switched?

In the old CGA-compatible modes, the memory layout is identical to that
of the CGA. Of course, you are using only a small part of the EGA memory
in this case.
In high-resolution (640x350) mode, memory is divided into four parallel
"planes". Each plane covers the entire screen and contributes one bit to
the color information; the four bits at identical positions in the four
planes give the (four-bit) number of the color in that pixel, and this
number (0 through 15) indexes the real color stored in the EGA's palette
vector (hence 16-out-of-64 colors).
In the PC's address space, the four planes occupy the same addresses
(so they fit into <64K). You CAN'T write directly into video memory as you
would with a CGA or Hercules adapter (or the EGA in CGA mode); instead you
have to set various and sundry hardware registers to select one of several
read/write modes, and what you finally read from/write to the memory
locations is latched, masked, shifted, and otherwise twisted around depending
on these modes. It sometimes gets rather complicated; obviously, they designed
it for efficiency rather than for ease of use.

>2)  By my calculations, 112K is required for a full page of graphics in
>    video mode 10h, using a 16-color palette.  Is the rest of the (128K)
>    display memory wasted?
The EGA maintains status information on its own RAM, most notably the color
palette and programmable character fonts. Consider that you can load four
complete bit-mapped character sets (with up to 128 characters each) into
the EGA (although you can only use two at a time). Of course, some bytes
(probably a few K) are wasted, but who counts memory chips nowadays :-).
By the way, with a 256K EGA, you can really have two high-res display pages.

>3)  Advanced MS-DOS says that mode 10h uses either a 4- or 16-color palette,
>    depending upon the amount of display memory provided by the adapter.
>    Is this selection made automatically?  What is the cut-off?
The 4-color palette in high-res (10h) mode is used only on the minimal (64K)
version. As you noted, you need 112K (and some more) to represent a full
16-color high-res page. On a 64K-diet, the EGA switches to 2 planes (instead
of 4) and has therefore only a 4-out-of-64 color selection. With 128K, you
get one page of 16 colors. This selection is made automatically (by the BIOS).

>4)  Norton makes a vague reference to the difficulty of writing directly
>    to the EGA's display buffer.  What's the story?  Are the pros and cons
>    of accessing the EGA's buffer directly any different from say, the MA
>    or CGA?
See answer to (1). It's a completely different world. On the one hand, you
don't 'see' the pixels any more in your address space, so the simplicity of
reading or changing individual pixels just via a 'mov' is lost. On the other
hand, the various read/write modes of the EGA give you (I think) adequate
support to do things *efficiently* (though not very *simply*). You certainly
have to go to considerable lengths to program the EGA directly.
The BIOS makes a valiant effort to hide this complex hardware from you. You
can still happily call the *read pixel* or *set pixel* etc. functions of
INT 10h. However, as these calls are *elementary*, using them to build
complex graphics makes your program **awfully slow**. Remember that there's
also 75% more pixels to handle...

I hope this helps you (and other Net-People).

P.S.: Would some kind souls out there please try to send me mail? I suspect that
 ***  there's something fishy about my incoming mail address, but I'd love
 ***  to learn otherwise... thanks in advance.
------------------------------------------------------------------------
  <<  Perry The Cynic >>	      ...!tektronix!ogcvax!omepd!inteloa!perry
						...!verdix!omepd!inteloa!perry
    (Peter Kiehtreiber)			      -or try- perry@inteloa.intel.com