This document hopefully explains the problem we have with the programmed
beamsync modes:


Outline of the problem:

Under V37, and with ECS, a Multiscan monitor was created to resemble as closely
as possible a VGA-type of display.  This monitor was designed in order to
operate at the standard VGA frequency of 31.5kHz horizontal, and 60Hz vertical.

The number of colour clocks for that monitor was set to 0x71. This gave the
horizontal refresh of 31.5kHz, and allowed 640 horizontal pixels with
smooth scrolling.

With the AA chip set however, to operate at the chip's full potential, and to
provide up to 8 bitplanes, the fetch cycle of this mode of operation has
increased from a 2-cycle on ECS to an 8-cycle on AA. Under ECS, the Multiscan
monitor was set up so that an early fetch of bitplane data was not needed, and
that DDFSTRT would always be set for colour clock 0x18, which leaves enough DMA
to fetch sprite 0 only. But in the 8 cycle mode, an early fetch is needed. This
would involve setting DDFSTRT to 0x10, which would involve losing the DMA cycles
of Audio channels 2 and 3, and sprite 0. Losing sprite 0 is a definite no-no for
software, as the system uses sprite 0 for the pointer.

Consequence:

As a result of this, the graphics OS will not set DDFSTRT to 0x10, even when it
is required for horizontal scrolling. Because the bitplane data that is needed
is not being fetched, this results in Lisa displaying colour 0 instead of the
image on the far left hand side. Up to 64 pixels of image are lost, and this
number decreases as the screen is dragged further. At this resolution, 64 pixels
is 10% of the total line.

Solution:

1)
The ultimate solution would be to fix the chips. However, this would require a
redesign of Alice's bitplane fetch engine, which is being addressed in the AA+
chip set, but would be too complicated for the current AA chips.

Therefore, software has to find a workaround.

2)
The workaround that is currently implemented is to add 8 colour clocks to the
size of each line, and move the whole image over by 8 colour clocks. This means
when the chips need to prefetch the data for smooth scrolling, the value of
DDFSTRT can be dropped from 0x20 to 0x18, which is legal, and so all the image
is visible. Unfortunately, adding these colour clocks takes the horizontal
frequency out of the range of industry-standard VGA specs. Also, the overscan
range of the monitor is reduced from its ECS values.

For those people using a VGA-only monitor that requires true VGA timing, there
is a s/w fix to tell graphics not to add the 8 colour clocks. These people will
then have to live with the fact that when they horizontally drag the screen,
they will lose pixels.

3)
Disable smooth scrolling for these modes. This would involve either disabling
dragging completely for these modes, or implementing some form of coarse
scrolling where the screen would move 64 pixels at a time instead of 1 pixel at
a time. This could cause a number of problems, mainly for software that is
expecting smooth scrolling behaviour. Also remember that a multiscan-type
monitor called DblNTSC (and DblPAL) would also have the same behaviour, and this
monitor was designed to be as good-as-possible a software solution for the
display enhancer circuitry, which scan-doubles NTSC and PAL screens.

4)
Still to be investigated is an option of dynamically changing the horizontal
timing. This would involve having a true VGA line, but when graphics needs its
prefetch, it would then add 8 colour clocks to the line. It would then drop the
extra colour clocks when they are not needed. Again, a VGAOnly monitor would
disable this feature.


Note:
With the normal NTSC and PAL (15kHz) modes, a similar problem exists in the 16
and 32 cycles (ie Hires4x, Lores2x and Lores4x). In these cases, software drops
the bandwidth when needed to hide the problem. We cannot use this trick for the
31kHz modes as an 8 bitplane Multiscan modes needs 4x bandwidth; if we drop the
bandwidth, then we will also lose bitplanes.

Timings (approximations)

Without fix 2):		Horizontal 			Vertical
Multiscan		31.5kHz				60Hz
Euro72			31.5kHz				70Hz
DblNTSC			29.9kHz				60Hz
DblPAL			29.22kHz			50Hz
*Super72		24.62kHz			72Hz

With fix 2):		Horizontal 			Vertical
Multiscan		29.29kHz			58Hz
Euro72			29.25kHz			69Hz
DblNTSC			27.66kHz			58Hz
DblPAL			27.50kHz			48Hz
*Super72		23.32kHz			72Hz
(*Super72 requires a Multisync monitor)


Modes that will work at 31.5kHz (using VGAOnly), but cannot be scrolled without
artifacts. These are the modes that can be chosen from the prefs Screenmode
requester, so HAM, EHB etc are not listed:
MULTISCAN:Productivity
MULTISCAN:Productivity Laced
EURO72:Productivity
EURO72:ProductivityLaced
DBLNTSC:High Res
DBLNTSC:High Res Laced
DBLNTSC:High Res No Flicker
DBLNTSC:Low Res
DBLNTSC:Low Res Laced
DBLNTSC:Low Res No Flicker
DBLPAL:High Res
DBLPAL:High Res Laced
DBLPAL:High Res No Flicker
DBLPAL:Low Res
DBLPAL:Low Res Laced
DBLPAL:Low Res No Flicker

