From: neil@cs.hw.ac.uk (Neil Forsyth)
Newsgroups: comp.sys.atari.st.tech
Subject: Falcon Video Hardware Bug
Date: 11 Jan 93 15:05:08 GMT
Organization: Dept of Computing & Electrical Engineering, Heriot-Watt University, Scotland


Last year, during a discussion about screen handling, I wanted to point out
a major difference between the Falcon and ST video hardware but at that time
the Falcon was unreleased and the NDA was binding. However a friend of mine
(Hi Kevin! :-) received his production Falcon recently and it has the same
problem that my pre-production unit has.

Now for the explanation ...

The video hardware in the ST, STE, MegaSTE and TT will not implement a change
of video address (@ $FFFF8201,3 and D on the STE) until the vertical blank
occurs but before it generates the interrupt. This means that if you were
writing a game that used screen double buffering and say each game turn took a
maximum of three frames, you MUST set the new screen address during the third
frame, NOT afterwards during a vertical blank routine. This we already knew.

However the new video hardware on the Falcon will implement a new screen
address at any time that it is not accessing video RAM. This is usually in the
margins at the top and bottom of the screen. This means that programs should
change the address during a vertical blank routine to avoid writing to a
screen that the video hardware is currently displaying. This usually means
ripples and shudders in the images since you see both old and new data at
some points of the screen.

Please take this into account when writing any new graphics programs so that
we can eliminate this problem and maintain compatibility across the entire
range of Atari computers. This was the only incompatibility I found between
the Falcon and Game Workbench.

To identify a Falcon look in the Cookie Jar for the machine cookie (_MCH).
The Cookie Jar pointer is at $5A0 an it points to a list of longwords
(cookie, value) the details of which I won't go into at the moment.

Possible values for _MCH are:-

	$0000xxxx - ST, STF, STFM
	$0001xxxx - STE (Note: In a Mega STE, xxxx will be non-zero)
	$0002xxxx - TT
	$0003xxxx - Falcon

As an alternative you could look at the video cookie (_VDO) which is $0003xxxx
on the Falcon.

How to view the phenomenon for yourself:-
I first noticed the problem when I ran a program that allowed me to have lots
of bouncing sprites on the screen. As the workload moved the screen change
to the point where the video RAM was already been scanned I noticed a shudder
in the sprite movement. Due to the varying workload in drawing a
non-preshifted image as it moves across the screen sometimes the change
happened before screen scanning started and sometimes afterwards.
Smooth movement only happens when the change of screen address is consistantly
before or after the margin.

Not long after I received my pre-production Falcon, I informed Atari UK of the
problem but received no feedback which is a pity because unlike other
incompatibilities with the ST which are not Atari's fault this one certainly
is. As far as I know, no developers have been informed of this.

+----------------------------------------------------------------------------+
! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
! Neil Forsyth                                                               !
! Department of Computing and Electrical Engineering                         !
! Heriot-Watt University                                                     !
! Edinburgh, Scotland                                                        !
! United Kingdom            Email: neil@uk.ac.hw.cs, ..!ukc!cs.hw.ac.uk!neil !
! "'Have you got any?' he asked, expecting the answer no" - Monty Python     !
+----------------------------------------------------------------------------+