The Thalion Source - The Wizards - 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 raster interrupts, 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 its 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.

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 C-64! Only known 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 to be 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 to squeeze the first line-demo through the heap of windows, it turned out that even the oldest ST Basic-version could stun C-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 it 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 CeBit '86; the ST's price sank to that of affordability, whereas other computers 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 colour 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. Raster interrupts and soft scrolling were his favourite disciplines on the C-64, so why not on the ST as well? We will talk about the raster interrupt adventure in the next issue of ST NEWS - for now, we'll take a closer look at scrolling.

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 two 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. Think, 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 a 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 to the problem of adding data to be scrolled into the screen (in our case from the right of the screen). It has 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.

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 interrupt routine 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 our demo with some sounds. Now we also needed a name, according to the "tradition" that comes with making programs 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 colours on the screen) and the development of the second demo. I hope you'll have fun, too.

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. 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 Magazin" (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 demo freaks 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 colours 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 colours 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 causes the processor to stop regular program execution and allows the program to branch to a specific memory address. After that, program execution continues as if nothing has happened. A raster interrupt 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 colour, you can now change the border colour wherever you want. Because the colour 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 it 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 colours 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 raster interrupt 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 monitor starts displaying a new screen (in colour 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 colour. 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 function works 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 colours. Thus, it's possible to change all 16 colours at once, but it's also possible to display both colour resolutions (320 x 200 and 640 x 200) 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 colour 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 colour in a screen line. Two things can disturb your raster. Your routine can be interrupted 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 colour. In the meantime, the electron beam continues and the switching of one colour 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 colour 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 interrupted by one of a higher priority. In the ST, there are three priority levels with the numbers 2, 4 and 6.

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 colours simultaneously on the screen. One weekend, he surprised me with a program that could display several border colours 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 colours 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 colour 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 colours several times in the middle of the screen, and we also wanted to use 16 other colours for the scroller.

Then, in April 1986, a program appeared in the "68000'er Sonderheft" that allowed the display of 512 colours at once. Yes! The Markt & Technik guys made us familiar with the principles of programming more than sixteen colours at once on the screen! Trying the program displayed a picture much like a chess board, which really displayed all 512 colours 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 colour switching didn't flicker up and down anymore, but now one could see the colour 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 colours 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 colours faster. But the fastest way is also too slow: Since the colours 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 colours while the horizontal blank is performed. With this method, we change the colour 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 colour 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. 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.

Finally, now the time has arrived for which all you computer freaks have been waiting such an incredibly long time: The third part of the amazing series in which the hacking group "The Exceptions" explains all about their programming tricks. This time: Professional music programming on the ST, together with some amazing source stuff for a really good synthesizer!!! Many thanks need to go to Mr. Tarik Ahmia of 68000'er/ ST Magazin for giving his permission for us to use these articles in ST NEWS.

This time, there's a special bonus for those among you that uptil now always doubted the simple musical capabilities of the ST: An exclusive music routine for ST NEWS that you can use in your own programs and that is supplied with several special effects! You know the recipe: First I, Erik, will talk a bit with you about the background story of TEX, and then the specialist, Jochen, will tell you how it is possible to get decent music from the ST. That this is very difficult, nobody knows better than Jochen himself.

Our second demo (LSD, Little Sound Demo; we talked about that in ST NEWS Volume 3 issue 6) was barely ready when he already started improving his synthesizer routine. Heated up by real "sound orgies", that were especially celebrated by the English music programmer Rob Hubbard on the Commodore 64, "Mad Max" eagerly sought to get similar effects from the prehistoric soundchip of the ST. Some things have to be said in advance: When looked at objectively, our ST surely has the worst soundchip of all current home computers (exceptions later). The Commodore 64 as well as the Amiga are way ahead. But, immodest as it may sound, Jochen doesn't allow hardware limitations to impress him much, just like the rest of our strange group. Soon, my old C-64 moved to our music freak more and more often, to assist him with reference during the conversion of Rob Hubbard's game music; since we had received some positive reactions to our demos, the motivation grew to make a third program of this kind to put all previous once in the shade. Whilst my nothingness started making a small portrait of the mentioned Rob Hubbard, and Udo was busy working out some new ideas for new effects, Jochen didn't do nothing either. Perhaps, the way in which music was converted from the C-64 to the ST might be interesting for some of you. At the time of the creation of our third demo, this was still very tiring. Jochen knew how to read Hubbard's C-64 note format like other people read comics, but the whole thing had to be typed and converted in the head to Jochen's note format, and then typed into the ST. Next, he had to try to make the sounds arising from the "bread toaster" sound as much like the C-64 as possible, with the modest capabilities of the Yamaha soundchip.

That's how eight pieces of music were developed that were desperately looking for some competition back then. Further, the creation of the third demo was quite the same as that of the other two. We worked for weeks and then, on one night and the morning after that, we mashed the whole thing together to the best TEX-demo then existing. Except for the good sound, there were two astounding things to note in the new demo: A "Three-channel-LED-VU-metre display" and a scroll line that displayed dozens of colours (thus giving the third demo its name: "LCD" or "Little Colour Demo"). After that, there was peace and tranquility for some time. Like people can still read in the "LCD", we didn't want to produce any demos for a while (boy, were we naive!), mainly because Udo and myself were working some time already on a commercial program - a game, of course. At the moment that you read these lines, it will still probably not be for sale anywhere. Nobody is surprised by that, and we in the least, because we couldn't resist to throw away our time making more demos of course. First, it was impossible to resist the temptation of making a slideshow for Neochrome pictures, as a friend of ours from Mannheim (working under the pseudonym ALYSSA) had discovered how it is possible to display graphics in the lower border of the ST. Next, Udo succeeded in displaying complete pictures, scrolling in the lower border, setting rasters, playing music with digital sound effects and loading pictures with the operating system - all simultaneously! But more about that in a later article.

Now, we are interested in music, and everybody who knows our demos should now immediately think of our "B.I.G. Demo", since it contains 127 different pieces of music. The one that this time started it all was our good friend Richard Karsmakers from Holland, now ex-editor (but special correspondent) of just about the best disk magazine for the Atari, ST NEWS (thanks, guys! ED.). After he had convinced us (or, rather, Jochen) to supply his disk magazine with background music, he started bombarding us with plans for a demo that should put everything else that had then been finished in the shade! He plainly stated that it would be very nice for a demo to contain all the musical compositions ever made by the music programmer that he (and we) admired: Rob Hubbard! Before we others only had the chance to breathe, "Mad Max" had already agreed. He had surely not done that if we had not made an interesting tool. Because while I was soldering a cable for data transfer from C-64 to ST, Udo had programmed a bit on both computers so that the whole RAM of the C-64 could be stuffed into the upper part of the ST's RAM. The tedious typing that Jochen had to do was now definite history, and what else could he do then to write a conversion routine to convert Hubbard's note format directly to his? Some work is still left then, however, since not everything can be translated, and the seperate voices have to be manually adjusted - still today. But this data transfer cable was the condition needed to start with something crazy like the "B.I.G. Demo" in the first place. Additionally, TEX had gained some powerful support by means of Michael (Daryl) and Gunter (6719). The production time of this project was, just allow me to use an eufemism, long. Over three months we worked, more or less intensively, on our 5th demo, and in the end it turned out that we had all put more work in it than we had wanted to and than was good for our game. The program-technical and graphical tricks that we used in this program will be revealed some other time. With regard to the sound and music, the endless list of musical compositions wasn't enough to satisfy us. In the "B.I.G.-Demo", there was a world premier of one of Jochen's new programs: The digital sound synthesizer! It could do nothing less than creating musical notes through the same principle that the Amiga soundchip uses to create them.

But one thing after the other. Let's first talk about Jochen's "normal" synthesizer program, and how it creates music with the built-in soundchip. This soundchip was developed by Yamaha and listens to the name "YM 2149". At the time it was introduced, it was a blessing for all coin-up producers and was now able to supply the newest arcade games with sounds never heard before. We hereby mean current arcade hits like "Pac Man", "Asteroids" and other oldies that we now think back about with tears of emotion. Tears of sadness, however, can be seen in one's eyes when one discovers that this ancient technical piece is again found in one of the hottest home computers at the end of the eighties. Probably, Jack Tramiel's developers treated the YM like a port chip anyway, that accidentally had some music generating circuits attached to it. Yeah, all right, I will stop this now. It just had to be said once. The technical data of the chip speaks for itself: The mentioned ports, two in number, switched as in- and output ports, take over data exchange with the disk drive and the printer. For the creation of music, they don't do much, as you will understand.

The following specifications can be set for any of the three sound channels still left:

The waveform specifies how a tone handles its attack, decay, sustain and release, so that one often talks about an ADSR-waveform. A piano, for example, has a rapid attack, doesn't keep the tone going for long and takes a long time to disappear. This is almost everything one needs to say about these tables, since the sounds produced by these tables don't sound all too well, and are almost all equal as well.

The YM-2149 knows only one true waveform, which is the rectangular waveform. Additionally, one (and the same) noise generator can be added to the voices. That's about it. Really, there isn't any more! To illustrate that it really isn't much, we will have a brief look at the SID, the soundchip of the C-64. It also has just three voices, that all have to share the same volume register. Additionally, it has:

All these features can be specified for each individual voice. This assures that a more widely varied sound pattern can be created - and just think that this C-64 computer exists since 1982! You might now perhaps wonder why a regular ST freak talks so badly about his machine's musical capabilities. The reason for this is the fact that we find that it should be common knowledge that the ST hasn't particularly been supplied with superb stuff with regard to sound production. When you often read in reviews of music programs or games, that the "sound is almost never worse than on the C-64", this proves that mankind and particularly the software reviewers (no, not you, Boris!) do not have much knowledge of the above said. It is especially irritating when a programmer takes much trouble to get better sound from the ST and that this is recognized nowhere (I am hereby thinking e.g. of "Sapiens", a French program with good, three voice digital music in the background). Enough smalltalk. Since there are, like you surely must have heard or noticed, methods to create something better than obnoxious bleeping on the YM-2149. As usual, the software has to do the work here. So let's look at the principal operation of a synthesizer routine.

First, the program should run on the background, "on interrupt", so that the music can be played simultaneously with the program. This also has the advantage that the sound processing routines are executed regularly. In the ST, the 200 Hz timers can be used for this, or, like with our program, the VBL (Vertical Blank Interrupt); this one is executed 50 (or 60) times per second (70 times in monochrome mode, ED.). Principally, such a program doesn't do much more than getting notes and note lengths from a table and writing this (converted through a frequency list) to the soundchip. Since the routine is executed regularly, it is also possible to change the soundchip data regularly - this creates the effects that can normally not be done by the soundchip itself. In the synthesizer routine that can be downloaded from this website, the following effects are built in:

All these manipulation possibilities together bring a remarkable effect from your speaker; just listen to the small demo song that is added at the end of the listing.

Before Jochen will start explaining all there is to know about working with his program, I will talk briefly about the operation principles of the "digital synthesizer" I mentioned earlier. This miracle of programming art (cough cough) gives the ST similar sound capabilities than the Amiga, but it costs a lot of processor time. In memory, just a single digitized sound of any instrument is needed, and the software can play that on various lengths or frequencies. Up to four of these voices are then mixed together and played through the soundchip. Only the volume register, that is misused as analog-digital converter, is applied here. The whole thing still runs "on interrupt", but one has to know that this method of creating sound costs about 70-80% of the total available processor time. How it functions precisely, will for a time remain our secret - we don't want to give away all the cookies! Instead of that, I will now give the keyboard to Jochen, who will now talk about the principles of his listing.

Greetings to all you music freaks! This is Jochen on the keyboard. In the next piece, you will be able to read everything about how to use the assembler source. I am afraid you have to type in all notes and effects directly in the assembler, as I didn't have the time to write a user interface for this synthesizer. By the way, I do it manually with my "big" synthesizer programs as well, that I use for our demos and for commercial pieces of music. All songs are directly edited in the assembler. So here we go...

Preface: This program should only be used by people that have experience with programming in assembler.

Three pointers to the sequence tables. The sequence tables: Every voice can create seperate sequences after each other, just like in a string. Each time, they have to be ended with the byte $FF. The numbers specify the numbers of the sequences meant. However, when the seventh bit is set, then a "transpose" byte is meant. The lower 6 bytes then specify the height.

Every note starts with a signal byte of which every bit takes over a function.
Is the signal byte $FF, than the sequence ends here.
Bit 0 to 4 specify the note length -1 (0 to 31) and are always before a note. A whole note is 32-1, so that would be 31 ($1F). A half note is 16-1, so that would be 15 ($0F), etc.
When bit number 5 is also set, this note will be attached to the previous one.
Syntax :	Signal byte, note
or :	Signal byte, waveform number, note
When bit 6 is set, the program knows that this is a pause.
The syntax of pause is: Signal byte.....
When bit 7 is set, the program expects the number of the waveform
Syntax :	Signal byte, waveform number, note

At the start of each sequence, one should select the waveform anew, or else the old one will be used.

In the signal byte, bit 7 is set, i.e. a waveform number must be specified (in our small example, this is $00). The lower five bits form number $07, i.e. a quarter note ($08-1). Then, the note always follows. $18 means a C'. The next signal byte is again $07, so yet another quarter note... This continues several times until the $FF byte - the sequence ends here.

Arpeggios are rapidly following note heights, that have to be set in this table (with Arpeggios, it is possible to simulate chords). An Arpeggio exists of a number of note steps, that are called after each other. Every Arpeggio step functions just like the same principle as Transpose (see Transpose). If one would want to simulate a Dur-chord, for example, the numbers should look like this:

The specification number can be calculated by the position it has in the list, minus one (in our example on the fifth position, so 5-1 is 4!). This specification number we'll have to put in the "wavetab" table.

wavetab: dc.l pointer on the wave tables....
wave0
	dc.b
		1st byte => The Arpeggio specification nr.
		2nd byte => The speed with which the ADSR waveforms should be handled...
		3rd byte => Vibrato speed (1 = fast,100 = slow)
		4th byte => Vibrato strength (1 = weak,100 = strong)
		From now on, the ADSR waveforms follow, according to the volume registers of the soundchip.
		This table also ends with the byte $FF.

So far everything's alright. I hope it can be understood. Have fun with trying and experimenting!

So that's yet another part of "The Wizards", dear readers. Next time, we will not spoil the ear, but the eye: Graphical tips and tricks can be expected. Till then, bye!

A last note for those among you who do not know much of working in assembler: After having loaded the SEKA assembler, you can load the source by typing [R], [Return], and then the file name (followed by [Return]). Then, you type [A] (followed twice by [Return]). Now, you must switch to supervisor mode. This can be done by typing "XSR" [Return] and "$2300" [Return]. Now, you can start the program by typing [G] (followed twice by [Return]). You will then hear the sample tune!

The fourth part of this highly popular series is here. This time, ES will talk about some graphic-tricks like transparent graphics, anti-aliasing and more like that. Many thanks have to go to Mr. Tarik Ahmia (68000'er/ ST Magazin) who gave permission to use these articles in ST NEWS.

Hi de hi, readers! Have you gained enough energy for yet another round of TEX-tips? For this part you don't even need specific assembler knowledge, since it mainly covers my personal field of expertise: Graphics. Some of you might now think that there's rather little left to be said about that; many pages in books as well as magazines have been filled with the subject already, aren't they? But I am sure that there are some more or less rare tricks and tips from which you didn't know anything, or are you familiar with:

You don't know anything about this? Then it'll be soon - just read on. Additionally, I will tell you something about the Neochrome drawing program that you surely didn't know. Just like all earlier episodes in this series, all things said refer to the low resolution of the ST, where you can normally use 16 colours (readers of ST NEWS Volume 3 Issue 5 will now of course chuckle lightly).

Well, let's start to talk about the subjects listed above systematically. "Anti-aliasing" is listed first there. This is commonly used in professional circles of computer graphics artists. Freely interpreted, this would mean: "How the heck can I avoid that gradation in my computer picture?" You all know that the ST, just like its colleague homecomputers, has a fairly limited screen resolution. This means that especially diagonal lines or circles show typical gradations. Since we cannot fool the hardware in this case, we'll simply have to fool another "peripheral": The human eye. We can hereby use the way an eye sees contrast. When anti-aliasing, one uses the following scheme: At the boundary of two colours, one insert some dots on the gradation that have colours in between the two colours that you use. That's all. To demonstrate the remarkable effect, please make a little practical exercise. You surely have a drawing program with a zoom function. Load it and define the following colours:

Now just draw a triangle with drawing colour 1, and therefore draw three lines, for example for the upper left corner (position x=0 and y=0) to position x=20 and y=80, then back to x=0 and y=80 and then back to the upper left hand corner. Fill it as well, with drawing colour 1. Now, a bright red triangle is on your screen of which the right side clearly demonstrates the typical gradation. Now copy this triangle, so that you have two triangles next to each other on the screen. The second one will now be anti-aliased. Enter zoom mode again and select drawing colour 2. Put one dot of this colour on each "stair" of the gradation at the right side of the triangle. Then select drawing colour 3 and do the same, and a third time with drawing colour 4. Now you have added three darkening red colours to every gradation. Leave zoom mode and look at the effect. The difference is quite stunning, isn't it? The second triangle seems to be displayed in a much higher resolution than the first one. That's anti-aliasing, quite simple! When you'd like to experiment a bit more, you can draw a filled circle in drawing colour 1 and again put the darkening shades of red on the gradation steps. You will then also develop a feeling of where you can put which number of anti-aliasing-dots, since a circle contains all different gradation sizes. Using this technique, all graphics can be enhanced if the colour palette has been properly designed. In our example, black (000) was the background colour, bright red (711) the drawing colour and 2-4 were the anti-aliasing colours. Have fun experimenting with these effects!

Now, what's up next? Ah! Colour palette animation! First, let's start with a small explanation what this actually is. The ST has sixteen colour registers; when some or all of these are swapped in a cyclic way, this is called "colour cycling" or palette animation. This is often used to simulate flowing water, and one of the oldest Neochrome pictures, "Waterfall", is a typical example. In this case, the shades of blue contained in the water are swapped in a circle. But there are much more possibilities with palette animation. I have always had the dubious pleasure of creating effects with this that many people considered to be graphic programming. A very nice application of this technique can be found in the TEX program "Super Neo Demo Show". There is a scrolling text in the lower border of the screen, and under that are a lot of small propellers. After this introduction you will probably not be surprised to hear that these rotating lines are nothing but palette animation. How it's done? Well, it's quite difficult to put into words (like love, ex-ED.), but I'll give it a try. Just imagine that you've drawn 12 lines that cross one another in the middle; each line has its own colour. Now, you set all colours to black with one exception: One colour remains e.g. black. In the middle you put a small circle with a non-animating colour to cover the part where all lines cross. If you now let these 12 colours cycle, you have the impression of a rotating line, since only one of the 12 lines is displayed in red at a time.

There are more tricks of this kind, e.g. the hopping dots in the 2nd Psych-O-Screen of our "B.I.G. Demo", but they principally all use the same trick: About all used colours are put in background colour, and only some of them are coloured, by palette animation, movement starts. One can use this to such extend that an animated figure, e.g. a little man, walks across the screen. The method is the same; you draw the movement phases in another colour at each time and you set them next to each other (they should not overlap). Since each of the men "lights up" after the other due to the colour animation, it appears as though the shape walks across the screen. True animation effects can thus be accomplished by animating the colours. The disadvantage of this trick is obvious: When you use a lot of colours for colour animation, only few are left for the rest of the picture. But that's each one's own decision.

Well, dear readers, now we're really starting. The previous was only to be classified among "harmless toying around", but now we're really cookin'. Maybe you have seen graphics that seemed like transparent glass or that seemed to float in some of our programs. Maybe you wondered which wonderful and difficult program sat behind it all. Ha! All wrong! I suppose you're just about used to it, but this is also covered by a sleazy trick. But to understand it, you must know something about the graphic buildup of the ST - so I will mention it here in short to refresh your memory. In low resolution, it looks like this: A certain piece of memory is referred to as "screen memory". There, four sequential memory words (1 word = 16 bits) always belong together, and each word represents a so-called "plane". It's best to imagine these four words lying under each other; this way you see best that each pixel is represented by four bits. According to this combination of bits, the colour value is taken from one of the sixteen colour registers. With a resolution of 320 x 200 (640,000 pixels) of which each pixel can take one of 16 colours, each plane is therefore 8 KB in size; an ST graphic screen thus costs 32 KB. These planes do not only have to be used to represent colours, but when you truly look upon them as "planes" and use them like that program-technically, there are some interesting aspects. Let's presume we made a piece of graphics that only uses eight colours. These colours can be realized with only 3 "planes" (3 "stacked" bits mean 8 combinations possible), so that their colours will be found in colour registers 1 to 8. But there's one plane left! In this plane, it is for example possible to display a piece of graphics that only uses one colour. When we set colour registers 9-16 to the same value, we can move this piece of graphics in just one plane (the program only uses each fourth word) and the corresponding bit combinations only give the colours in register 9-16. That's how it is possible to put a single colour piece of graphics on top of one that has 8 colours without difficult logical operations. That's all.

Oh, I hear you call: "What's up then with transparent effects, and fore-and background, eh?!" Well, program-technical nothing else happens than what I just described above. All else is simple brainmangling thought about setting proper colour palettes. Again: Transparent- as well as back- and foreground effects are now only realised by simply setting proper colour palettes! Therefore you must thoroughly realize what's happening with the bit combinations when a piece of graphics in one plane is moved "over" the three others. The colours that result into the corresponding effect are always the last eight (number 9-16), the colours located that are called by the corresponding bit combinations are located there. These are the colours that appear when the separate plane is moved "over" the other three - in other words when the fourth bit (fourth plane) is set or cleared. When you understand this, it is easy to think of a way to create the "transparent" effect: Simply put intermediate colours in the upper half of the palette that correspond to the brightness of the other eight. In our program example a bright red "plate of glass" moves over a background pattern that only uses shades of grey. The colours are hereby set as follows: Colour 1-8 are black (000) along all shades of grey to white (777). The "transparent colours" 9-16 go from dark red (004) to yellow (770). So when the one colour graphics block of the fourth plane goes "over" the other three planes, colour 9 appears where 1 used to appear, 10 where 2 used to appear, etc. Program-technically speaking, this is very simple, but about that we haven't even talked. Udo and the others were also quite blabbergasted when I came up with the idea, you'll believe me. The whole back-and foreground business is very much the same; just look at the B.I.G. scroller in our "B.I.G. Demo" where a scrolling text scrolls in between the fore-and background. With this effect, one has to set the upper eight colours as follows: With each of the colours that the one-coloured piece of graphics should go behind, you set the corresponding upper colour to the same. All colours that should be covered by the graphics block should get the value you want them to have when they move "in front" of it. So if you want the one-plane graphics block to move all in the background of all three other planes, one sets the upper colours exactly the same as the lower ones. Not really simple, you think? Hmm. You might be right. But we do everything to get the very last thing possible out of the ST, don't we? With this effects, it is also not quite simple to put it into words (sigh, ex-ED.). When you have a look at our listing, your last doubts will disappear. The program does the following: It builds a background pattern in three planes, thus using the first eight colours. It then makes a graphic block in the fourth plane move to and fro. Using keys [1] - [4], it is possible to call different colour palettes, that will support the description I have given above. By only pressing these keys, the following effects are realised:

[1]	Palette 1	one-coloured block moves over graphics
[2]	Palette 2	block moves in background
[3]	Palette 3	block moves through the pattern
[4]	Palette 4	transparent block moves over graphics

Have fun trying. It is easy to use some of your own colour palettes; some extremely funny effects can be created that way.

This almost made an end to this issue's "Wizards" article. But at the end I found it necessary to make a plea. No! Nothing like "Tortured ST users everywhere get together!"; it is much more about my favourite drawing program that I (and many others) think is one of the most grotesquely underestimated programs on the ST. I'm talking about Neochrome here, that was supplied with the Atari ST in the early days (version 0.5). It was supposed to be sold in the better version 1.0, but it was never properly marketed. Most salesmen also considered 1.0 to be public domain and that's why just about every ST user could get the program. The reasons why the program is so good will be explained to you in just a little while, when I will tell you something about the program that most of you probably didn't know. The basis is actually brief: Neochrome already includes (almost) all functions one would need for creating good pictures; unnecessary functions are not present and it is fast, very fast. It has several functions that would even make "Degas Elite" look rather basic. When you've drawn pictures yourself, you'll have to admit that the most important tool of all is the zoom mode. On the contrary to all other drawing programs that are available, Neochrome has a zoom mode that is always present, also when you operate on blocks, draw lines, fill, etc. This zoom mode is very fast, by the way, because it uses raster interrupts. Further, the "jackknife" function allows you to cut out whatever form you want (not just polygons), and these can also be moved in the background ("DPaint II" on the Amiga can't even do that!). I suppose you already know the functions that are implemented on the Neochrome menu. So I will now talk about some functions that are not so obvious; you might be in for a surprise! Many things, for example, are hidden in the right mouse button: In the "normal" block menu, the current block is set on the current position, but with "jackknife" you can draw with pressing the right button, just like a brush (and, unlike other programs, this also happens fast)! While in "brush" mode, pressing the right mouse button takes care that you draw with the colours that have been installed between the "colour arrows" - this is also the case when using nozzles (highly effective when using colour animation). When you're in "grabber" mode, you can get the colour of every pixel on the screen you want by pressing the right mouse button. In "line" mode, the current line is deleted when you press the right button with the left one. When double-clicking the right mouse button on the eraser icon, the entire screen is erased.

But now a very hot tip, since only few people know that there's a complete animation tool in Neochrome! Dave Staugas, the programmer, had no time to make it completely bug-free so that he just hid it. This is the way to get the new icon on the screen: Go to the "grabber" mode and click with the right mouse button precisely in the curve of the last "R" in the word "GRABBER" that will appear on the right side of the menu. A small camera appears! You can now do the following after selecting that camera: You can define an animation area with the mouse. With the right mouse button you can now slide the whole picture through this area. When you have the right part, you simply click on "add" and the part of the picture is in "animation memory". Add as many pictures as you want, and then you slide the cutout back on the first cutout (only Dave knows why) and you can use the arrows to play the animation forwards as well as backwards. With [Del], it is possible to delete the current screen, and "Load" and "Save" also work (just don't get startled when the fileselector box is busted - stop animation before!). Just experiment a little with the animation tool; unlike all other animation tools for the ST, this one's easy to use. The biggest advantage is that you can edit a figure that has to be animated right in the drawing program. But be warned: This new menu option is not bug free! It is for example not quite smart to press the [Undo] key or make the menu disappear while the camera is selected. So it's probably better to save your picture before you enter the animation tool. When you have the very old ST demo with the flying parrot, you can load it without problems. But do not forget to load the accompanying picture before (the shore landscape) with regard to the colour palette.

Finally, a little gag: You can define the colours in the menu yourself! When started up, Neochrome looks for a file called "NEO.CMP" in which 512 words with colour values need to be that will replace the preset palette. When you intend to use Neochrome more often in the future, look into your heart and give good ol' Dave something for his trouble and his really good program. He is currently a system programmer at Atari and quite disappointed about the fact that his excellent program wasn't treated accordingly in the magazine - and we're not even talking about the lousy marketing. Financial contributions can be sent to:

ATARI Corporation
Personal Mr. Dave Staugas
1196 Borregas Avenue
Sunnyvale, California 94088-3427
U.S.A.

If you're a Neochrome fan, do not falter! Dave wrote to me that he will consider rewriting old source stuff and making a better Neochrome version if the "fanmail" is accordingly. I beg you: Do so!

Well, dear readers, again we have told you some of our tricks, but the crown on our work of "hardware torturing" has yet to come; we're hereby talking about getting rid of the lower border so that graphics can be displayed there as well! Using this trick, you will be able to effectively display more lines than ever before anticipated by the developers of the ST. Just wait for the next episode... Bye, bye.

Unfortunately, this is the last episode in this remarkable quest through the land of programming tricks and things that were earlier thought to be impossible. We have seen smooth horizontal scrolling, techniques on how to use raster interrupts, a brilliant sound synthesizer by the best music programmer on the ST, neat graphics effects and now....the explanation of how one can use the lower and upper border for graphics! Now this series meets its end, the ST NEWS editorial staff would once again like to thank Tarik Ahmia (ST Magazin/ 68000'er) for his kind permission to have us use these articles as well, and of course to our good friends The Exceptions who have co-operated very well - and even more!

Well, so this is the last episode. Yeah, this is now truly the last part we write in the "Wizards" series. Never again I (Erik) have to write these weird prefaces. Finally, your machine's hardware is left untortured - but this will not happen until we have torn some more effects from it! I am not sure if the ST's designers knew what can be fetched from its meagre video electronics. You will now surely think we will finally tell you how the lower border can be removed: You're right - cause that's what we told you all the time after all. And we have not only decided to explain to you how to remove the lower border, but also the upper border! I am convinced that you will wonder how one would get the crazy idea in one's deranged mind to go and display graphics in any of the borders. And that even while the Shifter chip really doesn't have that much facilities to achieve this! Hereby I should say that it wasn't us that came to this idea, but someone from Mannheim, about two years ago, calling himself Alyssa (Hi Sven - still alive?). He spread a rumour that he had succeeded in displaying graphics in the lower border and of course we did the only sensible thing: We declared him insane. But a short while later we had to swallow our words: He sent us a sample and we had to admit: There was definitely something down there! We looked at the source with shaking hands and examined the method that he used. The specific explanation of the trick will follow in just a sec. We were stunned, but didn't falter to start and enhance Sven's method, so that we can now even put graphics in the left- and right border and even everywhere. But we want to keep a few of our secrets, so Gunter will now tell your everything about the control of the electron beam and not everything about the border programming.

Hi, dear readers, this is Gunter behind the keyboard! Our last episode wasn't really staggering insofar as that it wasn't really technical. But we're featuring three listings here! This time, we're talking about the upper and lower border - better put: Not the borders, but means to get rid of them. Let's start right away with the lower border. I hope you still have the article about raster programming (ST NEWS Volume 3 Issue 6) in mind, since we're going to use that here again. To remove the lower border, you must switch to 60 Hz in the lowest screen line (number 199). Shortly afterwards, in the left border, you must again switch back to 50 Hz. It is very important that this happens at the right time! When the switch point is somewhere in the screen, the graphics will be damaged. So dig out the rasters and turn them loose. Those of you that don't know the article about raster interrupts should know that "hblon" activates the rasters. The program is now adjusted in such a way that an interrupt is cleared every time the right border is found at line 198. Then, the program jumps into the "newtb" routine: This is where it gets to be interesting. Then we wait for the right border at line 199 (last "official" scan line). That's why the interrupt has to be cleared one line earlier. After the waiting loop, we switch to 60 Hz. After a short pause we go back to 50 Hz. That's all. The lower border should now be gone. Screen memory continues as usual - i.e. $7D00 bytes after the start of screen memory, memory for the lower border starts. You can for example build in the scrolling routine of ST NEWS Volume 3 Issue 5, and now you have a nice border scroller. In the sample program (LOWERBOR.S), the lower border is just removed and filled with a pattern.

Let's now get on with the upper border. Here, it is not all that easy as with the lower border. There is a very simple method, but it is strongly dependent on your monitor as well as your computer. To put it differently: The thing fails up at half of all STs. The graphics are most of the time damaged, and a routine that should combine into a removal of the lower border doesn't function anymore. So if you see a demo (not one of us, for sure) that has these effects, they surely use the wrong method. Enough slandering - I will now finally reveal to you how it's done the right way. With our routine, improved by Andreas from Level 16, it is not possible to open the entire upper border. There is a certain point that is - depending on computer version - 13 or 29 scanlines above the regular screen where you can open the upper border. Yes, you're right. Unfortunately there are two (I hope there aren't more) different computer versions. The MMU is really to blame in this case, because you use the MMU in all this border stuff, and not the Shifter, which often gets all the attention. The MMU "decides" in the ST when the Shifter should display graphics and when it should display borders. The Shifter itself is totally dumb. Even in the border the MMU must supply it with a continuous stream of zeroes. Here the MMU is "persuaded" not to give zeroes but graphics memory to the Shifter. Well....now for the upper border. One cannot undertake anything against the individual MMU versions, but one can get the computer to display the upper border in all cases through a little trick. So we simply built in the known 50/60 Hz switches on 29 and 13 lines above screen start. The border will then surely be thrown open. Depending on the computer version you own, you will have 13 or 29 lines extra. The second switch does not interfere, luckily. But now there's another problem. I talk constantly about switching before screen start. Unfortunately, you cannot clear an interrupt there, since Timer B only starts at the screen start. There's nothing you can do about that, so you'll just have to "spill" raster time and clear an interrupt in the last possible raster line. Then we simply wait the correct number of lines to switch off the lower border. This waiting loop is done the best way when we wait x * 512 clock cycles (the time needed to draw one scan line). Look at the file UPPERBOR.S. But you can also open the lower border to use the waiting time efficiently. Don't think that you can only open the upper border in combination with the lower one. It's only opened to save processor time. A second raster is in fact set 47 scan lines deeper. This second raster (newtb2:) is located on the last possible line, that is not reached on all STs. Here, we now have to start our waiting time loop. If we hadn't opened the lower border, we would have had to wait another 47 lines. The first waiting loop ends 29 lines above the screen. Here we will try to open the upper border just like we opened the lower one. Then we have to wait another 15 lines, and then we have to try our luck a second time. Alongside the old level 4 interrupt is restored, which is only needed when executed the first time. From now on, both Timer B routines call one another. After the second trial of opening the upper border, we load the Timer data registers with the value 199+13. We then get back to the precise location where the lower border starts (13 lines upper border + 199 lines regular screen), and the circle closes itself.

In the listing, some control colours are added where the borders are switched on and off. Between green and white, the lower border is opened. The two switch points for the upper border are located between white and red as well as red and green. Now you can see which MMU version you have. Depending on the version the pattern starts after white or after red. We have experienced that especially old STs have 13 lines more in the upper border, while the new models can usually achieve 29 lines. Therefore, these have a smaller lower border.

Hi. Here is Erik again. They told me I should write some final words of farewell. But why so sentimental? We have had good fun writing for ST NEWS, and who knows....we might get back in the future, revealing even more tricks! If you think the articles were nice, just write to the ST NEWS correspondence address. If you think they weren't, well....write as well! We hope you liked our style. Maybe, these articles even helped in increasing the overall quality of ST software? I don't know nothing to write now anymore, so I will close down. Maybe, we'll "see" one another again. Bye!

This text was published in the Atari ST diskmag "ST News" and is used by kind permission of Richard Karsmakers. Source for this article: http://www.st-news.com

Example:	$8C	<= The voice is transposed with $C half tone steps up
	^
	Bit 7 set...

arpeggiotab:
		dc.l arp0,arp1,arp2,arp3,our_table
arp0:....
arp1:....
arp2:....
	arp3:....
our_table:
		dc.b $01,$0c,$07,$04,$00,$ff			=> End mark $ff
			^	^
			^	-----------------Our Dur-Table
			maximal speed (1 => fast 3... => slow)

Background colour	000
Drawing colour 1	711
Drawing colour 2	600
Drawing colour 3	400
Drawing colour 4	300