Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!mit-eddie!killer!chasm
From: chasm@killer.DALLAS.TX.US (Charles Marslett)
Newsgroups: comp.sys.ibm.pc
Subject: Re: 16 bit cards vs 8, SHAFTED?
Summary: If you see it -- look again, its not there!
Message-ID: <7415@killer.DALLAS.TX.US>
Date: 4 Mar 89 17:09:41 GMT
References: <37020@tut.cis.ohio-state.edu> <14313@bigtex.cactus.org> <14505@bigtex.cactus.org>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 62

In article <14505@bigtex.cactus.org>, james@bigtex.cactus.org (James Van Artsdalen) writes:
> How so?  VGA cards have their own BIOS.  I assume those vendors code
> their BIOS to use their hardware properly.  The code in the
> motherboard BIOS isn't generally used.  The video card BIOS is certain
> to use 16 bit moves to scroll the screen.

As the author of half a dozen of those BIOSes, I consider myself more-or-less
an authority on this issue.  Mostly we who write BIOSes put our emphasis on
(1) making the d**n thing fit into the 16/30/32K of ROM space we have to work
with, (2) making all the flakey software out there work with it (the STB BIOS
write-dot function was at one time almost 3 times as fast as the second fastest
I could identify -- but because the registers in the CRTC/graphics controller
were not left in the same state as IBM left them, several programs broke -- so
we do it like every one else now...), then (3) making it run fast.

Specifically, all the GOOD 16-bit cards have some way to disable 16-bit operation
since the faster 386 boxes often do not work with them in 16-bit mode.  In
fact, we have one card (I believe it is a Video 7 VRAM card, but it may be one
of the others) that asserts a very short 16-bit acknowledge and on my Everex
Step/20 386 box it runs in 8-bit mode whether it realizes it or not -- so says
the PC Tech Journal ATPERF program.

> >[Some comments about non-significance of the improvement in speed]

> If you can see it, it's definitely an improvement.  If you can't, it
> usually isn't.  Whether or not something is an improvement from the
> CPU's perspective is entirely irrelevant: on the user's perspective
> matters.

And here I might add that if a program runs slower, but makes the
user wait less (not the case here, but often the case when a serial
tasking program is converted to running with multiple tasks) most people
will consider it faster, even if it does more poorly on the standard
benchmarks!

> > 4) Speed improvement in graphics modes is less since you cannot do 16 bit
> > graphics manipulations.
> 
> Oh?  I've been doing it for years.  If you store sixteen bits to the
> screen, you get that bit pattern displayed.  You just have to store
> the right sixteen bits.

Unfortunately, this is not true in general for EGA/VGA products.  If you
write your own graphics I/O routines (that is, write code that is NOT EGA
compatible) you can do 16-bit graphics I/O.  In fact, generic EGA graphics
access is even possible using 16-bit transfers, but the overhead and the
difficulty of the code (it is nearly impossible to follow, since the pixel
layout is erratic, and many registers need to be modified every few pixels)
make this very rare.  The normal methods of accessing EGA 16-color graphics
modes (VGA also) are inherrently 8-bit unless you are going to simulate
monochrome and write all 4 planes at once all the time.

> -- 
> James R. Van Artsdalen          james@bigtex.cactus.org   "Live Free or Die"
> DCC Corporation     9505 Arboretum Blvd Austin TX 78759         512-338-8789

Charles Marslett
===========================================================================
Charles Marslett
STB Systems, Inc.  <== Apply all standard disclaimers
Wordmark Systems   <== No disclaimers required -- that's just me
chasm@killer.dallas.tx.us