Article 21816 of comp.sys.atari.st: Path: mucs!ukc!mcsun!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!vaxb.york.ac.UK!SOCS18 From: SOCS18@vaxb.york.ac.UK (Vision Newspapers) Newsgroups: comp.sys.atari.st Subject: STE display hardware Message-ID: <9003050806.AA15885@ucbvax.Berkeley.EDU> Date: 5 Mar 90 00:14:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 82 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 * ***********************************************************************