Using an Amiga in 2021: Making an intro

Summer 2021

Contents

Introduction

Every once in a while, someone asks about my interests. I usually just say I'm into home computers from the 1980s and, since most people are very nice and polite, they then ask what I do with them. I usually say something about competing in computer graphics at "digital art festivals," because explaining what the scene and a demo party is can be somewhat tricky. That's usually when they stop asking questions. Nevertheless, I am the boss of my own home page, and I've decided to detail how I spent my spare time during a few weeks before easter this year.

Because of COVID, (almost) all demo parties have moved online until further notice. It's a bit boring, but it's better than nothing. The German party Revision is currently the biggest of its kind in the world and I decided to make an entry for the Amiga intro compo.

Istari - Space Swap

A screenshot from the running intro, complete with a visit from Miss Spellings.

Let's start off at the end and consider the final product of my efforts: It's available on Youtube or, if you have an Amiga or an emulator, as a single executable file and an ADF disk image. For Youtube watchers not using the link above but a tool such as youtube-dl, feel free to skip 23 seconds into the video. The long wait in the beginning is the decrunch, but more on that later.

The target platform is an Amiga 500 with 1 megabyte of memory, a 7 MHz 68000 CPU and Commodore's custom chipset for graphics and sound. The production (as we sceners pompously like to call our programs) is an intro, which is a term used for non-interactive audiovisual programs with small file sizes. The file size limit in this particular competition was 64 kilobytes.

I decided to make what's known as a one screener - a production that doesn't alternate between various full screen visual effects, instead keeping the same screen layout during its entire runtime. It's certainly not a technical marvel or big league production, but I had fun making it and ended up on place 7 (out of 11 entries) in the competition, which means it ranked first among the one-screener entries. I'm very happy about that.

For those who wonder, Istari is the name of a (mostly inactive) demo group I've been a member of since 1996. The name is of course from Tolkien's lore: there were five of us and we at least aspired to become computer wizards, so it seemed fitting. We organized a couple of small demo parties in the late 1990s.

A photo from a demo party organized by Istari. Ahh, to be young again, and so on.

Breaking it down

The screen layout consists of three main parts: A logo at the top, a background image and a box with a text writer in the middle of the screen. The logo is presented using a classic logo melt effect, meaning it seems to be poured or "melted" into position from the top of the screen. The logo changes colour before each new "melt". There are also several animations: a spaceship below the logo, the alien's blinking eyes and, occasionally, either a confused groundhog emerging from a hole in the ground, or a small volcano eruption. All the animations are made using sprites.

Making it

A lot of people who make Amiga demos and programs work on a modern PC, using cross-compilers, emulators, drawing tablets and Photoshop. I'm far more stupid and stubborn: I prefer working on an actual Amiga, with a CRT screen and all. I suppose it's like people who enjoy listening to vinyl records or driving vintage cars: It's the feeling, man!

Can you smell the warm plastic? Can you see the 50 Hz flicker? 'Tis truly the way to live!

My main workhorse Amiga is an A1200 with a 14 MHz 68020 CPU and of 6 megabytes of RAM. It's more than fast enough to run all the applications I use and multitask between them.

Jargon buster

I'm going to use a few terms in the text below that might require some explanation. Here goes:

Screens On the Amiga, a screen is the name for the base area on which the computer can draw graphics. A program can open several different screens at once, each of them in different resolutions and colour depths. Screens can be of arbitrary size and they can be displayed simultaneously by overlapping, so that part of underlying screens can be visible behind the topmost screen. This means that you can for example show a 320*20 pixel, 32 colour screen in "low resolution" (I.E. with square pixels) above a 640*256 pixel, 16 colour screen in "high resolution" (I.E. with pixels twice as high as they are wide) at the same time. The maximum colour depth on an Amiga 500 is 5 bits, which means a palette with 32 colours.

Copper The copper (short for co-processor) is a custom graphics processor in the Amiga. It is responsible for setting up and handling screens. The copper can be used to change the value of a given palette index once or several times per raster line. Doing so results in what's called a copper gradient. In effect, this means that a 320*256 screen with a 1-bit (2 colour) depth can be made to display a gradient with several hundreds different colour values.

Blitter A bit-blit, or bit-block transfer, is a method of using specialized hardware to quickly copy large chunks of memory around and apply various rules for the copy, to achieve things like background transparency. The Amiga has such a piece of hardware, which is very useful for copying the whole or part of a screen to a different position on the same screen, or to a completely different screen. It can also be used to quickly draw E.G. filled boxes.

Sprite multiplexing On the Amiga, a sprite is a hardware controlled piece of graphics that's drawn independently of the underlying screen, which means a sprite can move between two overlapping screens. The mouse pointer on the Amiga is a sprite. The Amiga can draw up to 8 hardware sprites simultaneously. They can be at most 16 pixels wide, but have unlimited height. Each sprite can use up to three colours (plus one transparent colour). By employing various programming tricks, one can both display more than eight sprites at the same time and combine several sprites into one, to achieve greater pixel width and more colours. This is called sprite multiplexing.

The Graphics

What I really enjoy doing on Amiga computers is pixel graphics. For this, I use my trusty original copy of Deluxe Paint IV (affectionately DPaint), published by Electronic Arts in 1991. The overall vibe I was going for in Space Swap is that of similar one-screener intros from 1993 and 1994. They all had very particular design aesthetics with lots of vivid pastels, cutesy graphics, playful fonts and a generally cheerful mood. Perfect for brightening the gloomy times of pandemic lockdowns!

Above, we can see a screenshot of Deluxe Paint IV. Along the top edge of the screen is the menu bar, with pull-down menus giving access to many of the program's advanced features. Along the right edge of the screen is the toolbar and palette, where the user can select various brushes, painting modes and tools. The palette displays all the available colours for the current image and lets the user pick the current fore- and background values. The screenshot is depicting the magnify mode, in which a smaller part of the picture is shown at lower resolution on the right part of the screen, and the magnified area is kept visible for reference on the left part of the screen. Most pixel graphicians (including myself) spend inordinate amounts of time in the magnify mode, since nearly all dithering and anti-aliasing is done manually.

As you can see above, the background and logo use a 32 colour palette. The screen mode is 320*256 pixels in the "lowres" mode, which gives square pixels.

The logo

The Istari logo was made by simply typing "istari" in my own custom font (more on that later), scaling it to a higher resolution, smoothing the edges by hand and then rotating it using the Perspective tool in Deluxe Paint. Some depth was added by manually extruding it along the z-axis. A gradient fill was applied to it and then it was just a matter of getting busy with manual anti-aliasing. Below is the logo in varying stages during work.

The background

The background image mostly consists of a starry sky. The gradient from dark to light is a simple line-based one, to avoid the cluttered feeling an overly dithered image can convey. The stars vary between being a single pixel to somewhat more complex, employing anti-aliasing to achieve a small halo. The alien (named Jeff), the mountains and the little "Space Swap" logo were drawn using the freehand tool in DPaint. The moon outline was made using the circle tool. All of this was then filled, shaded, dithered and anti-aliased by hand.

The bright yellow field in the bottom of the sky and the bright blue lava in the volcano and some of the stars are colours that will be changed in the final program. I find it easier to give those a contrasting value when working in DPaint, because it makes them easier to spot.

The yellow part of the sky will use a copper gradient. That's the reason why the mountains aren't anti-aliased there - partly because it's really hard to anti-alias against a colour you can't see and partly because there wasn't any suitable colour values left to anti-alias with.

The bright blue lava and stars will have a flashing colour effect, fading continuously between nearly black and a bright, purplish red.

The animations

Originally, I had just planned for the spaceship sprite. That felt a bit boring, so I decided to add a little space groundhog that could appear randomly across the screen from a moveable hole in the ground. This cheered things up a whole lot, which made me add a small volcano eruption as well. Then, as the deadline drew closer, I thought Jeff looked a bit dull and decided to make his eyes blink - out of sync with each other, of course, because that's just how it works when you're a three-eyed space alien.

All of the animations were also drawn in DPaint, utilizing the animation mode. This is a very advanced feature that lets you add, insert and remove frames at will, jump back and forth between them and also enable a light table mode. Once I was satisfied with an animation, I copied each frame to a grid in a still image to prepare for their use as sprites.

Animation frames for the groundhog, volcano eruption and Jeff's blinking eyes

The music

The sad truth is I lack any kind of musicality whatsoever. Lucky for me, there's a large number of compositions in the Amiga MOD format that are free to use if the author is credited. I opted for Hot Fever by Grim of Digital, a funky little chiptune classic I thought fit very well with the overall mood of the intro.

The font

Since there's a text writer in the intro, I needed a font for the text. I've been working on and off on one I've decided to call Istarfont. I use a program called FEd (Font EDitor) that Commodore shipped with AmigaOS 1.3, but for some reason left out of later releases. The font is quite complete - it lacks some diacritics and other special characters, but other than that it should be fine for most scrolltext writing. Feel free to use it with credits: Click here to download it as an LhA archive.

To use the font in the intro, I had to type all the characters I wanted to write with onto an image file using DPaint. When doing so, I also added a dropshadow to it.

Putting it all together

Cool guys code their scene productions in assembler. Nowadays mostly because you can't beat assembler for speed, but in the old days the prevailing idea was that programming was supposed to be hard and if you didn't do things the hard way, you didn't belong on the scene. As luck would have it, I've never been a cool guy, so these days I can safely use Amos Professional.

Almost Professional

The Amos Professional code editor.

Amos (or more properly AMOS) is an Amiga version of a BASIC dialect originally released for the Atari ST, called STOS. Amos Professional is the last and greatest version of it, containing so many nifty abstractions for working with the Amiga hardware it feels more like scripting in a modern multimedia package rather than doing actual programming work. Want to load and display an IFF image file? Just Load Iff! Want to load and play some music? Track Load and Track Play, baby! It also has easy to use functions for sprite multiplexing, working with double buffered screens, performing blits, manipulating palette values and creating copper gradients.

The Amos Professional REPL, called Direct Mode.

Apart from providing great abstractions for the Amiga hardware, Amos Professional was a very modern and forward-looking piece of software when it was released in 1992. It features a syntax-sensitive editor with MDI, code folding (of procedures) and context-sensitive hypertext help. It also features a REPL of sorts, a visual debugger and several tools for creating, editing and managing graphics and audio.

The Amos Professional debugger, called Monitor.

The logo melt and palette change

The logo melt is a classic effect in Amiga intros. While it can be made using the copper, working with the copper is often quite a hassle in Amos. I instead chose to use the blitter. The logo is actually displayed on a smaller screen positioned on top of the screen containing the main background image. I then copy a single line of the logo image to all the remaining lines above it, which creates the feeling of the logo being "poured" from the top of the screen into an invisible mold.

Since the logo is displayed on its own screen, the logo palette can also be changed without affecting the underlying background. Before each new "melt", the palette is alternated between pink, green, blue and gold hues.

The text writer

The text box is drawn at the start of the intro using the blitter. The flashing frame around it is a single colour in the indexed palette being faded between different values. This flashing is also used for the lava in the volcano and some of the stars in the sky. The text itself is colourized using a rainbow gradient created using the copper.

A rare insight into the mind of a deranged madman: Counting characters by hand in an image file in order to translate them to their corresponding ASCII values. But don't judge me too hard - what are you usually doing at 3 AM on Saturday mornings?

All the text is stored as strings in arrays. Amos does have support for data statements, but it also works very well with arrays and I use them for lots of things such as palette values and sprite frame identifiers. Each character has been programmatically cut out of the font image described above and stored in memory using an Amos abstraction called "banks". The blitter is then used to paste those characters onto the main background, and to clear the text box before starting over on the next screen of text.

The background

The background is mostly a simple matter of using Amos' built-in functions for loading, packing, storing and then displaying an image. The bottom part of the sky is colourized using a copper gradient to give it that final bit of oomph. Together with the changing logo palettes and the rainbow gradient used in the text writer, the total number of colours on screen at any given time is somewhere between 60 and 80 unique values. Not bad considering it's just 5 bits deep. Only Amiga makes it possible!

This is what the background image would look like if the logo hadn't been displayed on its own screen and the gold logo palette was applied.

The animations

Just like with the text writer font, each frame of animation has been programmatically cut out of a larger image and stored in an Amos memory bank. They are displayed on screen using Amos' built-in sprite multiplexer and most of the main program code consists of checking the values of various timers and flags to decide what sprite to display where and which frame of animation it should contain.

Tweaking and testing

During development, it's important to test the code regularly. An executable file is produced using the Amos Professional Compiler. The executable is then transferred onto a floppy disk for testing on my Amiga 500, and onto a compact flash card for testing in an Amiga emulator on my Linux PC. In this process, new ideas emerge and old ones are scrapped or refined. The number of animated sprites grew drastically during the last week of development, for example.

Well, crap.

Crunching

Once I was satisfied with the intro, it had to be crunched to meet the compo size limit. A crunched file is basically the demoscene term for a self-extracting, executable archive. If my intro had been written in assembler, it probably wouldn't have needed much crunching at all, but Amos embeds its support library into the executable and the programmer can't exclude unused parts of it. In other words, the file size was drastically larger than the permitted 64 kilobytes. This crunching was the only thing I actually did completely on my Linux PC: the Amiga would've been far too slow.

On the Amiga scene, there are three commonly used crunchers that produce executable files. They're all asymmetrical, meaning the crunching of the file is much slower than the decrunching. There's Titanics Cruncher by Titanics, which is old and a bit buggy; Shrinkler by Blueberry, which is very good at compression but aimed at small intros (4 kilobytes or less) and thus rather slow at decompression; and Cranker by Bifat, which offers a good compromise between speed and size.

I first tried to crunch the intro using Cranker, but to my chagrin it ended up roughly 10 kilobytes too large. My only option seemed to be Shrinkler, which met the size limit but decompressed very slowly. To make the wait a little less dull for the user, I added a small text to be displayed during the decrunching. I opted for a slight rewrite of the famous Trainspotting monologue about choosing life:

Choose scene. Choose a platform. Choose coding, pixeling or composing. Choose a fucking big television, choose disk drives, hard drives, CD-ROMs and three button mice. Choose bad health, high cholesterol and bleary eyes.

Choose a cross compiler. Choose your elite boards. Choose leisure wear and matching mouse mats. Choose a mechanical keyboard on hire purchase in a range of fucking colours. Choose DYCP and wondering why the fuck you're awake on a Sunday midnight.

Choose sitting on that sofa, watching mind-blowing, spirit-lifting demos, stuffing junk food into your mouth. Choose gaining some skills at the end of it all, pouring your might into a majestic compo winner, listening to the roaring crowd as you finally hit the big leagues.

Choose your future. Choose scene.

Releasing

With all of this in place, it was now just a simple matter of putting the final executable onto a bootable floppy, creating an ADF image file of that and submitting it to the Revision compo system.

There it is, live in the compo!

Special sauce

The source code, then? It's a mess. I'm not just saying that to be humble, it's truly terrible. That's what you get for cowboy coding flags and conditions for sprite animations right up until the last minute. I can't be bothered to clean it up, but I have added a few comments to explain roughly what the heck is going on. If you know how to program, feel free to point and laugh. If you don't, please promise me you won't use this as a reference for learning. Click here at your own peril!

Final notes

As stated above, this is hardly a technical breakthrough. I'm not an assembler hacker with amazing skills for taming the custom chips and making them do seemingly impossible things. What I enjoy is the poking about with pixels, animations and colours and I got to do that in spades with Space Swap. I'm quite pleased with the end result and even more pleased with all the fun I had making it!