braner@batcomputer.tn.cornell.edu (braner) (04/20/88)
[] Two problems with the suggestion for "hardware scrolling": (1) The ST's video pointer must be on a 512-byte boundary, NOT 256. Thus, incrementing it by $500 (1280) (to scroll by one text line) is NOT feasible. (I tried it: the screen goes crazy!) One could scroll TWO text lines at a time, though. (2) This solution only applies to scrolling the entire screen, while Tempus, Laser C, etc fast-scroll arbitrary WINDOWS. Rather impressive. What I do in MORE.TTP for fast scrolling is: no scrolling. I clear the screen before writing the next one. That is a lot faster since, again, 32000 bytes need to be manipulated (cleared, in this case) only once per 25 lines. It is also faster in another sense: The user can glance at the top lines while the bottom ones are being printed. In MORE (and GNOME too!), if you see that you want to scroll further, you press the appropriate key and the printing of the current screen is aborted immediately, the screen is cleared, and the next screen is printed. - Moshe Braner
neil@cs.hw.ac.uk (Neil Forsyth) (04/22/88)
In article <4484@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (braner) writes: >(1) The ST's video pointer must be on a 512-byte boundary, NOT 256. >Thus, incrementing it by $500 (1280) (to scroll by one text line) >is NOT feasible. (I tried it: the screen goes crazy!) One could >scroll TWO text lines at a time, though. No. It can go on a 256 byte boundary. I tried, and suceeded long ago for some smooth scrolling I did and it worked just fine for me. The screen just looks crazy because 256 bytes doesn't use an integer number of scanlines. (1.6 in colour modes) >(2) This solution only applies to scrolling the entire screen, >while Tempus, Laser C, etc fast-scroll arbitrary WINDOWS. Rather >impressive. Yup! I have not seen Tempus but my guess is they use "movem.l" all over the place and possibly force the windows to lie on 8 or 16 pixel boundaries so that there is no half characters to slow the thing down. It is often the case that a little machine (not OS) dependance goes a long way. ------------------------------------------------------------------------------- "I think all right thinking people in this country are sick and tired of being told that ordinary decent people are fed up in this country with being sick and tired. I'm certainly not and I'm sick and tired of being told that I am!" - Monty Python Neil Forsyth JANET: neil@uk.ac.hw.cs Dept. of Computer Science ARPA: neil@cs.hw.ac.uk Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil Edinburgh Scotland -------------------------------------------------------------------------------
unpowell@csvax.liv.ac.uk (04/22/88)
In article <4484@batcomputer.tn.cornell.edu>, braner@batcomputer.tn.cornell.edu (braner) writes: > [] > > Two problems with the suggestion for "hardware scrolling": > > (1) The ST's video pointer must be on a 512-byte boundary, NOT 256. > Thus, incrementing it by $500 (1280) (to scroll by one text line) > is NOT feasible. The video pointer goes on a 256 byte boundary. You must have a pretty weird ST there. I've had the hardware scrolling working fine. The screen memory location is held in addresses $ff8201 (high byte) and $ff8203 (mid byte). The low byte is always taken as 0 by the ST. Thus, as you can see, this allows the screen to be put on 256 byte boundaries. > (I tried it: the screen goes crazy!) Maybe it's just you thats crazy? 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 ********************************************************************************
poole@forty2.UUCP (Simon Poole) (04/27/88)
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.
- Doesn't work in 50 line mode on monochrome screens.
- 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).
- 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).
--
----------------------------------------------------------------------------
UUCP: ...mcvax!cernvax!forty2!poole Simon Poole
BITNET: K538915@CZHRZU1A
----------------------------------------------------------------------------magore@watdcsu.waterloo.edu (Mike Gore, Institute Computer Research - ICR) (04/28/88)
My 2 cents to do 'hardware' scrolling would be to do it partly in software and hardware. If we were to use the horizontal interrupt we could maintain a linked list of scan lines - or even a group of scan lines. This could be run as a interrupt driven display process that would then be a set up as a display list of sorts. In order to scroll the entry link for the beginning of the display would only need to be changed. If a group of scan lines were used to make up a single character line interrupt Overhead could be reduced and character I/O would be slightly easier. The disadvantage to this method would be the waisted space at the end of each line [ required to fall on 256 byte offsets ] and interrupt overhead. Comments ??? # Mike Gore # Institute for Computer Research. ( watmath!mgvax!root - at home ) # These ideas/concepts do not imply views held by the University of Waterloo.
poole@forty2.UUCP (Simon Poole) (04/29/88)
In article <4650@watdcsu.waterloo.edu> magore@watdcsu.waterloo.edu (Mike Gore) writes >My 2 cents to do 'hardware' scrolling would be to do it partly >in software and hardware. If we were to use the horizontal interrupt >we could maintain a linked list of scan lines - or even a group of >scan lines. This could be run as a interrupt driven display process that >would then be a set up as a display list of sorts. In order to scroll the >entry link for the beginning of the display would only need to be changed. If >a group of scan lines were used to make up a single character line interrupt >Overhead could be reduced and character I/O would be slightly easier. The >disadvantage to this method would be the waisted space at the end of each line >[ required to fall on 256 byte offsets ] and interrupt overhead. > Comments ??? If I understand you correctly, you want to change the current value of the display position counter on the fly in the HBI, well this is a very neat idea I had about two years ago , if possible it would allow some really nice effects like overlaying screens etc.. So what about writing to Atari and ask them to make the register writable in the next revision of the ST................ (BTW if you where thinking about actually copying the scanlines, a simple calculation shows (for mono screen): 1 Scanline = 80 Bytes = 20 Longs 1 move.l ~ 20 Cycles ~ 2 uS 20 * 2 uS = 40 uS (Time to copy a scanline) 400 * 40 uS = 16'000 uS = 16 mS (Total time used in one vertical scan) 70 * 16 mS = 1120 mS = 1.1 S (Total time used for 70 screen refreshes) and as you know 1.1s > 1s........) -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------
unpowell@csvax.liv.ac.uk (05/03/88)
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 ********************************************************************************
darin_wayrynen@pedro.UUCP (Darin Wayrynen) (05/09/88)
<1794@brahma.cs.hw.ac.uk> The fast screen text IO used in Tempus, Laser C, and the PD file lister called ASL all use the same basic technique for displaying text. They move the font information to the screen themselves using move.b (a1),(a2) instructions ( different registers of course, and a bit different semantics), and clear the screen using move.l's. If anyone is interested in Laser C source code and/or demos of screen IO faster than Tempus please contact me at my bbs: Think Tank BBS (602) 435-9645 between the hours of 9pm to 9am. Demos will be gladly given away, and source code will have to be discussed. Anyone who wanted to spend the time to write the routines to do it, could. I just don't want to release all of it and get nothing for my time. features... assembly/C mismash tweaked beyond belief... multiple (as many as you want) dega's 8 bit fonts on the same screen, changeable on the fly. Set up for TOS programs with variable number of lines saved at top of screen for a non-scrolling region. Can be used in GEM windows, but must do your own clipping of text before printing it. Speed of 33k buad (3,300 characters/second) with scrolling, and 134K baud (113,400 characters/second) without scrolling. Full screen of text in about 1/7th of a second. Darin