Path: utzoo!attcan!uunet!snorkelwacker!think!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!hyc
From: hyc@math.lsa.umich.edu (Howard Chu)
Newsgroups: comp.sys.atari.st
Subject: Re: MIXED
Message-ID: <10636@stag.math.lsa.umich.edu>
Date: 12 Jan 90 19:24:12 GMT
References: <9001050802.AA10246@ucbvax.Berkeley.EDU> <10616@stag.math.lsa.umich.edu> <5929@umd5.umd.edu> <32896@iuvax.cs.indiana.edu>
Sender: news@math.lsa.umich.edu
Reply-To: hyc@math.lsa.umich.edu (Howard Chu)
Organization: University of Michigan Math Dept., Ann Arbor
Lines: 50
UUCP-Path: {mailrus,umix}!um-math!hyc

In article <32896@iuvax.cs.indiana.edu> pwp@iuvax.cs.indiana.edu (Paul Purdom) writes:
>Could someone say briefly what techniques the overscan software uses to do
>overscanning?

The hardware change is to cut the normal display enable signal (between
GLUE and Shifter) and replace it with the composite sync signal. This
allows you to actually display bits during the longer display enable cycle.
The overscan software changes the physbase and logbase, among other things,
to accomodate the larger display area. Unfortunately it's a little memory
hungry with an SM124. Since the signal the ST is spitting out is now at a
slightly greater bandwidth than the SM124 can accomodate, the effect is that
the "top left corner" of screen memory cannot be displayed properly. The
fix the overscan software uses is to add an offset between physbase and 
logbase. This pushes the region of memory that the ST actually draws on
into a space that the SM124 can actually display.

This causes problems for a lot of programs that do page flipping for
screen drawing, animation, etc. They're typically set up to grab the
value of physbase, malloc a 32K chunk for their alternate buffer, and
toggle things in, swapping their original physbase and their new buffer
in for logbase as they please. This makes for a lot of screen garbage
when using overscan. [The original assumption, which is true on an
unmodifed ST, is that physbase == logbase. WIth overscan, logbase >= physbase
in order to position the screen appropriately. Thus, you can't swap them
around at will, you have to remember the original values, etc.]

I'm pretty sure the same sort of thing happens in color, but I haven't
played with it as much. Fixing Uniterm required searching for every hardwired
constant "24", "80", "132", "32000", etc., replacing them with appropriately
calculated variables, rewriting the code that manipulates the screen memory,
and finding weird little bugs caused by adding signed short integers to
long addresses. [That last is No Fun.]

I suspect that more programs will be incompatible than not. Another pitfall
is programs that use the Line-A screen width variable analogously with the
horizontal resolution variable. [On a plain ST, the screen width is 80 bytes,
in monochrome you get 640 pixels. No problem, 8 pixels per byte. With
overscan, you need 100 bytes per line, but you won't see 800 pixels on an
SM124. You could with a multisync monitor, but not otherwise. So, you need
to be careful, and some programs don't seem to take things into account
very well.] This all seems quite tedious, since programs are supposed to
let GEM worry about the nitty-gritty details of exact screen size. Some do,
and they work fine. Unix Windows is a slick example of one that does. Others
run into problems...

Gee, this turned out a lot longer than I'd planned. Anyway, I'm rambling now,
so I'll shut up.
--
 -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1]
 and You Too can have a Personal Electronic Relationship with God!