[ Back to Main ]
1.) The Hardware Scrolling
--------------------------
The Registers:
Video Base Address: ST STE
$FFFF8201 0 0 X X X X X X High Byte yes yes
$FFFF8203 X X X X X X X X Mid Byte yes yes
$FFFF820D X X X X X X X 0 Low Byte no yes
The first two registers are identical with those of the ST and
can be read and written to. The last one (low byte) did not
exist on the ST. While on the ST this meant that a Video Base
address had to be even on a 256-byte basis (lowbyte was
assumed #$00 then), on the STE it only has to be even since
bit 0 is automatically assumed #0.
Video Address Counter:
$FFFF8205 0 0 X X X X X X High Byte ro rw
$FFFF8207 X X X X X X X X Mid Byte ro rw
$FFFF8209 X X X X X X X 0 Low Byte ro rw
This set of registers already existed on the ST but could not
be written to. The Shifter uses this actually for counting
through the whole screen it is building up. Write access
has of course immediate effect.
Line-Offset Register
$FFFF820F X X X X X X X X X no yes
This register contains the value how many WORDS (not BYTES!)
the Shifter is supposed to skip after each Rasterline. This
register enables virtual screens that are (horizontally)
larger than the displayed screen by making the Shifter skip
the set number of words when a line has been drawn on screen.
Video Base Address Pixel Offset
$FFFF8265 0 0 0 0 X X X X no yes
This register allows to skip from a single to 15 pixels at
the start of each rasterline to allow horizontal fine-
scrolling.
The registers are easy to understand. So why didn't it work ?
? Writing to the Video Base Address registers seems to have no direct
affect on the screen contents.
! No. These registers only contain the "reset" value for the Shifter
after a whole screen has been drawn. It does not affect the current
screen, but the one for the next VBL. To make immediate changes on
the screen, use the Video Address Counter.
? There's only junk on the screen. It looks like the STE reads the
screen content from a totally wrong address.
! For compatibility reasons, the low-byte of the Video Base Address
is ALWAYS set to 0 when the mid- or high-byte of the Video Base
Address are set. This is easy to understand, seeing that the ST
did not have this register - hence ST software that never sets
the low-byte might have problems setting the correct Video Base
Address. The solution on the STE is simple: Always set the
Low-Byte last. First set High and Mid-Byte (in no special order),
then do the low-byte.
? Scrolling in 16-pixels blocks works, but fine-scrolling totally
screws up the screen contents.
! The Line Offset Register is very critical. Make sure it contains the
correct value at any time. If the Pixel Offset Register contains a
zero, the Line Offset Register contains the exact number of words
to skip after each line. But if you set the Pixel Offset Register to
"X", the Shifter will still display 320 (640) pixels a line and
therefore has to read "X" pixels from the NEXT word which it would
have skipped if the Pixel offset Register contained a "0".
Hence, for any Pixel Offset Value > 0, please note that the Shifter
has to read (a few bits) more each rasterline and these bits
must NOT be skipped using the Line Offset Register.
? Tried. Screen content is still screwed up.
! Please also note that in Low-Resolution (4 Bitplanes), the Video-
Shifter reads 4 words at once. In Low-Res, the Line Offset therefore
always has to be a multiple of 4, otherwise the Shifter will not
display the bitplanes correctly next rasterline.
? In Hires (Monochrome 640x400), my scrolling does not work on the
Falcon
! On the STE, the Video Base Address only has to be a multiple of 2
since bit 0 is always "0". On the Falcon, the least significant 2
bits of the Base Address are "0", hence, on the Falcon, you can
horizontally scroll a minimum of 2 words, which, in monochrome
mode, is not sufficient for fine-scrolling.
There is no way to do horizontal-fine scrolling on the Falcon in
a monochrome mode. Midres (640x200 2 bitplanes) will already
work since every address has to be a multiple of 4 then.
? Gah! On the TT neither hires nor midres works.
! It's even worse on the TT since the TT-Shifter lacks the 3 least
significant bits of the Video Base Address, hence all Video Base
Addresses have to be a multiple of 8. In hi- and midres however,
any "sound" Base Address is a multiple of 2 or 4.
There is no way to horizontally fine-scroll on the TT in these
resolutions.
? It scrolls, but the screen-content seems to jump sometimes.
! The Atari STE shifter has a slight timing problem regarding the
Pixel Skip Register. Whenever this register "jumps" from a value
>"0" to "0", the STE might display the wrong screen address.
This is a known problem and Atari affirms it.
Atari officially suggests to NOT set the Pixel Skip register in
the VBL as this causes the problem. Since changes on this
register has immediate effect, Atari suggests to use a HBL
routine that sets all registers connected to Video hardware
not in the VBL but in (for example) a HBL interrupt after the
VBL.
? On the Falcon and TT, fine-scrolling seems to work without
the jumping in low-res, even when the registers are set in the
VBL-interrupt.
! Affirmed. Both TT and Falcon do not suffer "visibly" from this
bug. However, in case there are other bus-timing critical jobs
running (like MOD-replay routines or heavily loaded interupt
routines that occur more often than the VBL), this bug MIGHT
become visible as well. Besides, if you are coding Falcon or
TT for STE compatibility, you should follow Atari's suggestion
and not use VBL to set the registers.
You will learn later on that the STE behaves very very critical
to anything done in the VBL anyway.
? I tried to write a screen splitting routine that changes a lot
of Video-related parameters after a certain rasterline. But it
is highly fragile and does not work very well.
! The STE with an 8 MHz CPU is not very fast and timing becomes
critical when trying to change Video-registers on the fly
during the screen build-up. There is no general solution for
this, just that you should, during screen build-up, never
change too many registers or at least not in a way that it
costs too much time. If you do need to change many registers,
make a table with all the values long before they are used
(for example in the VBL) and try to write these values as
quickly as possible.
Sometimes, an empty line in exactly that HBL you change all
the registers, can help a lot.
? I use "widescreen" on an RGB monitor on the Falcon, meaning a
25 MHz video clock (instead of the 32 MHz clock which is standard
for RGB). My screen-splitting routine flickers a lot. Why ?
! On RGB, using a 25 MHz video clock to create wide-screen effects
usually eliminates either the whole or at least a lot of the
so-called "border", the area where only the background colour is
being displayed. This border-region however is the time between
rasterlines where the video-chip does not access the memory and
also does not send any data besides the background colour which
is internally latched. Eliminating the border will make the video-
chip transmit data (more or less) non-stop and therefore leave
hardly any time for the CPU to "invisibly" change screen counter
registers. This will cause instability on the first few pixels
of each line.
Using a 32 MHz video clock will totally eliminate this effect,
however, it will not mean wide-screen anymore.
? My Falcon is modified and has a 36 MHz video clock instead of
the 32 MHz video clock. Now what do i do ?
! Unfortunately, a 36 MHz video clock is totally non-standard and
not a sensible modification at all since it will eliminate
compatibility to any kind of software using a 32 MHz video clock,
which is standard for RGB monitors and TV sets.
A Falcon with a 36 MHz video clock will have a general
compatibility problem to RGB monitors anyway so it will not be
discussed any further here.
? So now i fixed it and it works fine on the STE, but often enough,
bitplanes are screwed up on the Falcon. Why ?
! Remember that the Falcon only allows screen addresses as multiples
of 4, which is not as flexible as on the STE, where it only has to
be a multiple of 2. This is also the case for the Video Counter
Registers, not only for the Video Base Address.
Make sure that your screen data is stored on an address that is
a multiple of 4 and it will work.
[ Back to Main ]
[ Onto next Chapter ]
|
