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 9
Overscan Techniques

This is  part one  of a  three part  article. This version has been   translated
by Frost/Sector One and has also passed the eyes of STS to smoothen it a bit. It
was originaly published in the French "ST  Magazine", issue  51 and  52   (april
-may-june  1991). The  article is written by Alien of ST Connexion (also   known
as Sengan Short / Dr Sengan  Baring  -Gould).  13 years and  one PhD later,   We
managed to  get into   contact with  him ...  in  Western  China (!). Now   that
he's back home in  Colorado,   he's revised our   translation.  The   article's
original  title  was   "Les  techniques  de l'Overscan", "Overscan Techniques".

Please note that this article was written  mainly about the ST, not the STE.  I,
Alien, had  very little  access to  STEs: I  borrowed one  for an evening, and I
tried a few things out at  the local electronics supermarket before they  kicked
me off to demonstrate it to a customer.

Part One

In this article, we  will try to explain  to you everything about  the technique
known as "Overscan". We decided to publish this article because many people  use
Overscan without  understanding how  it works:  indeed it  is necessary  to have
discovered its mechanism to know how it works. This article is the result of one
year of painstaking research, and is explained at the hardware level. 

First, what is Overscan ? Also  known as "No Border Screen" or  "FullScreen", it
is a screen from which one  has removed the borders.  Before explaining  how one
performs such magic, it is useful to recall how a colour picture is displayed on
a monitor.

Picture Display Format

A picture is displayed 50 times a second in 50Hz mode (or 60 times in 60Hz). The
ST generates 313 lines per picture at  50Hz (263 at 60Hz). In theory, it  should
generate 312.5 lines, (obtained by  successively displaying 312 and 313  lines).
It therefore assumes  the monitor can  tolerate displaying a  picture at 49,92Hz
instead of 50Hz. This also explains why the ST cannot have a real interlace mode
such as that of  the Amiga. Each line  takes a constant time  to be transmitted:
otherwise the  picture would  be distorted.  This time  is calculated  using the
following formula:

(Number of pictures per second * number of lines per picture)

For "Number of pictures per second"=50 and "Number of lines per  picture"=312.5,
we get 64 microseconds. But some will wonder how come there are 313 lines, if  I
only see 200  on the screen?  The other lines  are used by  the upper and  lower
borders, and  by the  vertical synchronization  signal which  tells the  monitor
where the top of  the screen starts. Overscan  is the process of  converting the
lines used to make  up the borders into  lines able to display  a picture loaded
from memory. I will call "useable  screen" that part of the screen  not occupied
by borders.

A monochrome picture  is displayed in  the same way,  where the refresh  rate is
approximately 70Hz and each line takes 28 microseconds to be transmitted. It  is
composed of approximately 500 lines, of which 400 form the useable screen.

Video Components

Before getting into the subject, let us recall the role of each component of the
ST responsible of the display.

- The MMU: This component reads memory and sends it to the SHIFTER every 500 ns.

  * Address of the picture to display on next VBL:
$FFFF8201: upper byte
$FFFF8203: middle byte
$FFFF820D: lower byte (STE only)

  * Video counter, indicates the address being decoded at this instant:
$FFFF8205: upper byte
$FFFF8207: middle byte
$FFFF8209: lower byte
    Please note that you can only read from these on a plain ST, the STE however
    also allows to write to them,  which will immediately  change the  displayed

- The GLUE: Produces the vertical and  horizontal synchronization signals.  It
   also produces signals telling the SHIFTER  when it should display the useable
   screen,  and  when it should show the background  colour 0  (corresponding to
   the border). It also tells the MMU when to send data to the SHIFTER.

  * $FFFF820A: Synchronization mode
    Bit 1 corresponds to the monitor refresh rate (0 for 60Hz, 1 for 50 Hz)

  * Resolution:
$FFFF8260  (Both the GLUE and the SHIFTER have a copy of this register)
    This byte can have  one of 3 values:  0 for low-,  1 for middle- and  2 for
    high-resolution.  The GLUE needs this register,  because in high-resolution
    the picture is displayed at ~70 Hz which requires different synchronization
    signals (see second part)

- The SHIFTER:  Decodes the data  sent by the MMU into  colour or  monochrome
   signals, corresponding to the picture in memory.

  * Resolution:
$FFFF8260  (Both the GLUE and the SHIFTER have a copy of this register)
    The SHIFTER needs this register because  it needs to know  how to decode the
    picture data (as 4, 2 or 1 bitplanes) and whether to send the picture out to
    the RGB pins or the monochrome pin. Indeed, if one of these pins are active,
    the other is low.  The "hardware"  proof is  that the SHIFTER  receives  the
    address bus signals A1 to A5 (no need for A0 because every address is even).
    However only A1 to A4 would be sufficient to access the palette.

Video Signals

Now we'll discuss which signals the display components use to work together.
Before diving in, a word of warning: everything said here was deduced logically
but never verified with an oscilloscope. Thus, while I'm sure of my conclusions,
I don't take any responsibility if some hardware hacker damages his ST by
trusting this article.

The MMU reads picture data from memory  and passes it on the SHIFTER, using  the
Load/Dcyc signal to  tell the SHIFTER  the data on  its data bus  comes from the
screen buffer. When this happens, the  68000 can't access the data bus.  Because
the  data  bus  is also  used  to  program the  SHIFTER  registers,  you may  be
wondering,  how  can the  68000  change resolution  or  the palette?  After  all
programs such as Spectrum 512 change the palette while the picture is displayed!
Isn't there a conflict between the 68000 and the MMU?  To help us to understand,
we notice that the 68000 has access to the address and data buses every 4 cycles
(which explains why  all instruction cycle  times are multiples  of four: a  NOP
takes 4 cycles as specified in the 68000 manual, but EXG takes 8 cycles  instead
of the 6 specified in the manual). Thus, the MMU steals the other cycles to read
the video memory and to  transfer it to the SHIFTER,  and also to deal with  DMA
Sound on the STE. On the other  hand, the MMU interrupts the 68000 for  disk-DMA
(floppy and HD)  and Blitter transfers.  Thus, if these  devices are not  turned
off, every programs  that relies on  constant execution time  (such as Overscan)
will not work correctly.

The GLUE generates the DE, Vsync, Hsync and Blank signals:

- The DE (Display Enable) signal  tells the  SHIFTER when to display the  border
  and when it has to display the  usable screen.  It also tells the MMU  when to
  send data to the SHIFTER:  It is unnecessary  to send  data and  increment the
  video counter  while the  border is  displayed.  If you cut the track  of this
  signal you will obtain a  "hardware" overscan (thanks to Aragorn who confirmed
  this by doing it). However, due to stability issues, this is  not recommended.
  The Autoswitch Overscan board (see ST Magazine 50) works in a very similar way
  by controlling this signal.

- The Blank signal forces the  RGB colour outputs to zero  just before,  during,
  and just after the Hsync and Vsync synchronization signals.  Indeed,  monitors
  require the video signal  to be 0 volts  (black colour) before  every synchro-
  nization pulse (implemented as a negative voltage): Even the border colour has
  to be eliminated to prevent overlaying the border colour over the screen while
  the electron beam returns to the beginning of the next line (from the screen's
  right to its left)  and to the next picture  (from the screen's bottom  to its
  top).  Note that the Blank signal isn't used if the screen is displaying high-

The Vsync and Hsync sync signals are added to the video signal:

- Vsync is the  vertical synchronization signal which specifies where the top of
  the picture is located  in the video stream.  The VBL interrupt corresponds to
  an edge of this signal.

- Hsync is the horizontal synchronization signal. It generates the HBL interrupt
  (vector $68).  The HBL interrupt  should not  to be confused  with the Timer B
  interrupt (vector $120)  which is generated  when the DE signal goes low on an
  input of the MFP:  The Timer B interrupt is triggered  only,  when the useable
  screen is displayed, because DE is inactive during upper and lower border.

The MMU uses the  Vsync signal to  reset the video counter  with the contents of
$FFFF8201 and $FFFF8203 (you may also add $FFFF820D on STE).

Knowing that  the GLUE  handles this  signals,  it  seems logical  that it would
control the process of displaying the  screen. To do this, it would  require two

- a vertical counter:   the number of currenly displayed line

- a horizontal counter: the position within the line currently being output

We will first study the vertical counter.

Top and Bottom


Line Counter and GLUE

The vertical counter is  incremented every line, i.e.  at every edge of  the HBL
signal. It will be reset on each edge of the VBL.

At the top of the screen, a border will be displayed, and once a given value  of
the vertical  counter is  reached, an  internal signal  will be  set to show the
useable  screen;  let us  call  this signal  V.  V masks  the  DE signal,  which
specifies the location of the right and  left border. The V signal will also  be
deactivated when the vertical counter reaches a further value, corresponding  to
the end of the useable screen. Finally, once the counter reaches a third  value,
a VBL interrupt and the beginning of a new frame is triggered.

Based on  this, nothing  seems to  allow us  to get  rid of  the upper and lower
border. But we  must recall that  there are only  263 lines for  a 60 Hz picture
whereas there are 313 lines for a  50 Hz picture. If the upper and  lower border
had the same  height at 50Hz,  each one would  be 56 lines  high. If the useable
screen at 60Hz started  at line 56, as  it does at 50Hz,  there would only be  7
lines left for the  lower border: the useable  screen wouldn't be centered  ! On
some monitors, the bottom of the picture wouldn't even be visible...
Therefore the useable screen must start higher at 60 Hz.

At 60 Hz, the picture starts at line 34 and ends at line 234.
At 50Hz, the picture starts at line X and ends at line X+200.

Beware: the value X depends on the genation of the GLUE:
For older STs: X = 63-16 = 47 # (frost: beware also that the diagram says 49
For "newer" STs (every STs except those of ST Connexion!): X = 63.
In other words, on older STs, the picture is shifted upwards by 16 lines at 50Hz:
this explains why some obtains only 249 lines whereas others get 271 lines for a
simple Low-Border Overscan (thanks to Marlon of ST Connexion for telling me about this).

The following pseudo-code describes the work of the GLUE in a simplified fashion:

IF Line_Number ==  34   AND display_freq=60 THEN Activate signal V
IF Line_Number == X     AND display_freq=50 THEN Activate signal V
IF Line_Number == 234   AND display_freq=60 THEN de-activate signal V
IF Line_Number == 200+X AND display_freq=50 THEN de-activate signal V
IF Line_Number == 263   AND display_freq=60 THEN start a new VBL
IF Line_Number == 313   AND display_freq=50 THEN start a new VBL
Line_Number = Line_Number+1

Note that the frequency test happens more  than once when a new VBL is  started.
Thus, it  is not  possible to  use the  second example  program (see part #2) to
check the starting line of a 60  Hz VBL: just as well because line  263 triggers
the Low-Border Overscan on newer STs. If you want to check, make the VBL  adjust
the frequency to 50 Hz and the HBL to 60Hz at line 263.

The pseudo-code  is only  presented as  an example  to help  you understand  the
problem: the  GLUE is  not programmed  (that would  be too  slow for a component
which must  react in  500 nanoseconds).  Everything is  implemented as  hardware
logic, which explains the use of  equalities which are easier to implement  than

Horizontal Overscan

Since the ST only checks whether the vertical counter is equal to a given  value
to activate or deactivate the signal V,  one can obtain a variety of effects  by
setting the refresh rate at the appropriate line.

Thus, in order to produce a Low  Border Overscan, it is sufficient to switch  to
60 Hz at the right time at the end of line 199 of the useable screen. This  will
prevent the GLUE from  deactivating the V signal:  at the value of  the vertical
counter corresponding to the  199th line of the  useable screen at 50Hz,  V will
only  be deactivated  if the  current frequency  is 50Hz.  Because the  vertical
counter is now  greater than any  of the values  that cause an  event at a  60Hz
refresh rate, there are  no other effects to  worry about. Once the  time of the
test has elapsed (the test occurs at the beginning of the line, even before  the
left border is displayed),  it is necessary to  switch back to 50  Hz, otherwise
the screen will be distorted (refer back to the pseudo-code).

It is also  possible to shrink  the screen by  switching to  60  Hz at line 234:
this  corresponds  to  the point  when the  signal V  is deactivated  at 60 Hz.
Switching back to 50 Hz,  the screen will not be  affected by the subsequent de-
activation of signal V at line X+200.

Finally, it is useful to know that  one can produce a low border Overscan  at 60
Hz: at the end of  line 199 of the useable  screen, we switch to 50  Hz and then
back to  60 Hz,  avoiding the  test  at  line 234.  We can  use the same Timer B
interrupt routine whether the  program is running at  a refresh rate of  50Hz or
60Hzin, by using the following instruction:  eor.b   #2,$ffff820a.w.  The only
commercial program that  I know that  uses this technique  is the game  "Leavin'
Teramis" by Thalion Software: during  level loading, a 22000 colours  picture is
displayed, at either 50  hz or 60 Hz  (to reduce flickering). The  green message
under the picture is displayed in the lower border in both cases.

As  the lower  overscan happens  at the  bottom of  the useable  screen, we  can
synchronize the 68000 code versus the video counter ($ffff8205 to  $ffff8209),
resulting in better stability (see next  the part for example code). It  is even
possible to use the  floppy disk DMA with  a bottom overscan. This  kind of code
trades off the  amount of time  spent at the  alternate refresh rate  versus the
amount of distortion caused on the screen.  Note that there do not appear to  be
any methods other than toggling the refresh rate to remove the lower border.

To remove the  upper border, we  simply switch to  60 Hz at  the end of  line 33
(just before line 34,  where the test happens). As the top border overscan comes
before the useable picture,  we  cannot synchronize our program using  the video
counter. Various solutions have been used:

- A stupid wait loop  from the  beginning  of the VBL  interrupt handler,  which
  wastes cpu cycles but is easy to implement. This method makes two bets:

   * First bet, the VBL interrupt will always happen immediately, which requires
     that the 68000 is not executing an instruction which takes many cycles such
     as  movem  or divu,  since the 68000 will complete its current  instruction
     before servicing the interrupt handler.

   * The Second bet belongs  to the time taken by the  GLUE before treating line
     34. It has to be a constant whichever ST is used. So far this has proven to
     be true.

- The use of a MFP timer: This method allows the more than 17000 cpu cycles
  before line 34 to be used. However this method makes the following additional

   * Third bet, the latency to service the MFP interrupt will always be the same.
     This is true for the ST/STF series,  but some STEs that I was able to  test
     (thanks to Laurent) triggered  the interrupt 60 cycles later than on a STF!
     The bottom overscan of Leavin' Teramis doesn't' work on those STEs, even if
     the program  detects the STE:  This  shows that this delay varies according
     to your model of STE.

   * Fourth bet, unless we leave some dead time during line 34, we may encounter
     the same problem for the MFP interrupt as described in the first bet!

- The use of the HBL interrupt: this interrupt is nearly never used on the ST,
  and is even forbidden by the ROM (its interrupt handler, pointed to by vector
  $68 has as only function to mask this interrupt). As this interrupt is
  triggered by the Hsync signal, it occurs on every line (including borders and
  the useable screen), which makes it perfect for counting lines up to the 34th
  line after the VBL. But it has a drawback, which explains why this method is
  rarely used:  The HBL  interrupt occurs at the  beginning of the line, and the
  68000  takes at least  44 cycles  to enter the  interrupt handler, so that the
  interrupt  handling routine  is executed  in the middle of the  left border...
  Which is ugly if one uses it to change the palette!
  To remove  the upper  border,  each  HBL interrupt  will check  whether it has
  reached line 33. If so, it will wait (with a DBF and some NOPs)  until the end
  of the line to toggle the refresh rate. This way, we lose lose less cpu time
  than the first method, and we don't depend on the MFP.

  This method takes 2 bets:

  * First bet, the number of HBL lines to count will not change, whatever the ST
    we use:  This has never happened, and if it ever would,  none of other means
    of  removing  the upper border,  described above,  would work.  However this
    method will survive when the previous methods will not: The time between the
    VBL and line 34 may vary by up to a quarter of a line without  affecting the
    number of HBLs that must be counted...

  * Second bet, the time taken to service  the HBL interrupt will be a constant.
    Again,  I have never  seen this not to be true,  and it is hard  to see why
    Atari  would add  extra  circuitry to  this signal:  Some  chips  were added
    between the MFP and the 68000 on the STE,  but the MFP is fully used by this
    computer. Atari's disdain for the HBL should preserve its reliability.

It is  impossible to trigger a top  overscan in 60 Hz using a 50/60 Hz frequency

There is another method of removing the upper border: one switches to monochrome
output at the beginning of the VBL. This technique allows us to use most of  the
34 lines  above the  top border  overscan described  above. Unfortunately,  this
method only works on some STs, but not on STEs... This method relies on the fact
that a monochrome screen has an  even shorter top border since the  refresh rate
is 70Hz.  By switching  back to  50 or  60 Hz,  after the  video counter  starts
incrementing, one obtains a top border overscan. However, I've noticed that  one
does not remove  the upper border  if one switches  back to 50/60Hz  immediately
after the video  counter starts. Instead  one is able  to synchronize the  68000
with the  video counter  allowing one  to change  the colour  of the border at a
precise location, like BMT seems to do in the third screen of the Skid Row  demo
(see ST Mag 47, page 14). As  this technique is not reliable, I don't  recommend
it, to prevent  certain people from  complaining... (This is  an allusion to  an
article  previously  published  in  ST  Magazine,  written  by  Belzebub  of  ST
-Connexion, complaining that most overscans do not work on his ancient ST).

Now that we have learnt how to remove the upper and lower borders, it should  be
easy to  remove both  in the  same screen.  But a  subtlety is often forgotten !
Without top border overscan, we can use Timer B interrupt to trigger the  bottom
overscan, so the border is removed whatever value of X, the number of the  first
line of the useable screen. We  cannot use the same technique when  removing the
upper border: to remove the lower border, we must toggle the refresh rate twice,
with an interval of  16 lines. This will  guarantee compatability with the  most
recent STs as well as antiquities.

This is the end of the first  part of the article about Overscan. The  next part
is about creating left and right border overscan and about the internals of  the
SHIFTER.  We'll learn  about shifting  the useable  screen around,  the need  to
stabilise left/right overscan and  how to reset the  SHIFTER. The third part  is
about fullscreen overcan, hardscroll and extended palettes.

We hope that this series of articles prejudice anyone. Its purpose is to correct
the imbalance between those that have contacts, access to source code, or access
to cracked  demos, and  those that  do not.  It will  demystify Overscan,  often
considered a magic recipe, and a landmark of programming progress. In this way I
hope we'll  see fewer  boring copycat demos, like mega-scrollers.  Overscan  and
Hardscroll  deserve  more  respect,  as  those  that  discovered  them  know how
difficult it is to find them.  I therefore hope to see more Fullscreens that are
worth keeping.

Sengan SHORT (Alien of ST Connexion)

Rough translation by frost of Sector One (
Translation revised by Alien of ST Connexion 2005. (

Believe it  or not,  ST Magazine  still kind  of exists  (
which  is  pretty  cool,  since  at the  time  it  beat  all  other European  ST
publications, and was probably critical in  the rise of French Demo Groups  from
1991 onwards ( You may also
know the archive that contains most of the scanned issues of the old ST Magazine
at (

Alive 9