PCBUILD Archives

Personal Computer Hardware discussion List

PCBUILD@LISTSERV.ICORS.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Gillett <[log in to unmask]>
Reply To:
PCBUILD - Personal Computer Hardware discussion List <[log in to unmask]>
Date:
Tue, 23 Mar 1999 14:43:33 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
On 23 Mar 99, at 13:24, Earl Truss wrote:

> ----------
> > From: David Gillett <[log in to unmask]>
> > Subject: Re: [PCBUILD] only 16 colors with S3 trio 64+
> > Date: Monday, March 22, 1999 8:25 PM
> >
> > On 22 Mar 99, at 15:08, Earl Truss wrote:
> >
> > > Colors                        Number of bytes
> > > 16                               1
> >
> >   .5, actually.  A vanilla VGA can do 16 colours at 640x480 resolution
> > with only 256KB of installed video RAM (and some really gross interface
> > programming, which is why you want the driver to take care of the
> > details), and everybody emulates this as a "lowest common denominator".
> >
> But does it really only use 1/2 byte for each pixel?  I would think this
> would be pretty horrendous for the card to handle since most hardware
> works on byte boundaries rather than trying to work on four-bit
> boundaries. Maybe that's what you are talking about when you mention
> "really gross interface programming"?

  Actually, it's worse than that.  [I wasn't going to go into detail, but
I guess I will.]

  When the card is in 16-colour mode, the memory is organized as four
"planes", each with one bit per pixel.  Changing the colour of a single
pixel can involve mapping each plane, in turn, into the 64KB window at
real address A000:0000, reading the appropriate byte into a register,
modifying the value and saving it back to the register.
  This kind of "modify some bits within a byte"[*] was routine in
various CGA modes, but having to go through it four times for a single
pixel is I think unique to the VGA.
  To be fair, there are some simple optimizations which help if you're
drawing horizontal lines, including times when you're filling blocks of
solid colour.  So it generally isn't four times as slow as you'd expect
-- only in the worst case.

  Wilton's "Programmer's Guide to PC and PS/2 Video Systems" is my
preferred reference for this stuff, although my copy is the original
edition and there is a newer one out.  Any more, a lot of this
technical detail is most useful only to writers of video drivers.

[*] The usual techniques are "mask and shift", and working with
fractions of bytes is only a little more work than using whole bytes.
It's having to do it separately for each bit that gets really tiresome.

> I thought it more likely that the card is really running at EGA/VGA
> resolution of 640x320 which can be done in 256K using a full byte for each
> pixel.  Once upon a time, 640x480 and anything above that was considered
> "super VGA" resolution.

  Many cards support EGA resolutions as well, but not all.  I've always
heard "Super VGA" (or "SVGA") defined as starting with
800x600x256colours.

David G

            Do you want to signoff PCBUILD or just change to
                    Digest mode - visit our web site:
                    http://nospin.com/pc/pcbuild.html

ATOM RSS1 RSS2