ST Demos (1)

See it? See that huge pile of old knackered disks lying in the corner of your room? Just over there near old those expensive boxed games you played through after a week? I bet you a fortune that if you ever owned an ST, you kept all those old DS disks - because they have demos on them (or Maggie). No-one ever seems to format (good) old demo disks - because they were free, unlike all those games we played. Probably. So here comes Maggie to answer all those useless questions: How the hell did they do that on an ST?

Eight megahertz was never enough to really do all those things you saw in demos: they were all merely illusions... you *thought* you saw huge amounts of screen data being shifted, but most times it was a combination of clever tricks and fiddling with little-known hardware tricks. Parallax scrolling in the Cuddly demos? An illusion! So sit back, read on, and see how they did it...

N.B. Anyone wishing to know how a specific effect or demo worked, let us here at Maggie know (demo name/ screen name) and we'll publish the secrets (and source code if possible) in a further article. Amiga demos don't count: their hardware was designed for cheating!

Part One

(Borders and Scrolling, ColourShocks)

1.1. Borders

The staple of demos was the ability to do what nearly all games could not. Therefore, opening borders was the staple diet of a demo. Unfortunately this process was nowhere near as easy as it sounds: therefore we'll need to introduce you to some theory as we go along... you have been warned!

1.1.1. The Bottom Border

The bottom was the first to go: the first demo I remember with a removed bottom border was The Exceptions' BIG Demo (although I believe they did a slideshow demo before this) The method is surprisingly simple...

Unlike the imfamous reply to a reader's question in ST Format, the method of opening borders is NOT to switch the whole system into 60Hz NTSC mode to get a bigger screen (!!) In fact, the principle of border removal is the same in all cases: at certain points, the video chip would perform certain checks, a bit like a piece of software, to determine whether phases of its operation should change (i.e. starting or stopping the screen display.)

At the bottom of a normal screen, after the final line becomes border, before the next line appears, the video processor checks that the ST was set to 50Hz (PAL) mode. If it was, then the processor output no more screen data. By quickly flicking into 60Hz while no screen data is displayed, then switching back to 50Hz, the processor is fooled into displaying more screen data until it reached the point where all display is automatically cut off (38 lines later, I seem to remember.)

Voila! No bottom border. To see how programmers determined exactly how to write a program that switched 50Hz/60Hz at exactly the right time, see "Screen Synchronisation."

1.1.2. The Top Border

This is slightly more difficult, due to the way that processor interrupts and video display was set up, but the principle is the same: switch into 60Hz very briefly, then back into 50Hz (once only). Early attempts at this were not very reliable (anyone see the Whattaheck Demos?) but more of this later.

1.1.3. Side Borders

Yuk! Ever wonder why the Lost Boys, probably the best "pure" coders of early ST days, hardly ever did fullscreens? Because it was a total nightmare, that's why. People went to great lengths to give the illusion of fullscreen effects by using rasters (see later) - I remember a Level 16 demo as being the best example of this, and the ICE STe demo reviewed in Maggie 20 also uses a similar trick, nearly 8 years later. "So Des,
how did they do that?"

Knowing the way that a monitor displays graphics (i.e. left to right, then next line, etc.) you should be able to work out that you need to repeat the process of opening borders EVERY SCREEN LINE. Not only that, but the precise times at which the switches needed to be made were much more exact than the processes for top and bottom border opening. In fact, they really needed a precision of 4 processor cycles - the speed of execution of the fastest 68000 instruction possible!

The process then involved synchronising the processor exactly to the screen display (see "Screen Synchronisation" again), then analysing your code to add up exactly how long each instruction takes... therefore programs using conditions (i.e. IF...THEN type statements) were impossible, and to make matters worse, the original execution speed lists published by Motorola were incorrect. Typical.

Side border removal was notoriously unreliable. No sooner had groups managed to make one type of removal possible, foreign machines would fail to be compatible, and when the STe came out... everyone started again. Reliable border removal code was a closely-guarded secret. Good job we all had ripper programs, eh?

1.2 Screen Synchronisation and Rasters

Ok, time for a little diagram, then some explanations:

This diagram shows more precisely how the video system operated. Most readers will have heard of the VBL (Vertical BLank) interrupt: the processor will stop each time the video processor restarted sending a frame of screen data from the top again (50 times a second on a PAL system), jump to an address defined by software, and do whatever the programs in ROM or RAM want. Then it returns to what it was doing beforehand. That's what an interrupt is. Interrupts are also used to process keyboard/Midi data, disk access, or internal clocks. In demos such other interrupts were switched off because they stole time from raster effects or complex calculations. Leaving a keyboard interrupt enabled with rasters, then moving the mouse, caused the rasters to wobble up and down - a source of much hilarity.

Similar to the VBL is the HBL interrupt (Horizontal BLank) which occurs every time the video processor restarts processing a screen-line (even when in the borders or past the top/bottom of the screen - video processors don't take a rest.) This was usually switched off: interrupting the main processor every line slows the ST down significantly.

1.2.1. Rasters

In addition, there was another way to cause an interrupt, called the Timer B interrupt, which only occurred when the screen display itself was on (i.e. not in the top and bottom borders.) By changing the background (or other) colours with this interrupt, it was possible for raster effects: more than 16 colours on screen, for example. This was a bit pass‚ though: but you got a hell of a buzz the first time you got it to work. From then on ("Wow! I've bent the limits of my ST!") most people who did it were hooked.

1.2.2. Syncing

Now, back to the theory: The time-relation between the start of the VBL interrupt and the point in time needed to open borders was fixed, but not accurately enough for side borders. A more precise method of being accurately able to know where the video processor was when you changed a colour was needed... hence "syncing." This relied on a stunning coincidence (not really): every 4 pixels on screen corresponded (almost) exactly to 4 processor cycles of the main 68000 processor. In addtion, the 68000 could read exactly which section of screen data was being processed at any specific moment... So... By using a piece of code which code vary how long it waited depending on where the screen was up to (either a Shift-instruction or jumping into a long list of dummy instructions at a variable point) the coder could change a colour at EXACTLY the same point every frame, or reliably do the necessary switches to remove side borders. The left one went first, the right one later (it needed two switches!)

1.2.3. ColourShock and Plasma Effects

The ability to change background colours gave an added bonus. If we did nothing but continually change the background colour (as long as we switched off any interruptions to it) we get a repeating pattern of colour, that we could overlay the other 15 colours over. Later we could distort the pattern by jumps of 4 pixels left/right, by inserting short paused in the code (the distorting plasma effects.) Later single colours in a picture e.g. the insides of lettering, were also changed in this way. See "Plasma" in a later article for other variations on this.

1.2.4. Sync Scrolling

A real buzz-word of demos in the days of the ST. Basically this was the ability to hardware scroll to an accuracy of 2 bytes. But the normal ST only allowed screens laid on boundaries of 256 bytes - just over one normal screen-line, which required 160 bytes. 256*5 bytes came to 1,280 bytes, which was exactly 8 screen lines, so you could hardware scroll up and down 8 lines at a time, but this wasn't really good enough, and sideways scrolling was impossible... or was it? Enter Sync-scrolling.

The great Swedish crews Omega and The Carebears take the credit for inventing the new technique. They realised that a screen line with the side borders opened took 230 bytes (70 bytes more), while one with only the right border removed took 192 (32 bytes more.) By opening the top border and playing with these numbers (multiples of 256,70 and 32) they managed,

- by opening both borders for 'x'-many lines.... by opening both borders for 'x
then the right borders for 'y' many.... then the right borders for 'y

.... then adjusting the base screen address by 256*'z' bytes, you could scroll the screen to multiples of 8 bytes!

Later, more sophisticated forms of the sync-scroller appeared using more types of border opening (e.g. left border only, leaving the processor in 60Hz for a tiny bit longer) that reduced the number of screenlines needed to do this effect to around 9-10 lines, and to an accuracy of 2 bytes. Stupid amounts of effort were expended to squeeze that extra free line of processor time, but we were all very sad people then...

Page maintained by Steven Tattersall

Pages hosted by Zetnet