The basic way to display graphics on the Atari ST is to copy some screen data,
in bitplane format, straight to the area of RAM that has been set as screen
memory.  The ST's video architecture then gets to work and does the rendering
for you, fifty times a second, like magic.  If your graphics do not then need
to update, you can sit back and your image will be displayed on screen - no CPU
needed!

However:  
We made this demo for a special competition at Sommarhack 2024 where it was
against dem rules to write *any* screen data to screen memory *at all*.  A
blank screen.  A zero bitplane demo!  How can one make effects like this?!

The way we do it is through switching the background colour, just like in old
fashioned rasterbars.  Rasters use interrupts to wait until typically the
beginning of a specific scanline, at which point a tiny bit of code changes the
background colour.  This produces the visual effect of a horizontal "line" of
colour across the screen.  

Our demo uses exactly the same principle.  However, rather than waiting until
the beginning of each line and then changing colour for the whole line, we use
some well known code tricks to synchronise our code to the electron beam
first.  This means we then have absolute control over the position at which we
change the background colour.  We're no longer limited to the very start of
scanlines, and can change colour much more frequently with stability.  This
allows us to "draw" little lines of colour on the screen (e.g. 8x1 pixels),
which we can then stack up on adjacent lines to form chunky "blocks" of colour
- like big pixels!  Effects are possible!  Hurray!

But is it all that simple?  Well....... in short - no.

The single advantage of this approach is that we can display as many colours as
we like on screen from the ST's 512 colour palette.  Awesome!  And we can also
do stuff in the left/right borders very easily, without even having to worry
about opening them.  Great!

The disadvantages and limitations, however, are major.  They include the
following:

1) To make a longer/shorter tiny rasterline on screen to build up our chunky
images, we use instructions of different speeds to do the colour writes.  The
more CPU cycles an instruction takes, the longer the "line" of the previous
colour is displayed for as the electron beam moves across the screen
left-to-right.  However, for technical reasons, these "lines" are limited to
multiples of four pixels in width, starting with 8x1 pixels.  Even then, there
are additional limitations when using 8x1 lines around how many colours we can
display each screenline.

2) Similarly, we can only "move" stuff around horizontally (more accurately:
create the illusion of horizontal movement) in 4 pixel intervals.

3) Look closely - you'll see some 4x1 lines/blocks too amongst all the chunky
crap!  This switch should be impossible and uses a super smart method devised
by Mr. Nyh!  But as awesome as it is, the method comes with even more
limitations about what can be done where.

4) And the biggest issue of all.....  
Unlike when bitmaps are displayed, where you can sit back and do what you like
with the CPU in the background while the ST does the rest, all of these display
methods eat 100% CPU while they're active.  Unlike on certain rival 16 bit
computers, we can't outsource this job to other parts of the hardware!

This is a tremendous pain in the ass, especially when we're using the whole of
the visible screen area for effects.  This is because in these instances, we're
doing nothing but using the CPU to change colour for the vast majority of every
screenline.  That means we have to fit our actual effect code either above or
below the visible screen area, or when the electron beam is off the edge of the
screen in the non-visible area.  So not much CPU to actually do stuff with.
Ballache!  And you can forget using SID voice/timer based music, unless you're
willing to make even more concessions...

To summarise: what you see here is a combination of brute force CPU burning
colour switching, packaged up with some brave attempts at lateral thinking from
both a gfx and code perspective.  We hope you enjoy it!

Real hardware is recommended to watch this thing on.  However, if you simply
must use an emulator, we recommend the latest version of Hatari, as Steem does
not emulate this demo fully correctly (hi Troed!).