Atari STE display hardware
OK folks, it's STE programming time again...
Data from "Atari STE Developer Information Addendum", addresses in hex, sizes in bits (in table)
Video Harware Modifications
===========================
Addr Access Size Use
====== ====== ==== =================================================
FF8204 R/W 6 Video address counter (high)
FF8206 R/W 8 Video address counter (middle)
FF8208 R/W 8 Video address counter (low)
The change here is that these registers are now
read and write, allowing the programmer to
update the video refresh address to any word
boundary _at any time_.
FF820C R/W 8 Video base address (low) (VBASELO) This register
didn't exist on the ST, but on the STE it allows
the positioning of the screen base address on
any _WORD_ boundary
FF820E ?? 8 Line offset (LINEWID) - the number of extra words
added to the address counter at the end of each
line, _MINUS ONE DATA FETCH_. This allows for
virtual screens that are wider than the actual
screen display. Clearing this register means the
STE acts like an ordinary ST.
FF8240 to FF825E Colour palette
There are now four bits for each of the red,
green and blue components. To give backward
compatibility with the ST, the least significant
bit is above the most significant bit. Thus the
register layout is as follows:
xxxx 0321 0321 0321; x=don't care
RED GRN BLUE
FF8264 ?? 4 Horizontal bit-wise scroll (HSCROLL). Allows the
start of each line to be delayed by 0-15 bits,
thus giving instant horizontal scrolling.
Horizontal fine scrolling isn't quite as trivial as it looks. The pixel offset is loaded into HSCROLL, and the documentation then says the following about the LINEWID register :
"If you are actively scrolling (HSCROLL<>0), this register should contain the additional width of the display line _minus one data fetch_ (in low resolution one data fetch would be four words, one word for monchrome etc.)"
The reason for the extra data fetch becomes clearer if you think about what is actually happening. If you fine scroll by n bits, then n bits are effectively missed off the left hand edge of the screen. But to get a complete line of pixels, n bits must be added to the right hand side of the screen. This constitues one extra data fetch for the display processor beyond the usual requirement.
For example, if you had three low resolution pictures side by side in memory, and you wanted to scroll across them, you would set LINEWID to 160 when HSCROLL=0 (no extra data fetch). When HSCROLL<>0, LINEWID would be set to 156 (four less due to the extra data fetch done automatically by the display processor).
Vertical scrolling is trivial - simply set the video address base to the required address at horizontal blanking time.
That's all folks - for now - more info on the new controller ports soon.
Regards,
Mathew Lodge
***********************************************************************
* c/o Dept. Computer Science * "Baldrick, fetch me a turkey _so *
* University of York * big_, you'd have thought its mother *
* Heslington * had been rodgered by an Omnibus" *
* York, UK * *
* YO1 5DD * JANET : SOCS18@uk.ac.york.vaxa *
***********************************************************************
