Path: utzoo!mnetor!uunet!mcvax!ukc!mupsy!liv-cs!unpowell
From: unpowell@csvax.liv.ac.uk
Newsgroups: comp.sys.atari.st
Subject: Re: ST hardware scrolling
Message-ID: <1282@csvax.liv.ac.uk>
Date: 2 May 88 21:44:12 GMT
References: <544@csvax.liv.ac.uk> <4484@batcomputer.tn.cornell.edu> <1794@brahma.cs.hw.ac.uk> <237@forty2.UUCP>
Lines: 61
Organisation: Computer Science CSVAX (VAX1), Liverpool University


In article <237@forty2.UUCP>, poole@forty2.UUCP (Simon Poole) writes:
> 
> My two cents:
> 
>         - Screen refresh rate is 50/60/70 Hz, even if you switch
>           screens faster, nobody actually sees your work of art,
>           so you can just as well scroll 2-3 lines at once in
>           software and synchronize it with the VBI and get the
>           same effect.

	However, the hardware scrolling takes up (alot) less processor time than
the software method. This is it's main advantage! I know you can only scroll
a 25 line screen with it, but the speed achieved cannot be equaled by any
of these "scroll as many times as the user lets you" methods.

>         - Doesn't work in 50 line mode on monochrome screens.

	Never said it did!

>         - As soon as you start having portions of the screen which
>           should stay static, your performance win gets smaller
>           and smaller (in uEmacs or in a VT100 Emulator this would
>           lead to added complexity that's just not worth the 
>           trouble).

	I agree, your Uniterm wouldn't benefit from this method.

>         - While hardware scrolling on the ST might be great to
>           show off to your friends:
>           "Hey look, it scrolls so fast that you can't read the
>            text anymore!"
>           it's not realy useful, typically 40 to 50 lines/second
>           give a pleasing (and half legible) effect (Tempus does
>           ~46 lines/second on normal text with full size window).

	The method wasn't suggested as "the fastest and the only that you
need use ever again", it is merely another method. Albeit the fastest!
When I say fastest I mean, the method that uses up the least processor time
(a factor which is pretty important in a lot of programs); not the method which
produces the fastest line movement (which incidentaly, it does also do).
	A lot of programs which are written for speed, lose a considerable
proportion of their speed on the output of data. If they used hardware
scrolling they could devote more of the processor time to the job inhand than
the actual outputting of results. This is the factor that first prompted
me to write a hardware scrolling routine. I was timing a "super fast" (?)
prime number generator, out of curiousity. It took 3 seconds to produce
it's list of numbers when it was outputting them to the screen and less
than one when it didn't do any outputting. Quite a difference, don't you
agree? Well okay I'm a bit of a speed freak (like to make the best use of
the processor not an amphetamine addict).

	Mark Powell

********************************************************************************

 "...I hate the white	JANET unpowell@uk.ac.liv.csvax
  man, and the man	UUCP  {backbone}!mcvax!ukc!mupsy!liv-cs!unpowell
  who turned you all	ARPA  unpowell%csvax.liv.ac.uk@nss.cs.ucl.ac.uk
  loose..." R. Harper

********************************************************************************