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!
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."
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?
| Non-Visible Time | ^
| Top Border Area | | (Not to scale,
|ÿÿÿÿÿÿÿ|ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ|ÿÿÿÿÿÿÿÿ| | obviously!)
| |/Normal\Screen| | |
| |\/\/\/\/\/\/\/| | |313 scanlines
| Bottom Border Area | |
|ÿÿÿÿÿÿÿÿÿÿNon-Vis Timeÿÿÿÿÿÿÿÿÿ| V
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.
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...