INSIDIOUS 6581 Part 4: What makes the SID sound like the SID is not the SID

Part 3, "When a filter doesn't behave" is available here.

Not Unique

Aside from the filter, the SID chip does not do anything particularly special. It didn't demonstrate any newly-invented synthesis, it didn't have better capabilities than other actual synthesizers of the time, but what it did do was produce reasonably complex sounds for a very low price.

If you just take a standard SID chip connected to a keyboard and play the oscillators like a usual synthesizer, it really doesn't sound like anything unique. Listen to the SID tune below that I started a while back. Until the drums come in, you really can't tell that it was produced using SID chips. I deliberately had to put in C64-type drums and fast arpeggios to give it that SID sound.

So what is it that makes "that SID sound"? Well I'll tell you...it's the television. Ok, there's more to it than that, but for the most part the nature of the television standards coupled with the detailed control allowed by direct programming of the CPU is responsible for the general sound that is associated with the SID chip.

I shall explain.

Pulse Width Madness

Firstly, I want to get PWM (pulse width modulation) out of the way. The PWM 'neeeeoooowwwww' sound is something that is particularly attributable to the SID for SID fans. Although it's available on most early synthesizers, it has never been widely used in the raw, brash way in which it is used on the SID. The reason it is so used in SID tunes is because of processing cost. If you only write SID music using the standard waveforms, the sound you get is very static and rudimentary, much like music on the earliest games or on almost every other computer sound chip. For example, take a listen to the music from the 1983 game Slalom, which uses only the raw sawtooth wave on every channel. It is tonally simplistic and a far cry from the music produced in later years after audio specialist musician/programmers came along and started to use PWM and other more advanced techniques.

PWM gives a tonally complex sound and, as mentioned before, is very cheap in terms of processor usage and audio channel usage. All other complex tonal features on the SID (such as ring mod or chorus) require the usage of 2 audio channels, but PWM can be implemented using just one and takes almost no processor time. It's the natural choice and so is found in most of the classic SID music.

So PWM is a reasonably big deal in contributing to the sound of the C64. Most tracks use it because it's cheap and dynamic, and although PWM is not unique and can be found on most synthesizers, its use in C64 music is rather in-your-face.

Graphics constrain sound

Now about that television thing...first it's necessary to know something about how graphics are processed, especially in the context of games.

I will go into the technical details about the hows and whys in another post, but fundamentally what you need to know is that a TV refreshes its screen at a regular interval and every time the refresh happens, the parameters for audio are updated.

This means that the audio can not be updated more frequently than 50 times per second (or 60 if using an American TV). Pitch can not be changed, waveforms can not be changed, the filter can not be changed. These things can only occur when the TV screen refreshes. For the more worldly among you, this is the reason that music plays faster on an American C64 than on a European one; American TVs update 60 times per second rather than 50, so the audio updates occur 20% more often. For the rest of this post I will refer to only 50Hz updates.

It should be noted that this is the case for every other gaming soundchip at the time when the TV was king. Atari, NES, Gameboy, Amiga they all work in the same way. Even the handhelds have a hardware design that is based on the idea of regular screen updates at the rate of a television.

The SID chip has got three channels; it can play three sounds simultaneously. It also has a limited number of waveforms. Once you've reached the limit of this configuration, what is there to do? Well let's say you wanted to play a three note chord. You can either use all three channels or you can use one channel and run through each note in the chord as fast as you can. "How fast would that be?", you ask. "Why, 50 times per second of course", I reply. The video to the right demonstrates the effect. The video regards the same effect in NES music, but begins with a C64 tune.

Faking it

How about if you want to make the sound of a snare drum? Fundamentally, a snare sound consists of the impact tone of the drumstick against the skin resonating inside the drum itself plus the noisy sounds of the snare wires rattling underneath the drum. This can be emulated using two channels, one for the impact tone and one for the noise of the snares.

In fact, this is exactly what Tim Follin did for the L.E.D. Storm music. Have a listen on the right.

The problem with using two channels is, obviously, that it uses two channels, and taking up 66% of your channels for a snare drum while still keeping a full sound requires skills of the likes of Tim Follin. The compromise is to squeeze both sounds into one channel instead. How about switching between the two sounds very quickly to make it sound like two channels? Well, that's perfectly reasonable and if you could do it fast enough, you'd be hard-pressed to hear the difference. Unfortunately, C64 games couldn't go that fast without wasting too much CPU, but they could do it 50 times per second. At this frequency, it's very noticeable and that's what gives C64 drums their trill-like sound.

Take a look at this lovingly-prepared image of the snare sound from the title music of the game Delta. You can see how the sound switches between triangle and noise waves every 50th of a second. Click on the image to see a bigger version. Click on the play button beneath to hear how it sounds.

It's important to note that this technique of switching between sounds so quickly is only possible because the processor has direct control over the SID chip and it can be programmed to switch so frequently. Standard synthesizers do not allow anything like it, mostly due to the fact that they need a user-friendly interface and in general the friendlier the interface, the less flexible something is.

Can you imagine Nick Rhodes from Duran Duran programming sounds in the 80s for his synthesizers in assembly language? What a thrilling band practice that would have made:

"Nick, can you make that sound a bit less harsh? It's drowning out the guitar."
"Yep, hold on, just let me connect the computer and set up the cross-assembler. It'll take me about half an hour. Talk amongst yourselves in the meantime."

That's why he used a Roland Jupiter-8 and not a Commodore 64.

Smashing sounds together

The technique of switching sounds at this speed happens across all sorts of instruments, not just snare drum elements and it gives a very characteristic sound. One very common technique is to play a short percussion sound at the beginning and then switch to another sound like a bass or lead. On the left you can see an image of the snare/bass sound from Chris Huelsbeck's R-Type music. Click on it to see it in a larger view or click on the player button beneath it to hear it. It has snare elements right at the beginning and then continues with a bass sound for the rest of the instrument. There is an equivalent instrument that contains a kick drum in place of the snare and also one for the same bass sound without the snare or kick part.

This sort of thing can be found all over SID music to make it sound like there are more than 3 channels being played at once. The minimum switching speed of 1/50th of a second gives it a sort of scratchy stuttering sound that massively contributes to what people think of as being sound of the SID.

For comparison of how different things could sound without the 50Hz Vertical Blank timing restriction, here is the snare sound from 'I swore a vow on my dying breath' by Sascha Zeidler (a.k.a. Linus). In this track from 2006, there is no Vertical Blank restriction. The audio updates are done with the CIA timer at 200 times per second. There is a massive difference in the sound compared to the Delta snare sound above. It doesn't really sound like a SID drum sound at all.

Not Just Noise

This contribution to defining the sound style of the SID does not just apply to percussion sounds. The marvellous Lightforce by Rob Hubbard is rammed full of these 50Hz sound switches.

To the right is the tune itself. To the left is the sound used in the main arpeggio. The defining bloopiness of the sound is due to the waveform change and pitch change that you can see clearly in the image of the waveform.

Listen to the rest of the music and see if you can spot other areas where the above techniques are applied. They're all in there at various points.

And hopefully, now that you know what to look out for, you'll be able to hear the same thing across the gamut of SID music. Happy listening. Comments section for questions.

Next: "Tables. How to emulate SID switching without making the users insane."

Old Audio Part 1: You People Don't Even Know You're Born

Chiptunes have quite a following these days. But why?

Is it really that great to have Gameboy music playing through massive speakers? A lot of people seem to think so, even though it's mostly just square/pulse waves. Yet, Roland would be laughed at if they released a synth that only had three square waves and a noise channel, so what's the big deal with it?

The square wave genre, including AY chips and the other doorbell sound chips, certainly has its charm. It sounds pretty unique compared to any other style of music and the limited capabilities definitely forge creativity (giving us some great melodies), but my word it can sound like an absolute travesty without a skilled person at the helm. A true assault of sonic knives stabbing at the ear drum, and make no mistake it was the same back in the day. There was an abundance of absolutely appalling music on every game platform.

But the good stuff can be very good indeed. Who doesn't love Chipzel? She's brilliant. And hilarious. It's understandable that people would want to emulate her and other's success, but there are so many people trying to make Gameboy music right now that it's borderline ridiculous. Chiptunes are 'in' right now and the barrier to entry is unbelievably low, almost as low as picking up a guitar and strumming E, A, and D. It's very easy now to download a Gameboy emulator, load LSDJ into it, and start making music thinking that you're just like game composers of yore.

But things were not so easy back then. Even after somehow getting hold of the dev kit, it could be a complete pain to do any audio on the machines of old and it was a constant battle against the restrictions of the hardware. It was not a particularly pleasant situation and all we ever wanted was for those restrictions to go away. I find it somewhat amusing that people now celebrate what was a mostly awful restricting environment, but the power of nostalgia (for things real or romanticised) can be very strong indeed.

In this series of articles I shall describe the sometimes crazy processes I've had to go through to create music/sound on various game platforms, beginning of course with the Gameboy.

If only now had been then

How can you hate MIDI, Mr. Clarke? You must be an idiot!

I don't hate MIDI for writing music in general, but when dealing with low-spec devices, MIDI is one of the worst possible formats. It's fine for trying to recreate a jazz band on a synthesizer, but appalling for fine control of a sound chip. The direct control over the sound that you get from a Tracker is a world apart from the fuzziness of MIDI.

MIDI has no concept of audio channels or polyphony. Either a player would have to restrict itself to one MIDI channel per sound channel or you'd have to be very careful when placing notes so that there are no notes overlapping. If there were, the second note could spill your lead sound into the next sound channel and cut out a bass note.

Instrument changes are incredibly laborious in MIDI. It takes ages to do clever effects like switching samples very quickly on each note. The nature of how MIDI is purely a song data format meant that designing instruments for your music was a completely separate process from writing the music. In a limited capability environment having immediate and direct control over the sounds while editing the music data is really important.

Doing pitch and volume effects in MIDI is really cumbersome. You have to set the pitch bend limits in the instrument and then insert hundreds of pitch bend values into the MIDI data. With a tracker you could just repeat a command at each note step and it would continually perform that command. You can do nice effects with this like repeating a pitch command with a high value while retriggering the sound at different notes, or repeating a decrease volume command while resetting the volume each step to get a staccato effect. Dynamic portamento was also very easy to do with this method and very controllable.

How about the bubbly-sounding fast arpeggiations that chip tunes are known for? Most trackers have this as an arpeggiation command where you specify the relative note numbers to cycle through, but with MIDI you'd have to enter each individual arpeggiation note by hand. Why do those arpeggiations sound so characteristically like old game music? Because the rate at which the notes changes is the refesh rate of the TV, i.e. 50 or 60 times per second. If you go faster or slower than that, it starts to sound different.

Basically, if you want your music to sound good on a weak chip, you have to do clever stuff that is really awkward to do in MIDI. Step-based players like trackers or custom playroutines were always designed to take advantage of the nature of the chip itself and made it much easier to implement that effects that could make it all sound good.

I will touch more on MIDI when I get to PCs and mobile phone audio in a later article.

Most of my music was on the Amiga using Protracker, which is really the basis for all of these modern chiptune trackers (although it could be argued that Protracker and its originator The Ultimate Soundtracker were based on earlier programs like Soundmonitor on the C64, which itself was based on earlier hand-coded music players and works in a very similar way to the Real-Time Composer interface of the Fairlight CMI sampling workstation). In a way, I had it easy because I could use a tracker while others before me had no choice but to use self-written code. On other platforms, I was not so lucky.

There were few public tools available for computers and none at all for consoles (as you needed to get a licence and a devkit from the hardware manufacturer). Most tools and players were written in-house at whichever game company was writing whichever game. These tools would never see the light of day outside that company. To even get tools in the first place could be problematic. They would obviously have to be written by a programmer who hopefully understood something about audio, and that would take time and money. It was a big investment for a company and programmers interested in audio were very hard to come by, so it would be pretty common that a programmer would shovel together the bare minimum and leave the musician to just get on with it. This could be anything from just a music player with the music data having to be written directly in hexadecimal in a text editor to more user-friendly toolsets with instrument editors and so on.

Never again, please

I only ever worked on one Gameboy game. It was called Force 21 and was originally a PC realtime strategy game from Red Storm Entertainment. The port was by The Code Monkeys and they had their own Gameboy audio player that they had used on previous games. Worst case scenario, I thought, was a bunch of assembler code into which I would write music data, which is how I mostly worked on the SNES and my own players. But no. It was worse than that. It was a MIDI player. I always hated MIDI.

It got worse.

To get the music into the correct format, I had to use their MIDI converter, which was written for the Atari ST.

It got even worse.

Their MIDI converter wouldn't convert the MIDI files that I output from Bars & Pipes on the Amiga. As it turned out, it would only convert MIDI files that were exported from a specific version of Cubase.

And yes, it was even worse than that.

After getting the music into the correct format, I then had to email the data file to the programmers who would package it up in their music player and send me back a Gameboy ROM file of the player with the music embedded to check if it worked okay.

The original music that I had to convert was a set of really nicely done orchestral music by David Frederick. I had to convert that into 1 square wave, 2 pulse waves and white noise. Not easy to do without it sounding like crap, but I usually enjoyed trying to get the most out of limited capabilities. It was a pain though, converting orchestral stuff was definitely the hardest thing to have to do.

To do it, I made a Gameboy emulation with my K2000 (possibly the finest synthesizer ever made). It was just a simple setup that matched the setup of the instruments on the Gameboy, with one sound on each MIDI channel. Then I wrote the music in Bars & Pipes on the Amiga that was connected up to the K2000 (as was my other gear), like with all of my music. Once that was done, it went through an utterly ludicrous process to be ready for the game...

Here's the complete sequence of events:

1. Convert the music from the MP3s of the original orchestral score to fit the limitations of the 4 channel Gameboy.
2. Export a MIDI file from Bars & Pipes.
3. Copy that MIDI file from my Amiga to the PC via a floppy disk.
4. Load the MIDI file into Cubase.
5. Export a MIDI file from Cubase, having performed no operations on the original.
6. Put the MIDI file into a specific folder.
7. Load the Atari ST emulator and run the conversion program inside it.
8. Load the MIDI file into the conversion program.
9. Save out the data file.
10. Email the data file to the programmers.
11. Wait.
12. Receive the ROM file from the programmers.  One time, it was 3 days until I got the ROM file back.
13. Load it into the No$GB emulator.
14. Listen to the new track and make sure everything sounded as expected.

The experience was so insane that after I'd finished, I spent the next three weeks writing my own Gameboy music driver in z80 assembler. It had plugin synthesis modules and sample playback, but it never got used for anything. I stopped being freelance and moved to London to do full-time audio programming. I enjoyed creating it though. There's something cathartic about going through an opcode list and realising that you can save two clock cycles if you replace that clear command with a multiply by zero instead. If I can ever find it, I'll post the source code here.

Force 21 PC music
Force 21 Gameboy music 

Next: Part2: Some Lesser Home Computers