Sound Drivers | Code Like It's 198x

A sound chip does not play music. It holds a few numbers, a pitch, a volume, a waveform, and keeps making the same noise until something changes them. The something is the sound driver, a routine inside the game that reads the composer’s music data and rewrites the chip’s registers, over and over, at a steady rate. Amstrad Action explained it to would-be game writers in 1990: “A sound driver is a program that plays and updates sounds through the chip. It needs to be ‘called’ extremely frequently to work properly, a rate of around fifty times a second being the norm.”

Two composers with the same chip could sound nothing alike, because the driver decided what the chip was asked to do. On the Commodore 64 the composer usually wrote the driver as well, and it had to be small. Edge, looking back in 1994, said that writing the melody “wasn’t enough; you also had to write a sound driver routine to control the SID that would fit into the memory available — normally 3-5K”. The Games Machine gave a similar figure in 1987, “about 4K of memory for sound”, and put part of Rob Hubbard’s success down to “the library of self-written routines that he has built up”.

Fast facts

Job: read music data and write the sound chip’s registers, usually once a video frame, from an interrupt (see Interrupt-Driven Music).
Size on 8-bit machines: a few kilobytes for driver and tunes together; Hubbard’s C64 routine was about 900 to 1,000 bytes of code.
Who wrote them: often the composer (Hubbard, Martin Galway, David Whittaker, Chris Hülsbeck, Tim Follin); sometimes a programmer colleague or a studio’s house driver.
Console era: drivers supplied to developers, such as Sega of America’s GEMS for the Mega Drive and the standard driver in Nintendo’s SNES development kit.
Afterlife: SID and NSF files keep a game’s own driver code so that its music can be played outside the game.

A sequencer in machine code

A driver keeps the music as data, not as code, and the data is built for size. Anthony McSweeney, who published a commented disassembly of Hubbard’s routine in C= Hacking in 1993, set out the layers. A music “module” holds one or more songs, so a game’s title tune, in-game tune and game-over tune could share one routine and even the same instruments. Each song is three tracks, one for each voice of the SID. A track is a list of pattern numbers, so a repeated section is stored once and called again. A pattern is a string of notes, each with its length and pitch and, where it changes, a new instrument. An instrument is eight bytes that set its pulse width, waveform, envelope, vibrato depth and effects.

David Whittaker described his own driver to Sinclair User in 1987 in the same terms. It let him “write in a stream of bytes which represent either musical notes or effects and arrange those phrases into different patterns – it’s like a machine code sequencer”. The effects were where a driver earned its keep, because the chips had no chords and no vibrato of their own. Whittaker explained the chord: play C, E and G “in succession very quickly – an arpeggio really” (see Arpeggio). For an echo he took the current note and, every so often, played it an octave higher for a fiftieth of a second. McSweeney found drums, vibrato, pulse-width modulation, a one-octave arpeggio and pitch slides in Hubbard’s routine, all worked out afresh on every call.

The same frame-by-frame loop carried the sound effects. A game had to decide which voice an explosion could take. A programming series in Commodore Computing International in 1987 left voice one free “to produce any noises that might be required by the game itself” and played the soundtrack on the other two, and the Monty on the Run routine that McSweeney disassembled had sound-effects code of its own, which he removed for clarity. Chris Hülsbeck’s later Amiga and SNES music kept “a couple of channels reserved for sound effects”.

Who wrote the driver

Hubbard wrote his once and kept it. McSweeney found that he “used this routine to make music for a very long time, only changing it slightly over time”, in Confuzion, Thing on a Spring, Monty on the Run, Commando, Thrust, International Karate and many more; to play a different tune “all you would need to do … is to change the music data at the bottom, and a few lines of the code”. Galway went the other way. “I had an all assembly language, no fancy editors, hard-work approach to putting in tune data,” he told Retro Gamer, which let him “custom-modify program code for each tune”, at the cost of complex tunes taking a month.

Other C64 composers told Retro Gamer how their drivers grew. Fred Gray said his first driver “didn’t fully exploit the SID’s capabilities”, so he wrote a more complete one, and when he rewrote it again he used the SID’s ring modulation for Mutants. Ben Daglish started with a driver Tony Crowther wrote for him, into which he typed notes such as “C2, 10, D2, 13”, used others at Gremlin, and later wrote his own, “which then made it easier to port code to different platforms”. Whittaker said he “did share and swap players with Rob Hubbard for a couple of different formats”. The composers who could not program waited for someone else: Reyn Ouwehand called himself “a bad programmer, so I had to wait for others to create players and routines for me”. In the Netherlands the work was split inside one team. Charles Deenen of Maniacs of Noise recalled starting out as “a programmer doing drivers and sound effects”, with Jeroen Tel writing the music.

As studios grew they kept house drivers. Stephen Ruddy, who converted Bubble Bobble to the C64 for Software Creations, remembered that after it he “was working on the Software Creations music driver”. In 1989 Tiertex’s musician Mark Tait composed on a sampler and an Atari ST sequencer, then ran a program to convert the MIDI data “into the format required for Tiertex’s music driver on the Spectrum”. Dave Rogers typed his notes into an editor he had written in Amstrad BASIC; a compiler packed them into a data block, and the driver was “the only part that I wrote in machine code, because obviously it had to be very fast”.

Machine by machine

Commodore 64 (SID)

The SID has three voices, each with its own envelope, so a C64 driver spends much of its time starting and stopping notes cleanly. The chip’s envelope generator has a fault: change an attack, decay or release value at the wrong moment and the envelope can stall for a full cycle of its counter, “32768 cycles. That is 1.7 frames in terms of 1/50 fps frames”, according to the Codebase64 wiki. Many drivers therefore release and reset a voice about two frames before its next note, provoking the stall early where it cannot be heard. This is the hard restart, and the values a driver chooses for it shape how each note begins.

Drivers also reached past the SID’s three voices. Galway worked out sample playback by studying the drum program Digidrums, and Hülsbeck, at Rainbow Arts, built his own sampled drums into his player; both are covered in their entries. Hülsbeck also said that when he heard Galway’s fast arpeggio chords in the Ocean loading music, he “coded that stuff in” to his own player.

AY-3-8910 family (Spectrum 128, Amstrad CPC, MSX, Atari ST)

The AY-3-8912 in the Spectrum 128 and its relatives hold three square-wave tones and a noise source, and keep playing without the processor’s help, so a driver only has to update them once a frame. The same notes and effects could be moved between machines, since, as the AY-3-8910 entry explains, a driver for another machine needs new port routines and a new table of periods, not new logic. Rogers’ drivers played the same Amstrad-made data on the 48K and 128K Spectrum and the Atari ST, Retro Gamer reported. On MSX machines BASIC offered its own simple driver: the PLAY statement took music written as a text string in a “music macro language”, in the manner of the graphics statement DRAW.

Atari 8-bit (POKEY)

Atari’s POKEY chip has four sound channels but, like the others, needs constant attention to play a tune. In December 1982 the magazine SoftSide published Craig Chamberlain’s Pokey Player, a music editor and player for the Atari 400 and 800. It moved the note processing into the vertical blank interrupt, which “happens every sixtieth of a second”, so that the music could run “simultaneously with another program”, and the player could be merged with the reader’s own Atari BASIC games.

NES (APU)

The NES’s APU offers two pulse channels, a triangle, noise and a sample channel, and most games run their driver once a frame from the vertical blank NMI; Metroid keeps its music running even when the game itself slows down. British teams wrote their own. Tim Follin’s own discography in Super Play lists his music drivers, as well as his scores, for Solstice, Target Renegade and Silver Surfer on the NES.

Amiga and Atari ST (Paula and after)

Paula plays sampled sound from memory by itself, so an Amiga driver chooses samples, pitches and volumes for four channels and changes them as the song goes. The best-known Amiga drivers are the replay routines of SoundTracker and ProTracker, which play the self-contained MOD files those programs write.

Composers also wrote their own. Hülsbeck’s TFMX, The Games Machine reported in February 1990, had been “developed over years” to produce the best sound “using as little memory and using up as little processing time as possible”, and gave X-Out its music. The German publisher Demonware sold it to other programmers that year. Amiga Computing noted that unlike SoundTracker it came with no source code for its player: “all you’ve got to do is disassemble the player program!” Hülsbeck later told Retro Gamer how drivers crossed machines. A colleague fitted an Atari ST sound chip to a board for the Amiga, so he “could program the sound driver on the Amiga and port it easily back to the Atari ST”. The traffic ran both ways. The ST composer Jochen Hippel had written “his own Atari ST sound system” that emulated the Amiga’s sound chip; for Turrican II, with Hippel’s help, Hülsbeck ported that code back to the Amiga to mix four simulated voices into one channel, giving his “seven-voice system”. Whittaker also wrote his own Amiga driver, which played synthesised sounds alongside samples.

Consoles of the 1990s

By the time of the 16-bit consoles, console makers supplied drivers. Nintendo Power explained in January 1994 that every Super NES game “is equipped with a Sound Driver, which is a program that converts music instructions and data in the game’s ROM into Super NES data”. Nintendo’s development system came with a standard driver, and some companies wrote their own. The magazine picked out two. Software Creations’ driver, written by its technical director Michael Webb, could compile music and send it to the console “almost instantly”, in the words of managing director Richard Kay. Interplay’s A.R.D.I. system read the score straight from the cartridge, not from the sound system’s limited RAM. Edge gave the reason: the SNES had only 64K of sound memory, and Interplay’s Charles Deenen put “the note data and drivers in the normal 512K” and kept the 64K for samples.

On the Mega Drive, Sega’s technical overview gave the Z80 processor the job of running the sound chips, and the YM2612 entry explains the driver’s work there. The Sega Retro wiki records that Sega of America commissioned the San Francisco developer Recreational Brainware in 1990 to write GEMS (Genesis Editor for Music and Sound effects), because Western developers were struggling with the unfamiliar hardware, and that it was used in about 200 games. Sega’s Japanese teams used a family of drivers that fans now call SMPS, a name the same wiki describes as colloquial, found in Sonic the Hedgehog and Streets of Rage among many others.

British studios built their own as well. At Krisalis in Rotherham, the technical director Shaun Hollingworth made an audio development system for the Sega consoles “custom made to my requirements”, as its user, the composer Matt Furniss, put it. Furniss wrote the music in a tracker-style program on an Atari Mega ST, which was linked to a SNASM Mega Drive development kit; the music data went “in real-time to the Sega console, similar to a MIDI sequencer and synthesizer”, so he could “hear exactly how it would sound in the game”. Hollingworth, Furniss said, “wrote most of the sound engines I used in the early years”; his entry lists the Mega Drive, Master System and Game Gear games, many of them for other developers, that Furniss scored with them.

Taken apart and kept

Because a driver was a program, it could be copied, studied and reused. McSweeney wrote in 1993 that Hubbard’s routine “has been ripped off by many famous groups and people over the years”, naming The Judges and Red Software’s Red-Hubbard demo, and the Atari ST demo in which Jochen Hippel, as “Mad Max”, converted about a hundred Hubbard tunes to the ST. He published his commented source partly because Lars Hamre had shared the ProTracker source. The same issue promised that the next would carry “The Second Rob Hubbard Music Routine”, with Galway, Daglish, Tel and Maniacs of Noise routines to follow, but no later issue of C= Hacking carried them.

Today’s music archives depend on the drivers. A .sid file in the High Voltage SID Collection holds the game’s own player code and data, with a header naming the routines that start and play the tune. The NES Sound Format works the same way: an NSF player calls the tune’s own INIT routine once and its PLAY routine at about 60 or 50 Hz. The VGM format, started on the S8-dev forum in 2001, takes the other approach: it “logs the data written to the sound chips by games”, so a player needs only the chip, not the driver. Modern trackers for the old machines, such as SID-Wizard and FamiTracker, carry on the old arrangement and export a player routine with the music for a game to call.

Sources

Amstrad Action issue 58, July 1990, p. 39: games-writing feature, “Sound as a Pound” (“A sound driver is a program that plays and updates sounds through the chip … around fifty times a second”).
Edge issue 15, December 1994, pp. 56–59: feature on game music (the SID driver in “normally 3-5K”; Charles Deenen as “a programmer doing drivers and sound effects”; the SNES’s 64K and Deenen’s drivers in the main 512K).
The Games Machine issue 1, October 1987, p. 111: programming music for games, “about 4K of memory for sound”, Rob Hubbard’s “library of self-written routines”.
Anthony McSweeney, “Rob Hubbard’s Music: Disassembled, Commented and Explained”, C= Hacking issue 5, March 1993 (web, secondary): the data layers, the eight-byte instruments, the effects, the games that used the routine, its size, the sound-effects code, the “ripped” copies and the Hippel demo; the issue’s “In the Next Issue” notice. Issues 6 to 21 contain no further Hubbard article. http://www.ffd2.com/fridge/chacking/
Sinclair User issue 65, August 1987, pp. 32–33: David Whittaker feature (his driver as “a machine code sequencer”, arpeggio chords, the octave echo).
Commodore Computing International vol. 6 no. 1, August 1987, p. 118: games-programming series, interrupt-driven music on two voices with voice one kept for effects.
Retro Gamer: The Commodore 64 Book (2012), “The SID Crowd”, pp. 24–29: Galway’s assembly-language method; Fred Gray’s drivers; Ben Daglish and Tony Crowther’s driver; Whittaker swapping players with Hubbard; Reyn Ouwehand; Hülsbeck on arpeggios after Galway’s Ocean loader.
Retro Gamer issue 37, 2007, pp. 84–88, Paul Drury, “Ste Ruddy”: the Software Creations music driver.
Sinclair User issue 90, September 1989, p. 59: how Tiertex’s Spectrum Strider was made (Mark Tait and “Tiertex’s music driver”).
David Crookes, “The Making of Cybernoid”, Retro Gamer issue 102, May 2012: Dave Rogers’s BASIC editor, compiler and machine-code driver, and his drivers for the Spectrum 48 and 128 and the Atari ST.
Retro Gamer issue 115, June 2013, pp. 90–94, “In the Chair: Chris Huelsbeck”: porting his driver between the Amiga and the ST, Jochen Hippel’s ST sound system, the seven-voice system and channels kept for effects.
mixer and others, “Classic hard-restart and about ADSR in generally”, Codebase64 wiki (web, secondary): the 32,768-cycle stall and the restart two frames before the note. https://codebase.c64.org/doku.php?id=base:classic_hard-restart_and_about_adsr_in_generally
MSX Technical Data Book (ASCII/Microsoft), p. 96: the PLAY statement’s music macro language.
Craig Chamberlain, “Pokey Player II”, SoftSide vol. 6 no. 3, December 1982, p. 49: playing music in the vertical blank interrupt on the Atari 400 and 800.
Super Play issue 43, May 1996: Tim Follin interview and discography, as cited in the Tim Follin entry.
The Games Machine issue 27, February 1990, p. 51: X-Out review, TFMX “developed over years” by Chris Hülsbeck.
Amiga Computing vol. 3 no. 6, November 1990, pp. 120–121: TFMX from Demonware, no player source (“disassemble the player program!”).
Chris Wilkins and Roger M. Kean, The Story of the Amiga in Pixels (Fusion Retro Books, 2017), pp. 208–210: David Whittaker’s Amiga driver.
Nintendo Power issue 56, January 1994, Super Power Club supplement, pp. 6–7: the Super NES sound driver, Nintendo’s standard driver, the Software Creations driver (Michael Webb, Richard Kay) and Interplay’s A.R.D.I. system.
Sega Retro wiki, “GEMS”, “Recreational Brainware” and “SMPS” (web, secondary): GEMS commissioned by Sega of America in 1990; its use in about 200 games; SMPS as a colloquial name and the games that use it. https://segaretro.org/GEMS https://segaretro.org/SMPS
Chris Wilkins and Roger M. Kean, The Story of US Gold (Fusion Retro Books, 2015), pp. 196–197: Matt Furniss’s own account of Shaun Hollingworth’s Sega audio development system (the Atari Mega ST, music sent to the console in real time).
Zebbe, “Interview: Matt Furniss (Composer)”, Sega-16, 20 April 2010 (web, secondary; his own words): the Mega ST and SNASM development kit, the tracker-type program on the ST, Hollingworth writing “most of the sound engines”. https://www.sega-16.com/2010/04/interview-matt-furniss/
High Voltage SID Collection, “SID file format description” (web, secondary): the init and play addresses in a .sid file. https://www.hvsc.c64.org/download/C64Music/DOCUMENTS/SID_file_format.txt
NESdev Wiki, “NSF” (web, secondary): the INIT and PLAY routines and play rates. https://www.nesdev.org/wiki/NSF
SMS Power!, “VGM File Format” (web, secondary): its origin on the S8-dev forum in August 2001 and what it logs. https://www.smspower.org/Music/VGMFileFormat