STE documentation

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 sincebit 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 registers "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 have 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.

? 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 Registerts, 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.

? My screen splitting routine now works fine on the STE and on the Falcon, but not on the TT.

! On the TT, it's even worse and each Video Base Address has to be a multiple of 8. According to Ray/tSCc, the TT allows write access to the Video Counter - in contrast to what some books say. However, officially, the TT does not allow to change video address on the fly by writing to the address counter.

<Previous> [1][2][3][4][5][6] <Next>