The Wizards part I

THE WIZARDS PART I by Udo (-ME-) and Erik (ES) of The Exceptions
or: How to program things that are actually not possible

 Editorial remark: The articles in this series "The Wizards" were 
originally  published in the German "68000'er ST  Magazin"  under 
the  title  "Die  Hexer".  Many thanks need to go  to  its  chief 
editor,  Mr.  Tarik  Ahmia,  for  allowing ST NEWS to  use  these 
articles.  Many  thanks  also  need  to go to  the  guys  of  The 
Exceptions,  who assisted gladly with this venture. This article, 
the  first in the row,  was originally published in "68000'er  ST 
Magazin" 7/88.

  This  is  a series of articles that is written by  a  group  of 
programmers  that  is commonly known as "The  Exceptions"  (TEX). 
Well  known  for their demos,  they will now reveal some  of  the 
programming tricks that already stunned many people.  Some  basic 
knowledge of assembler and the ST's graphics setup is required.

 This time: The first experiences of two innocent people with the 
ST,  as  well  as theoretics and practicals  of  horizontal  soft 
scrolling on a computer that was not quite developed for that.

 Welcome to a small series, written by The Exceptions, a group of 
ST  freaks  that  is more known by a row  of  programming  tricks 
rather than their illegal activities.  With you,  we want to sail 
out with you on battle against the hardware possibilities of  the 
ST,  meet  its  strengths and weaknesses,  and get  to  know  its 
limitations  as  well as means to override these.  We  will  talk 
about the following themes:  Horizontal soft scrolling,  flicker-
free  raster  interrupts (which also means more than  16  colours 
simultaneously on the screen),  principles of music  programming, 
graphical  tips and tricks (anti-aliasing,  transparent  effects, 
etc.) and the display of graphics in the screen borders. To avoid 
this all from becoming too 'dry',  we will accompany this  series 
with some anecdotes of the life of so-called 'crackers',  like we 
are often called too.
 Many of you have probably already seen one of our demo programs, 
which  made us kinda well known in the circle of ST  users.  Each 
one in its own time,  these demos showed many effects of which it 
was thought that they were impossible to program. But, as is well 
known,  both  the  forbidden as well as the impossible  are  very 
exciting.  And coincidence brought together some guys that wanted 
to bring fear to the ST's hardware. Please let me introduce these 
people  and  their  'artistic  names'  quickly:   Our   assembler 
programmers Udo,  Gunter and Michael have adopted -ME-,  6719 and 
Daryl  as their names;  they are the specialists on the field  of 
rasterinterrupts,  scrolling  and speed-optimized  machine  code. 
Jochen  (Mad  Max)  prefers  indulging  in  the  worlds  of   the 
soundchip,  and  knows how to get tones from this quite old  chip 
that  it's developers would probably have found  impossible.  The 
writer  of  these  lines is  called  Erik;  my  specialities  are 
graphics and the invention of effects that should be realized  by 
the aforementioned programmers and that (in the best cases)  just 
make  them moan and groan.  TEX also exists of three  more  guys, 
that call themselves AFF (Axel), Martin Fry (Markus) and Dr. Byte 
(Carsten), but these do not work on this series of articles.

 What makes 'regular' ST users adopt cover names,  and enter  the 
world of more or less gladly seen activities?  For those that are 
interested  and for those that don't mind thinking back of  their 
own first contacts with the ST,  a small excerpt of our origin is 
offered  - that would eventually lead to the first TEX demo  (all 
others  may  proceed  at  the program  listing  in  the  PROGRAMS 
folder).

 It all started,  how could it have been different,  on the  good 
old C-64.  Back then two people, Udo and my Meaninglessness, were 
seated  behind this Bread-toaster and did nothing else than  that 
what  we  do  today:  Udo  brought the  hardware  to  life  using 
assembler,   while  I  was  more  interested  in  the   graphical 
capabilities of the machine. It was good fun, and success did not 
remain hidden for us,  but then,  1985, a new computer generation 
began  to display itself on yonder horizon.  Every piece of  news 
about the new 68000 machines was attentively observed by us.  And 
we  started....to program 68000 assembler!  How did that  happen, 
you might wonder,  without an Amiga,  Mac or ST?  Very simple: On 
the  64!  Only know to few,  a 68000-Simulator was launched  back 
then  on  the  small  Commodore  (no  joke!).   On  this  program 
(assembler  and simulator) we undertook the first steps on a  new 
processor.   Shortly  after,   we  heard  that  someone  in   our 
neighbourhood  has gathered enough small change for the  purchase 
of an Atari ST (Hi,  Heinz! Good luck in Stuttgart!). The results 
were  some  pilgrim's  voyages to  a  computer  that,  with  high 
resolution,  512 kB RAM,.  360k drive and a damn fast  processor, 
appeared  the by the Nonplusultra!  Wisely,  we glanced over  the 
scarcely  available software,  because it was a new computer  and 
there were even more things to be amazed at:  The luxurious  user 
interface for example,  with windows and menus through which  one 
looked...it  was  great  (have  you  ever  typed  'OPEN   1,8,15, 
"N:NAME,ID"'  to  format a disk?).  Further,  there  was  a  Word 
Processor  with  display  quality  never  before  seen;  not  the 
fastest,  but  it was programmed in a high-level  language,  just 
imagine!  With Logo, we couldn't do much on this machine, either. 
But of course there was Basic, on which we flung ourselves. After 
loading,  there  was some initial confusion,  but as  we  managed 
squeeze  the  first line-demo through the  heap  of  windows,  it 
turned  out that even the oldest ST-Basic-version could stun  64-
freaks  through its high speed.  So what was more likely than  us 
testing  our recently acquired  assembler-knowledge  practically? 
There  was  no assembler to be seen anywhere,  so  that  a  small 
routine was manually converted into opcodes.  Without limitations 
imposed  on us by knowledge of the ST's memory map  or  something 
like that,  we POKEd our program in the RAM and immediately had a 
key-experience:  A  row of impressively looking  Atom  explosions 
appeared  on the screen - not really tasteful,  but much  forming 
something  useful to the occasion.  Testing of several pieces  of 
RAM followed after the method:  Boot TOS,  load Basic,  BAMM!! We 
enjoyed  ourselves  thus for a while,  when suddenly  Udo  got  a 
magnificent idea: Why not check the available RAM? A PRINT FRE(0) 
brought  mood in our first round: Appalled screams and the  words 
'11.720  Bytes?' echoed through the house.  What had happened  to 
the enormous range of memory? People who know the size of TOS and 
ST-Basic,  can calculate it simply. So that's what we did, and we 
went  just below screen memory that we had found  through  random 
POKEing anywhere in memory (BAMM!!).  And there is ran: Our first 
assembler  program!  It  was supposed to fill the  entire  screen 
memory with the value $FFFF. The screen, however, was not filled, 
but just WAS filled after the program was started. We yelled like 
madmen,  and our shrewd conclusion was:  "This processor must  be 
FAST!' From now on,  Udo wrote and assembled his programs on  the 
C-64 and typed them on Heinz' ST in the weekends,  that got  used 
to it.
  Then  came  the  C-Bit '86;  the ST's price  sank  to  that  of 
affordability, whereas other computer like the Amiga still roamed 
in  the  regions of more than 6000 German Marks.  That  made  our 
decision quite clear,  and in the spring of 1986 Udo and I bought 
an ST; he bought one with a monochrome monitor whereas I bought a 
color  system,  because when I had played with "Neochrome"  in  a 
shop earlier,  I knew the ST was to be my system.  We slowly  dug 
into the machine and,  since Udo has bought the K-Seka  assembler 
with his ST,  programming could start. The K-Seka assembler was a 
blessing for us, because we wanted to test small programs without 
having to leave an editor,  writing the assembler error  messages 
down and having to link it all together through a linker.  And we 
don't  even talk about the fact that there are easier methods  of 
debugging  rather  than  counting the bombs.  In  spite  of  many 
errors,  Data Becker's "ST Intern" (that had just been published) 
was of good help to us. The hunt for the hardware could start!
 While I was busy writing small machine code routines, but mainly 
found  out  what  the machine's  graphics  were  all  about,  Udo 
started right off.  Rasterinterrupts and soft scrolling were  his 
favourite disciplines on the 64, so why not on the ST as well? We 
will  talk about the Rasterinterrupt adventure in the next  issue 
of ST NEWS - for now,  we'll take a closer look at scrolling. The 
machine  code routine in the PROGRAMS folder,  by the  way,  only 
runs on color monitors!

 What,  actually, IS scrolling? Basically, it can be said that it 
means  the  moving  of the contents of the screen  in  a  certain 
direction,  whether characters or graphics (which is all the same 
with the ST,  as you'll know). When you list a program listing on 
the screen,  for example, it scrolls up. The next level comprises 
the  so-called  'soft  scrolling'.  The  screen  moves  smoothly, 
without flashing or shaking.  This kind of scrolling is  obtained 
through three factors.  First,  the distance between to movements 
should not be too big.  But the most important factors are  these 
(which also count for shapes that move across the  screen):  From 
one  scroll-step  to another,  no more than 1/50th  of  a  second 
should  pass.  That's the screen frequency of your monitor -  the 
time the electron beam in your monitor needs to draw one  screen. 
If  your  program uses more than 1/50th of a second to  move  the 
picture,  it can happen that it appears as if your monitor builds 
up the screen too slowly:  It starts to flicker or shake. Thinks, 
for comparison, of a film projector that runs too slow. The human 
eye cannot be fooled to think that things are happening  smoothly 
when it's done at less than 50 screens per second.
 For the perfect scrolling,  you must also watch out that you  do 
not  move graphics that are currently drawn on the screen by  the 
electron beam.  This will result in part of the 'old' graphics to 
be  displayed,  while your program is already moving  the  screen 
contents. So far the theoretical aspects.

   Our   practical   experiments  on  the   ST   started   really 
disappointing.  Scrolling vertically went really nicely,  but  in 
the horizontal directions, everything went wrong. The grounds for 
this are hidden in the graphical setup of the ST's screen. Memory 
words  that  lie behind each other create the  bitmap.  When  one 
would want to move the screen, or a part of it, one pixel down or 
up,  it  suffices to move a memory block word-wise (1 word  is  2 
bytes = 16 pixels).  The 68000 doesn't take long in these  cases, 
and does this with its familiar speed.  That also explains why so 
many shoot-'em-up games appear on the ST with vertical scrolling. 
The  reason why such few games with horizontal scrolling  (hello, 
Steve Bak!) are on the market, is simple. When graphics are to be 
moved  by less than one word (16 pixels) to left  or  right,  the 
bits  of the memory words have to be shifted and that even  costs 
too much time for the 68000 when more than just a few lines  need 
to be scrolled.  Thirty-two scanlines is possible, but there's no 
time left to process shapes or something else.
 So one should use as little bit-oriented operation as  possible. 
But  how?  We  DID want to scroll more than just a  part  of  the 
screen,  and time had to be left to take care of other jobs (like 
moving objects,  for example).  Don't panic. Udo found a solution 
for  our first demo (what a staggering coincidence) and will  now 
explain it:

  The  first trials were based on simple,  bit-wise  shifting  of 
memory words,  but was so slow that I had to think of new method. 
The  bit-shifting  routine was written on paper,  and  the  clock 
cycles were added together.  A glance in the 68000-book and  some 
thinking  were needed to know that the same thing could  be  done 
faster using other instructions.  After the moment on which  this 
kind  of optimising didn't speed up anything anymore,  I  had  to 
think of some other programming logics. The bit-wise shifting was 
the slow-down factor in my routines; somewhat faster is byte-wise 
shifting  and,  due  to the graphic setup of  the  ST,  word-wise 
shifting  is fastest.  That would,  however,  turn out to  be  16 
pixels at once. That's too fast to read and would shake terribly. 
So  there  was only one solution:  Using 8 buffers in  which  the 
graphics were each shifted 2 pixels,  and displaying these  after 
one another.  After displaying the last buffer,  the first one is 
shifted  by 16 pixels and the shifted graphics now fit neatly  to 
the eighth buffer.
 Copying the buffer to the screen also needs some time,  so  that 
up to fifty scan lines can be scrolled using this method  (adding 
data  to  be scrolled into the screen will be  discussed  later). 
When  you  also want to save the  buffer-copying  time,  you  can 
simply  work  on eight screens.  You can then scroll  up  to  100 
lines,  but  it  costs you 256 Kb memory that are only  used  for 
scrolling.

  Now  for  the problem of adding data to be  scrolled  into  the 
screen (in our case from the right of the screen).  They have  to 
be shifted bit-wise each time,  and get into eight other  buffers 
from  which  the current scroll buffer gets its memory  words  to 
merge  them onto the right.  This preparation of the eight  extra 
buffers  (at  which only two memory words are  shifted  bit-wise) 
takes just as long as shifting one buffer but-wise and copying it 
to  the  screen.  This  shows  how  tideously  slow  bit-oriented 
operations  are.  A further trick exists in the way  one  shifts: 
Because  not just the next,  but also the memory word after  that 
can become visible,  this data has to be added.  Here,  no single 
bits  are  shifted  several  times and  the  carrier  flag  added 
afterwards,  but  each  over-next  word is loaded  in  the  upper 
longword half of a register,  the next one in the lower  longword 
half  and  then  the required factor is  rotated   to  the  left. 
Thereby,  the  bits of the over-next word fit neatly to the  next 
word.

  Now  for  a general look at the program (to  be  found  in  the 
PROGRAMS folder, "WIZARD_1.S", on this ST NEWS disk).

 When initializing,  a table is built up that contains a  pointer 
for  each character.  In our case,  the characters are 32  by  32 
pixels in size,  and are painted using "Neochrome".  In the first 
32  screen  lines,   the  first  ten  characters  are   therefore 
contained,  and so on.  Later,  our text only consists of numbers 
that identify the character to be displayed.
 After that,  the height in 'zanz' needs to be  specified,  after 
which  the routine only has to be built into the  ST's  interrupt 
structure.
 Our interruptroutine contains an internal counter,  that is used 
by the program to determine which buffer has to be displayed  and 
which  one  is  being  prepared  to  be  displayed.   The  proper 
subroutine  is executed through the value of  this  counter.  The 
subroutines 1-7 are identical to the subprograms 9-15.  They only 
transfer the current buffer addresses and shift off.  Routines  0 
and  8,  however,  also  have to prepare  the  data-add-buffer  - 
routine 0 gets the next character to be displayed,  calculates it 
and  prepares the appropriate  counter.  Then,  the  data-add-on-
buffer  is shifted.  Routine 8 takes over the right  counter  and 
shifts the last 16 pixels of the data-add-on buffer.
 The 'linksw' routine shifts 16 pixels (one word, two bytes) in a 
buffer, and merges the 16 pixels of the data-add-on buffer to the 
right.  The  'show' routine copies the appropriate buffer on  the 
visible screen.
 The routine 'addpuff' prepares the data-add-on buffer,  which is 
optimized by the trick I mentioned above.

  I  have  used this technique in an assembler  listing  that  is 
supplied in K-Seka format.  When you want to experiment a little, 
you can go ahead.
 When you have assembled the program,  all you need is a  picture 
with a character set and scrolling can start!

  And thus,  together with some raster effects,  the  necessities 
were  created  to create a demo program the likes of  which  were 
just 'hot' among Commodore 64 crackers.  So I designed a  picture 
as  well  as a character set,  and Udo brought it  all  to  life. 
Because we didn't know our sound programmer Jochen back then, the 
music  from  the game "Extensor" got the dubious  (?)  honour  to 
support  out demo with some sounds.  Now we also needed  a  name, 
according to the 'tradition' that comes with making program  like 
our demo.  After some thinking we both decided to call  ourselves 
"The Exceptions". First, this name had something to do with 68000 
machine  code,  but  we also were exceptions  because  we  hadn't 
cracked much programs and there were no real connections with the 
'scene'.  Apart from some local fame,  this demo didn't bring  us 
much, though we sure got experience, Know-How and FUN!

 In the next issue of ST NEWS, we will tell you more about raster 
interrupts (using more than sixteen colors on the screen) and the 
development of the second demo. I hope you'll have fun, too.
�