Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!nsc!pyramid!leadsv!zech
From: zech@leadsv.UUCP (Bill Zech)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why no graphics in text mode?
Summary: it's the hardware
Message-ID: <9386@leadsv.UUCP>
Date: 13 Jan 90 02:24:33 GMT
References: <25820@cup.portal.com>
Organization: LOCKHEED, Sunnyvale, CA
Lines: 34

In article <25820@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) writes:
> I'm trying to figure out why there is this division 
> between text and graphics modes with PCs. 
   [ some deleted]
> 
> I'm assuming that each screen pixel is represented 
> by a bit in memory (or several bits) even in text 
> mode - but in text mode the bits are written with 
> bit maps from the BIOS.
> 

The original PC video is built around a Motorola 6845 CRT controller
chip.  This chip does two distinctly different things in text mode
and graphics mode.  When in graphics mode, text is displayed much 
as you describe.  The BIOS looks up bit patterns in ROM or an
auxiliary table and writes them to graphics memory to form 
characters bit by bit.

In text mode, the video memory does *not* hold bit maps.  It holds
ASCII.  (actually, an IBM defined extension of ASCII).

The 6845 does the character lookup in its associated ROM and blasts
the dots up on the screen on the fly.  The 6845 also implements the
attributes such as blink, inverse, hi/low, underline.  Note that
all these attributes must be handled in software when in graphics mode.

So, text mode means you write ASCII + attribute byte to the video
memory and the 6845 interprets it.

Graphics mode means you program the dots yourself.

Of course, you can mix graphics and text all you want in graphics mode.

- Bill