Date   : Tue, 30 Aug 1994 16:48:46 WET DST
From   : Bonfield James <jkb@...>
Subject: Re: NOTHING ELSE WORKS...!!!!

Rycharde writes:

[Revs]

>It rolls its sleeves up and plays with the video timings on the fly to get
>the split screen.  The thought of emulating that boggles my mind.  I 
>think Acorn User once did an article (and source code, of course) on
>the technique.

Firstly, to whoever it was who spoke about scrolling the screen - does Revs
really do this? I can see no reason to.

Secondly, the split screen modes are quite simple to understand (but maybe not
to emulate). For a nice test try Sphere of Destiny, which varied its "splits"
(colour switches mainly here) constantly to generate the scrolling effect!

The usual technique employed is to setup the 6522 timers to generate an
interrupt after a predetermined amount of time. This time corresponds to how
long the raster takes to travel from the frame flyback to a particular point.
It's sometimes a bit inaccurate which is why you often see slight flickering.
I guess the approach would be to trap the video sync interrupt; switch to mode
X; update the timer value to our specific pause; process your usual code until
a timer interrupt occurs; switch to mode Y.

What this boils down to is knowing when to draw a line of graphics. A simple
way I can see is to have a continuous interrupt that occurs at each line of
drawn screen. This implies 256*50 interrupts per second - quite a few.
A more sophisticated technique only interrupts when we actually know we're
going to do something special. Such a system may be along the following lines:

1) 'Interrupt' 50 times a second to draw a screen.

2) Whenever we receive any other interrupt, first update as much of the screen
   as will have been scanned since the last refresh.

This has the drawback that mode switching timings done purely in CPU loops
won't work. However this is all a theoretical case as no one ever uses such a
dumb method (as far as I'm aware). The above doesn't actually appear to be
much harder at all than any normal graphics drawing system.

This typically will only cause the screen update code to be called a couple
hundred times a second at most, instead of the 'simple' line by line system
which has tens of thousands of calls per second. This is how I plan to
implement things. I'll update you of progress; once I start rewriting my
existing graphics code that is...

       James