News Team Current issue History Online Support Download Forum @Pouet

01 - 02 - SE - 03 - 04 - 05 - 06 - 07 - 08 - 09 - 10 - 11 - 12 - 13 - 14

Alive 6
[ 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-

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
! 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

? 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

? On the Falcon and TT, fine-scrolling seems to work without
  the jumping in low-res, even when the registers are set in the
! 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 ]

Alive 6