curtis@uwmacc.UUCP (Alan Curtis) (10/31/86)
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.
I have a few turbo programs that write directly to screen memory
without doing any kind of checking for scan status, and I'm hoping
that this isn't doing any damage to the monitor.
Thanks,
--
Alan Curtis
Madison Academic Computing Center
ARPA: curtis@UNIX.MACC.WISC.EDU
UUCP: {harvard,ucbvax,allegra,ihnp4,seismo}!uwvax!uwmacc!curtisballou@brahms (Kenneth R. Ballou) (10/31/86)
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 word "safe" here refers to avoiding "snow" on the screen. This is the procedure to avoid creating snow when updating the screen on older video cards. Newer cards have no problem with direct screen writes. --- Kenneth R. Ballou ...!ucbvax!cartan!brahms!ballou Dept. of Mathematics University of California Berkeley, California 94720
jnk@drutx.UUCP (KelleyJN) (11/01/86)
Writing to the screen memory during the retrace period avoids getting
snow on the screen while the memory update is going on.
John Kelley
AT&Tvg55611@ihuxk.UUCP (gopal) (11/01/86)
> 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. I wrote a program sometime ago that writes to and reads from the screen memory extensively and did not check the video controller scan status. Never had any problems of any kind (the program has been in use for a couple of years). I have never seen any warning about doing this anywhere either. The only thing I can guess is that this may prevent "snow". Some other netlander may have a better guess. Venu P. Gopal, ihnp4!ihuxk!vg55611
ben@catnip.UUCP (Bennett Broder) (11/06/86)
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}/