Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cuae2!ihnp4!drutx!mtuxo!houxm!hjuxa!catnip!ben
From: ben@catnip.UUCP (Bennett Broder)
Newsgroups: net.micro.pc
Subject: Re: Writing directly to screen memory
Message-ID: <411@catnip.UUCP>
Date: Wed, 5-Nov-86 23:59:29 EST
Article-I.D.: catnip.411
Posted: Wed Nov  5 23:59:29 1986
Date-Received: Fri, 7-Nov-86 22:22:56 EST
References: <442@uwmacc.UUCP>
Distribution: net
Organization: The Broder Residence, Holmdel, NJ  07733
Lines: 24

In article <442@uwmacc.UUCP>, curtis@uwmacc.UUCP (Alan Curtis) writes:
> I have been perusing through some assembler code written who knows where,
> and I noticed that when a particular routine writes to screen memory,
> it first reads the video controller scan status and makes sure it is 
> low, then after it goes low it waits until it goes high before writing
> to the screen buffer in memory.  The associated comment remarks that
> it must go high before it is safe to write directly to screen buffer
> memory.
> 
> Is it possible to damage the monitor if the screen writes are not 
> synchronized with the scans, or is there some other explanation.  

The reason that programs check before they write to screen memory is
because the IBM color graphics adapter (cga) was very poorly designed.
If you update the screen without the check, the screen will flash with
very annoying snow.  The check you saw waits until the monitor is in
retrace, (the beam is always turned off during retrace, for obvious
reasons) and then updates memory.

-- 

Ben Broder
{ihnp4,decvax} !hjuxa!catnip!ben
{houxm,topaz}/