Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!hp4nl!phigate!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: Screen Saver
Keywords: Vsync VBL-Queue
Message-ID: <1025@philmds.UUCP>
Date: 9 May 89 12:12:02 GMT
References: <1040@gmdzi.UUCP> <7871@batcomputer.tn.cornell.edu>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 26

In article <7871@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (Moshe Braner) writes:
|Here is of IDLE, version 1.2.
|Reminder: IDLE 1.2 replaces NIGHT, NITE, and earlier versions of IDLE,
|all of which had serious bugs.  IDLE blanks the screen after 6 minutes
|of no activity (up from 3 in 1.1) and unblanks upon keyboard/mouse
|input or BIOS text output.
|
|All IDLE does is zero the palette AND shift the video RAM pointer 32K
|below the normal location.  Since that area is normally all zeros,
|zeroing the video palette will display it as all black.  IDLE checks
|to see that that piece of RAM is all zeros, and if it is not, it leaves
|the video pointer as it was, but still zeros the palette.  This has the
|effect of blanking the screen in color mode, but only reversing black
|and white in monochrome mode.  The check for nonzeros is done slowly,
|so strange things _might_ show on the screen for up to 20 seconds.
|But not to worry: IDLE does _not_ write to the video RAM.

But I'm still worried: if the 32K below the normal physical screen
location (or part of it) belongs to a program (it often does) and
contains all zero's, IDLE will make the video RAM pointer point into
that (probably executing) program. Subsequent data changes in this part
of the program will reflect on the screen, and, what is worse, writes
to the screen will modify the data in the program (and note that not
all screen output is directed via the BIOS calls).

         Leo.