From: neil@cs.hw.ac.uk (Neil Forsyth)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Is page flipping safe, and I need to know about syncing
Date: 30 Jul 92 15:10:57 GMT
Organization: Dept of Computer Science, Heriot-Watt University, Scotland

In article <1992Jul23.222019.27222@infoserver.th-darmstadt.de> 
wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
>In article <1992Jul23.184657.5699@wam.umd.edu> dmb@wam.umd.edu
(David M. Baggett) writes:
>>The Setscreen and Vsync (X)Bios calls work fine for double buffering
>>(aka "page flipping").  There are some subtleties but for most
>>practical purposes you'll get good results using these calls and your
>>code will work with all versions of TOS (including, in theory, those
>For most practical purposes you do get good results with this.
>
>BUT: the disadvantage is that you don't have precision page flipping. It 
>just may happen that on screen1 you are done drawing in 2 screens and flip 
>then, while on screen2 you need 3 screens. The net effect of that would
>be that if your flip rate is 4 that screen 1 will be displayed 5 VBIs, where 
>screen2 will be displayed only for 3 VBIs. If your game nears completion
>and you are not 100% satisfied with the animation I'd suggest that you
>use the VBL directly to flip pages (you can use Setscreen()) there too.
>Until then Setscreen() + Vsync() + frclock will suffice.

The trick is to set the physical screen base before the last frame that you
are waiting for. ie. If you are running at 3 frames per turn then set the
new screen address when you reach a count of two (which means the current
screen is being displayed for a third time) so that it takes effect at the
end of frame three. "Why?" I hear you ask (or maybe I don't:-).
Well if you set the physical screen base the SHIFTER chip will not use that
address until it finishes scanning the current screen. However this happens
before SHIFTER causes the vertical blank interrupt so if you change the
screen address in a VBL interrupt then you are too late.

You want more proof? Take a look at the system variable 'screenpt' ($45E).
The system VBL routine copies this to the physical screenbase if it's non-zero
but foolishly neglects to zero it afterwards. You might think that this is
the variable that Setscreen sets. Nope. Setscreen blasts the hardware itself
and ignores screenpt. In fact TOS *NEVER* writes to screenpt. If you do
then your in trouble because that means that the screen address is getting
changed to screenpt every VBL thereafter EVEN after a soft reset. Can you
imagine coming up with a 4MB machine in which the video RAM is at a low
address in memory belonging to no-one. Why did Atari do this? Because they
originally thought that screenpt/VBL would be the way to ensure a clean
screen change but in the end the video hardware took care of it and the
method became redundant/unworkable. However there are dark grey clouds on the
horizon regarding this issue ...

+----------------------------------------------------------------------------+
! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
!                                                                            !
! 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, UK           "That was never 5 minutes!"              !
+----------------------------------------------------------------------------+