Date   : Fri, 09 Dec 1994 14:03:34 +0000
From   : lamcw <lamcw@...>
Subject: Re: Screen updates on Changes

Dave Barnett wrote:

;The overhead is very small.  Suppose the screen is divided into a 4*4 or
;8*8 Grid (or even into a number of horizontal bands).  A screen write would
;mark the region on the changed list.

Okay, this means we need to trap any opcodes which alters beeb's vram.
Off the top of my head these will include STA, STX, STY, ASL, LSR, ROL, ROR
and maybe a few others. Say we divide the screen up into a 2 x 2 grid. We
need to work out the start of vram, subtract that from &8000 and then work
out the address boundries. So for each of the opcodes above, we need to include
4 IFs, i.e.

 if ( (addr<=start1) && (addr>end1) ) mark1=1; 
 if ( (addr<=start2) && (addr>end2) ) mark2=1; 
 if ( (addr<=start3) && (addr>end3) ) mark3=1; 
 if ( (addr<=start4) && (addr>end4) ) mark4=1; 


or something similar. We can't even divide the screen properly into a 2 x 2
grid (can you imagine trying to work out if an address fell into the top
right hand corner of the visible screen? ) but rather into 4 horizontal regions.
I need hardly mention the erosion of performance caused by including the 
above IF statements into such common opcodes as STA/X/Y.

Now, let's for the sake of argument, say we've worked out that only the
top left corner and bottom right corner have been updated. Now my guess is
that TWO calls to Mac's COPYBITS routine would taken longer than just one
call to dump the whole screen. PC programmers usually access their vram
directly, so yes, there could be some mark up in performance. 


;Even just marking the whole screen as changed (i.e. one region only) would
;save significant time because there are many programs don't touch the
;screen for long periods.

Well, fair enough if you're running CPU intensive programs which don't
output much. Perhaps an option to only update the screen when
a special key is pressed would fit the bill.


Chris Lam.