Part II: Raster Interrupts

THE WIZARDS PART II - RASTERINTERRUPTS by Erik and Udo of TEX

  Originally published in "68000'er/ST Magazin" of  August  1988, 
this  is  the  second article in which the  world's  most  famous 
hackin' group - The Exceptions - explains some of the tricks that 
made them famous in the first place.  Or:  How to do things  that 
are impossible.  This article was written by Erik and Udo of  TEX 
(thanks  for sending the original,  Erik!),  and  translated  and 
reprinted by kind permission through Tarik Ahmia of  "68000'er/ST 
Magazine" (cheers to you! May your life be bug-less forever!). In 
ST NEWS Volume 3 Issue 5, the Exceptions told you something about 
smooth horizontal scrolling; in this issue they'll talk about the 
mysterious topic of....raster interrupts.

 Hello,  dear Demofreaks and machine language programmers,  hello 
dear  readers!  Here  we are again,  gathered  together  for  yet 
another hour of tips & tricks.
  Have  you understood the previous article  well,  and  are  the 
characters now scrolling smoothly over your screen?  Or have you, 
quite  outraged,  scrolled your ST through your (closed)  window? 
Whatever may be the case, we now mercilessly intend to go on with 
the  next chapter:  We will dig deep into the wonderful world  of 
Raster interrupts!  But,  like in our earlier story, I would also 
like   to  present  you  with  some  more  anecdotes   from   the 
"Development Story" of our Club.
 Don't start panting now,  since I will now just describe some of 
the  proceedings  that took care that we met someone  who  called 
himself "Mad Max",  or better Jochen.  He is now, in all modesty, 
one  of  the very best (or the  best?) sound  programmer  on  the 
Atari ST.
 The whole thing with Jochen (and the second demo) started in the 
sales department of a Computershop in Mannheim.  There,  I talked 
with someone named Sascha about the subject of pirated  softw..., 
no, we talked about decentralized safety backups, the creation of 
which we both felt warm about.  Thus,  I drove to and fro a small 
meeting of ST freaks in Ramsen,  a small village that is  located 
on an even more remote spot than our native village Bad Dürkheim.
  The meetings took place at our member-to-be Michael  ("Daryl"). 
Sometimes,  a  longhaired fella could be seen there that did  not 
yet  have  an  ST,  but that was  definitely  interested  in  the 
machine.  Unbelievable stories were told of him:  Despite of  the 
fact that he was 15 years old at that time,  he already knew  how 
to  handle the Music routine of music programmer Rob  Hubbard  on 
the C-64, so that he could play melodies through that.
  On his school,  Jochen gained his first fame by creating  'rock 
versions' of X-mas songs.  When he got to have an ST a bit later, 
we immediately stumbled onto the poor guy with the question if he 
couldn't do something like that on the ST, too.
 His lapidary answer to this question was:  "Why not?".  After  a 
while, the first successes followed.
  Only later did I hear that Jochen had examined the ST in a  way 
that can only be described as 'adventurous'.
 Without being slowed down by books about the "Sixteen-Thirtytwo" 
he  found out everything about the necessary sound registers  and 
started to experiment with these.  Soon,  amazing tones could  be 
heard  coming  from the small chamber,  where Udo could  also  be 
found.  Up  to then,  ST friends weren't particularly treated  to 
good music in games or music programs.
 We were stunned. And from then on there were three of us: Jochen 
was now with us as sound specialist.
  The thought of a new demo crawled into our minds.  A demo  with 
more movements on the screen,  even MORE colors and music of  our 
own.  Being a Rob-Hubbard fan, Jochen did the impossible and made 
ST versions of some of Rob's songs.  Back then,  this method  was 
very  tiring;  hours of typing data from printed out  C-64  songs 
were  needed.  Then,  one afternoon,  we met at  Jochen's  place, 
harassed  his sister out of the common room and began making  the 
second demo.  Graphics were designed, routines were made to match 
one another and note tables were entered.  Our feverish work  was 
only  interrupted  by  some  (not  quite  good)  pizzas  and  the 
accidental appearance of the house cat on our  keyboards.  Jochen 
was  just  typing  the C-64 game "Thing on a  Spring"  music  and 
ordered  me  to design the graphics for that.  That  happened  at 
about 02.00 hours. I did it.
 And that's the reason that in the second TEX demo a small  piece 
of  graphics  is  present that will never see the  light  of  the 
screen because,  as you would have guessed (or don't you know our 
second demo?), the music data was not ready in time - whereas the 
logo was.
 Why?  Well, the morning sun was sending its rays directly on our 
monitors and,  who'd believe that  ,  we were  TIRED!  Muttering, 
Udo,  Michael and the Chronicler of this text went on the way  to 
home.  Happily,  we sighed something like "finally ready",  "good 
music" and "the rasters are standing".
 Yes, there they are again, those mysterious "Raster Interrupts". 
Finally,  such  a  program does not merely exist  of  music,  but 
should  also offer some extraordinary optical effects.  And  what 
would be more appropriate than more than 16 colors simultaneously 
on  the screen?  But first,  we will have a deeper look into  the 
world of raster interrupts.
 As you might know,  an 'interrupt' is a signal of a chip  inside 
a  computer,  that caused the processor to stop  regular  program 
execution  and allow the program to branch to a  specific  memory 
address.  After that,  program execution continues as if  nothing 
has happened.  A rasterinterrupt is an interrupt that is  cleared 
when the electron beam of the monitor (that is controlled by  the 
computer)  reaches a certain line on the screen.  When you  allow 
the raster interrupt to branch to a subprogram that, for example, 
changes  the border color,  you can now change the  border  color 
wherever  you want.  Because the color change takes place on  the 
same  location every time,  two parts of the screen  appear  that 
hold a specified size.
  The methods of achieving a raster interrupt are different  from 
machine to machine.  With the C-64,  the Videochip takes care  of 
this job. You just have to give it the number of the line. In the 
Amiga,  a co-processor named Copper is there for this (as well as 
other) jobs. With our ST, things go even more different.
  The  Shifter,  the  chip that is  responsible  for  the  screen 
display,  is as deaf as can be.  This means that is doesn't offer 
much that we could use to do things.  It does  contain a register 
that contains the currently displayed video address,  but we have 
to  read that constantly in order to find out where the  electron 
beam currently is.
 Bingo.
  The  additional  colors  should,  after  all,  cost  the  least 
processor  time  possible.  So  let's have a look  at  the  other 
interrupt sources that are available.  How are things with the so 
called  timers?  The  ST  has  four  of  those,  that  can  clear 
interrupts to one's heart's content.  It's clever to use Timer  B 
here.  We  can  give  that one a counter,  that  it  will  easily 
decrease with one. When the value reaches zero, Timer B can clear 
an  interrupt through the MFP (Multi Function  Peripheral  chip). 
The clue with this method is that this counter is decremented  by 
one  every time a screen line has been displayed on the  monitor. 
When we supply it, for example, with the value "100", exactly 100 
screen lines later an interrupt is cleared. Practical, isn't it?
 If we can now also make sure that it regains its original  value 
exactly at the upper screen border,  it is possible to clear  the 
rasterinterrupt you've been wanting all the time at any place.
 Quite exceptionally,  the ST makes it easy for us here.  There's 
the so-called "VBL" (Vertical Blank) that is cleared regularly  - 
when the monitors starts displaying a new screen (in color  mode, 
that's 50 or 60 times per second). This interrupt is eagerly used 
by many applications in the ST,  to take care of tasks that  have 
to be performed quite often. When we reset our timer, if possible 
before  any  of  the other VBL routines  are  executed,  we  have 
reached our goal: The raster interrupt is 'standing'.
 Since we have already come so far,  it's probably quite clear to 
you that we will go further than just switching the border color. 
The possibilities are almost without limits.  Some  examples:  If 
you reset the counter after every interrupt that's cleared, it is 
of course possible to create several raster interrupts.
  This  functions  up to line 199 (up to now)  and  please  don't 
forget:  After the VBL,  so when the screen buildup starts  anew, 
you have to reset the first counter and the original colors.
 Thus,  it's possible to change all 16 colors at once,  but  it's 
also  possible  to display both color  resolutions  (320x200  and 
640x200)  at  once,  like some famous adventures  from  "Magnetic 
Scrolls"  clearly demonstrate (e.g.  "The  Pawn",  "Jinxter"  and 
others).
  Another  way  to torture the Shifter is to  change  the  screen 
frequency  in  the middle of the screen.  Some nice  effects  are 
created then,  but we will not dig into this any deeper until our 
last part of this series.
 Now,  you must be glad that you know what raster interrupts  are 
all  about.  But  there's something you should  know  that's  not 
really  nice:  Raster interrupts are not always equal  to  raster 
interrupts.
 No,  the switching line between two color palettes have to stand 
perfectly  still  and should not be insulting to the eye  of  the 
spoilt  beholder in the least!  How such flickering  appears,  is 
easy to see.
 Just imagine you have just changed the border color in a  screen 
line.  Two things can disturb your 'raster'.  Your routine can be 
interrupt  by another interrupt of a higher level.  This  assures 
flickering of several screen lines.  If the interrupt routine  is 
left to itself, the actual clearing of the interrupt also takes a 
certain  amount  of  time before the  ST  actually  handles  your 
routine.  Depending  on the way you have programmed,  it takes  a 
while  until the command is encountered that changes  the  border 
color.  In  the  meantime,  the electron beam continues  and  the 
switching of one color to another enters the visual range of  the 
screen.  How you can avoid these effects,  which difficulties you 
will encounter while trying to avoid them will Udo tell  you now.

  Just like Erik just explained,  the ST doesn't really  help  us 
with programming raster interrupts.  But there are three ways  to 
achieve  a  color switch,  though:  We take over control  of  the 
horizontal blank, the vertical blank and the MFP.
 Some additional explanations:  The MC68000 processor has several 
interrupt priority levels.  An interrupt of lower priority can be 
interrupt by one of a higher priority. In the ST, there are three 
priority levels with the numbers 2, 4 and 6.
  1.  The  horizontal blank (HBL) has priority  two  (that's  the 
lowest),  because it is called 15625 times per second on a  color 
monitor.  Therefore,  this interrupt is normally not even enabled 
on the ST.
  2.  The vertical blank (VBL) has priority four.  It is executed 
at  least 50 times per second.  The CPU branches fifty times  per 
second to an interrupt routine that handles GEM:  The setting  of 
the mouse, check drive, flash cursor...
 The MFP is a chip with many tasks.  It has priority six, that is 
divides as well.  The MFP is responsible for the RS232 port,  for 
the keyboard data handling,  control of printer and disk  drives, 
has a monochrome monitor detect function and has four independent 
timers.  Two of these timers count external signals; timer B gets 
its signals from the monitor:  It counts horizontal  blanks,  and 
thus  works much like the HBL - with the difference that the  HBL 
counts all blanks,  and Timer B only counts the blanks of  screen 
lines that are actually displayed (normally 200).
  The  method of VBL is very messy,  because the  current  screen 
position  is  compared  constantly,   and  it  thus  is  no  real 
"interrupt". So let me do some explaining.
  Everything  started  when  Erik  wanted  more  than  16  colors 
simultaneously on the screen. One weekend, he surprised me with a 
program that could display several border colors at once.  It was 
done with help of the HBL interrupt,  that decreased a counter at 
every  call until it would reach the value  of  zero.  Then,  the 
colors  were changed and the counter was set for the  next  call. 
Principally this is very simple but it looked awful!
  Because  every  interrupt can override the  HBL,  it  was  very 
difficult to count the lines.  The range of the color switch went 
up and down when moving the mouse or typing on the keyboard  (the 
mouse is a very intensive level-6-interrupt source).  That's  why 
this method was hardly perfect for us,  although this same method 
was used in games like "Gauntlet I" (the title picture).
  After the scroll routine of our demo was finished (see ST  NEWS 
Volume 3 Issue 5) and we principally had the background  artwork, 
we wanted to change the colors several times in the middle of the 
screen,  and  we  also  wanted to use 16  other  colors  for  the 
scroller.
  Then,  in  April  1986,  a program appeared  in  the  "68000'er 
Sonderheft" that allowed the display of 512 colors at once.  Yes! 
The Markt & Technik guys made us familiar with the principles  of 
programming more than sixteen colors at once on the screen!
 Trying the program displayed a picture much like a chess  board, 
which  really displayed all 512 colors of the  ST.  Alright,  the 
mouse  did  mess up things a bit (flickering of  one  line),  but 
that didn't have much to say in our new demo anyway.  So we built 
the appropriate parts in our demo and lo and behold....: Still it 
was trash.
 The color switching didn't flicker up and down anymore,  but now 
one  could see the color switching in one screen line.  This  was 
caused  by the following:  The MFP signals the CPU to  perform  a 
level 6 interrupt when the internal counter reaches the value  of 
zero.  The CPU now handles the current command completely  before 
it branches to the interrupt routine at all.
 During this time,  the electron beam of course moved on, so that 
you can see the colors switching in the next line.  Many programs 
leave  some space for this switching,  but this could not be  the 
case in our picture.  Somehow, somewhere, we would have to switch 
the colors faster.
 But the fastest way is also too slow:  Since the colors have  to 
be switched immediately after the interrupt is cleared.
 And here's the trick:
  One  has to clear the interrupt one line earlier and  wait  one 
line further for a HBL.  Thus,  it is possible to set the  colors 
while the horizontal blank is performed.
 With this method, we change the color of one line to another. On 
the  contrary  to Magnetic Scrolls title  pictures  ("The  Pawn", 
"Jinxter"...),  our routine only interrupts the program one  line 
earlier,  that  thus  executes more operations  as  well  (music, 
scrolling...).
   In our demo,  we only had to build in the music and the  whole 
case would be closed. But for our second demo, Erik had conspired 
some  more  tricks.  Starting  with color  palette  animation  in 
certain parts of the screen as well as the copying of song  logos 
onto the screen,  we generally built in more. It was early in the 
morning when the demo was ready. Since it mainly concerned music, 
we called it "Little Sound Demo".

 So far Udo's excursion into the hot world of raster programming. 
And  now  you  can  throw yourself at the  source  file  that  is 
contained in the "PROGRAMS" folder on this ST NEWS disk (the file 
is called "WIZARDS2.S").
 Just one more hint: Start the program as .TOS, because GEM tends 
to grow nuts when it looks at so many colors and crashes.
 We expect that no games, whether Public Domain or not, will ever 
bother  to  have raster interrupts that flicker or that  are  not 
present at all.  A very typical example of this is a quite recent 
game's "Game Over" screen that reminds us of the city's  library, 
although  there's  no fella there that walks around with  a  Mega 
blaster in an Alien Spaceship.

  In  the  next issue of ST NEWS,  you will be able  to  find  an 
article about sound programming as it should be,  explaining  how 
you can get tones from the soundchip which the (probably  already 
retired) developers of this chip didn't consider to be  possible. 
See you all then!

  Editorial remark:  In the original article,  a  type-in-listing 
appeared  that had some small errors in it.  In this issue of  ST 
NEWS, the proper listing is of course supplied on the disk.
�