Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!ames!amdcad!sun!pitstop!sundc!seismo!uunet!munnari!uniwa!wacsvax!effigy!acp!julian
From: julian@acp.OZ (Julian Elischer)
Newsgroups: comp.os.minix
Subject: Re: 1.3c more notes
Summary: a note on scrolling
Message-ID: <462@acp.OZ>
Date: 27 Oct 88 14:42:17 GMT
References: <3193@sdsu.UUCP> <1499@ast.cs.vu.nl>
Organization: Australian Computer Products, Perth, Australia
Lines: 30


First, an appology about how late this is..
we had a big blockage here in Western AUS.

ast mentions in his articel of the 10th of Oct
the method of scrolling that has the screen creep
one line higher in memory for each scroll, and then does a bulk
copy when the 'creep limit' is reached, to move to the base of video
ram again..  An alternative that might be worth considering is to
just keep 2 screen-fulls of ram for the screen. Characters are written
to 2 locations for each write, one on screen, and one off. When the
'creep limit' has been reached, the screen is reset to the bottom of
the video ram, which should ALREADY contain identical information
to the top of the  video ram, hence no bulk copy is needed.
If it is coded correctly, the extra copy might (no promises)
not prove too much of an extra load ( though the 8086 architecture
may defeat you). Theoretically, this incremental copy MUST
have more overhead, however the elimination of the BULK copies
might be worth the trouble in some situations. ( and anyhow you are
doing the copy anyhow, just at a different time)

I unfortunatly do not have minix  OR a machine to try it on
however I would be curious to hear if anybody can think 
of any advantages or disadvantages to this scheme.

Julian Elischer

julian@acp.oz

UUCP: {check your map,uunet}!munnari!acp.oz!julian