What is it?
remake demake of Unreal Tournament, developed by Megga. Unlike the original, UT2600 will be
released on only one platform: the Atari 2600, hence the name.
The Atari 2600 (also known as VCS prior to 1982) is a home video console that was released in 1977. You probably have seen one and if you haven't, it suffices to say that this machine is why video games are credited to be heavily blinking, epilepsy inducing beepfests. The limitations of its technical specifications are such that for the remake a whole dimension has been dropped in the games presentation (namely the third one).
So what minor annoyances can one expect when creating a soundtrack for such a system?
#1: Limited voices
The Atari 2600 can output sound through its Television Interface Adaptor (TIA)-chip. This TIA can output two channels of audio simultaneously.
We're talking one sound per channel. At most you can only play two note chords by using both channels to play a different note on each. By playing these two notes on both channels, you have now exceeded the amount of available sounds for the duration of those notes.
Now to be honest, this limitation isn't too bad and actually quite interesting in that it challenges your creativity. How can you give the illusion of drums with kick, hi-hat and snare while at the same time playing a bass line and a melody (Cue arpeggios everywhere) ?
Long story short: it is not possible to use notes that sound in tune to their real life counterparts. Due to the mere 5 bits available to define pitch, the resulting frequencies (in Hertz) are of insufficient resolution to be "correct" (and also differ in accuracy between PAL and NTSC systems). To make matters (even) worse, this means the pitches are also out of tune with each other!!
This limits the amount of scales you can use as well as the amount of notes available within a scale. The best compromise is to find a set of notes that work well enough in relation to one another to keep a sense of musicality going on.
You can view this impressive map to get an idea of the available notes and by how many cents they drift off from their supposed frequency.
#3: Memory space
The average Atari cartridge has 4K of ROM. That is a whopping 4096 bytes. By contrast, 1 second of CD quality stereo sound requires 88200 bytes!! Keep in mind that apart from the music, the actual game code also has to fit in that size. You'll actually end up using the term "squeezing" more often than "fitting" in this context.
It's not wholly bad, with a technique known as bank switching, up to 64K can be used in an Atari ROM, though it does complicate the programming of the software. For UT2600, seven additional banks are used, bringing a total of 32768 bytes at our disposal. Luxury!
The music for UT2600 is not a pre-fabricated recording (e.g. "sample"), but rather a series of instructions to be synthesized by the TIA at runtime. As such, the size for a typical track is much more forgiving, averaging between 413 to 956 bytes (yes, you keep track of individual digits!).
#4: Assembly code
Programming music from code isn't wholly bad either, but when you need to talk directly to the hardware instead of through the abstraction layer of a programming language, things get more interesting. But who needs interesting when you're trying to be creative and try out an idea within the already limiting constraints of the Atari 2600?
Instead of dealing with actual machine language, you can luckily program the 6502 microprocessor through assembly language. Also, a gentleman known as Paul Slocum has created a ready to use audio driver.
While Lady Luck seems to be on our side again, a typical musical composition ends up looking like the text in the following image:
Coming up with solutions
UT2600 is a labour of love and as is often the case with these projects, their development span usually lasts for a long period. With this comes the time to experiment.
After having had a lot of happy accidents using a text editor and listening to the results after assembling the code, the need for a more efficient workflow arose. The result is Slocum Tracker, a web based frontend that provides a graphical user interface to sketch out ideas, which can be exported for use with Paul Slocums driver, and in turn be built into a binary.
Slocum Tracker was split from the source code of Efflux which was under development at the same time allowing to create this "nice spin-off" quickly.