sdh@thumper.UUCP (02/13/87)
Just a simple point, that it is fact very easy to do scrolling
for a hires character generator that is just as fast as normal
test scrolling. The way to do this is to write a program that
builds a scroll routine. The end result is a program that
would look something like this:
LDY #$00
label LDA ${the address of the 8th line of video},Y
STA $2000,Y {the first line of video}
LDA ${the 9th line},Y
STA $2400,Y
.
.
.
INY
CPY #$28
BNE label1
RTS
label1 JMP label
This just does huge amounts of raw moving, and will scroll the screen
tremendously fast (compared with the normal way of scrolling.
This does not allow windowing, though. That can be added into code of
this sort, but it slows it down.
Also, this technique extended to the text screen gives phenomenal
scrolling there too. You never new the screen could go by so fast.
Retief of the CDT
(ucbvax, decvax, ihnp4)!bellcore!sdhlc@pbhyd.UUCP (02/19/87)
In article <394@thumper.UUCP> sdh@thumper.UUCP (Retief of the CDT) writes: > >Just a simple point, that it is fact very easy to do scrolling >for a hires character generator that is just as fast as normal >test scrolling. The way to do this is to write a program that >builds a scroll routine. I presume the author of the above meant to say hi-res screens could be made to scroll as fast as *text* screens. Not hardly. Each line of text on a text screen requires one line of screen memory (40 bytes). Each 'text' line on a hi-res screen requires 8 lines of screen memory (320 bytes). Since a memory move routine does not care what memory is being moved, it should be obvious that the best a hi-res scroll can do is 8 times slower than text scroll. Some other factors will impact this (80 column text, use of look up tables instead of bascalc, etc) but in no case will hi-res scrolling ever be as fast as text screen scrolling.
sdh@thumper.UUCP (02/20/87)
In article <836@pbhyd.UUCP>, lc@pbhyd.UUCP (Larry Colton) writes: > In article <394@thumper.UUCP> sdh@thumper.UUCP (Retief of the CDT) writes: > > > >Just a simple point, that it is fact very easy to do scrolling > >for a hires character generator that is just as fast as normal > >test scrolling. The way to do this is to write a program that > >builds a scroll routine. > > I presume the author of the above meant to say hi-res screens > could be made to scroll as fast as *text* screens. Not hardly. > Each line of text on a text screen requires one line of screen > memory (40 bytes). Each 'text' line on a hi-res screen requires 8 > lines of screen memory (320 bytes). Since a memory move routine does > not care what memory is being moved, it should be obvious that the > best a hi-res scroll can do is 8 times slower than text scroll. > > Some other factors will impact this (80 column text, use of look > up tables instead of bascalc, etc) but in no case will hi-res > scrolling ever be as fast as text screen scrolling. If you looked at my code, you will notice that it uses NEITHER bascalc NOR lookup tables. This will make the screen scroll just as fast as the text screen using apple's bascalc routine in ROM. Excuse me for not putting this comparison in. Obviously, if you have 8 times as much data to move it will take 8 times as long, BUT ONLY IF YOU USE THE SAME ALGORITHM. If you look at the routines in ROM, they use bascalc routines for every line. This is an extremely slow technique, but makes windowing pretty easy. Try the following exercise: rewrite the character i/o routines for the machine (not too hard, they're just hooked by soft pointers at $36-39), so that you use the same algorithm I present for HIRES scrolling for text. You will be shocked by the increase in speed. In fact, you won't even be able to follow the text that's going off the screen. To scroll a line of HIRES text, it would take 8*40*6 cycles, 1920 cycles. That's 3 for a load, 3 for a store times 40 bytes/lines times 8 lines. Since it is in a loop an will involve one branch (always successful), and a jump, thats 40*8 (successful branch not over a page boundry = 2 + unconditional branch (JMP) = 6). Total 2240 cycles. For scrolling one line of text, 2 bascalc calculations (don't know what these cost, but they are VERY expensive) + 40 * 10 cyclyes = 400 cycles (that's 40 bytes/line * 5 cycles for zero-page indirect indexed addressing read and write) plus the looping, which will be rougly the same as for the above, = 720 cycles, plus the overhead for 2 bascalc calculations. Is it unreasonable to assume that 1 calculation takes 500-700 cycles? They are pretty hairy after all. At any rate the overall difference will be not more than 200-400 cuycles. That's is very little considering the sheer amount of data being moved. Exactly the same speed? No. Close enough that you wouldn't be able to tell the difference by watching. Not to mention that the scrolling routines for handling windowing require a great deal of overhead, while the only over head in my scrolling would by LDY #$00 for initialization. 3 cycles. The tradeoff: the routine takes up 1.25K of memory, and while it could allow windowing, it would slow it down *significantly*, fortunately, windowing is not used that often. Yours sincerely, Retief of the CDT (decvax, ucbvac, ihnp4)!bellcore!sdh
cimbura@srcsip.UUCP (03/06/87)
in article <836@pbhyd.UUCP>, lc@pbhyd.UUCP (Larry Colton) says: > > In article <394@thumper.UUCP> sdh@thumper.UUCP (Retief of the CDT) writes: >> >>Just a simple point, that it is fact very easy to do scrolling >>for a hires character generator that is just as fast as normal >>test scrolling. The way to do this is to write a program that >>builds a scroll routine. > > I presume the author of the above meant to say hi-res screens > could be made to scroll as fast as *text* screens. Not hardly. > Each line of text on a text screen requires one line of screen > memory (40 bytes). Each 'text' line on a hi-res screen requires 8 > lines of screen memory (320 bytes). Since a memory move routine does > not care what memory is being moved, it should be obvious that the > best a hi-res scroll can do is 8 times slower than text scroll. > > Some other factors will impact this (80 column text, use of look > up tables instead of bascalc, etc) but in no case will hi-res > scrolling ever be as fast as text screen scrolling. It may not ever be as fast as normal text scrolling but it can approach great speed through the method indicated (building a scroll routine.) The trade off is program memory space for speed. The routine would do direct memory moving which is much faster than any calculations or even using look up tables can approach. Although this is not really practical for an entire screen it may be done on a small portion of the screen easily if speed is really a problem. A program segment might look something like this... ldx #0 loop: lda $2000,x sta $2010,x ... (many more loads and stores)... inx cpx #40 bcc loop Well anyways. See ya. -- Tim Cimbura {ihnp4,philabs,umn-cs,mmm}!srcsip!cimbura Honeywell S&RC, Signal and Image Processing MN65-2300 Artificial Intelligence Technology 3660 Technology Drive Minneapolis, MN 55413 (612) 782-7537