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
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
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.
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
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
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
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
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,
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.
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.