The Lost Sound Code of Sinistar

Sinistar was a game that had quite an impressive sound design. It borrowed a bunch of its sound effects from earlier Williams games, with which it shared common hardware that was originally design for pinball machines. A cockpit version of Sinistar, of which only around 200 units were made, was the first arcade game to have stereo sound. And of course all versions of the game have the Sinistar’s famous digitized threats and taunts.

While Sinistar’s main program source code was found and made available on Github, the source of the code that drove its sound hardware has long been lost. Youtube user SynaMax has done the best he could at recreating that code, and has made a video talking about the process, the sound design of Sinistar and other early Williams games, and even found unused sounds in the code.

Contained within the code is the revelation that the sound chip that drove the rear speakers in the cockpit version ran slightly different code than contained within the main sound ROM. The data from that version of the game was only dumped this year, meaning that the game running in MAME was somewhat incorrect.

Now that the right version of the chip has been dumped, the cockpit version of Sinistar now sounds properly in MAME. Although this does mean that users running up-to-date MAME have to refresh their romset for this version of the game. Such are the tradeoffs of MAME emulation.

Another revelation of the video was that the parametric sound generators used by Williams arcade games from that time often produced interesting noises if it was fed with random data. Sound programmers sought out different sets of numbers to give them, including by asking passers-by for numbers off the top of their heads and garbage values found in RAM when dev systems were powered up, in order to produce strange sound effects.

Devs using more recent parametric generators like bfxr, LabChrip, ChipTone, sfxia, rFXGen, wafxr and jfxr can produce noises by similar means using those programs’ Mutate or Randomize buttons!

I feel like I should warn however, near the end of the video is mention of a bit of drama concerning the MAME developers, in getting code supporting the change integrated into the software. I’m not weighing in on this, not the least reason being I don’t know enough about it. But I feel like you should know it’s coming, ahead of time, before embarking on the 51-minute journey.

Rescuing the Lost Code and Stereo Sound to Sinistar (Youtube, 51 minutes)

How David Crane Got Good Music Out Of The Atari VCS For Pitfall II

Back in 2013, David Crane chimed in on a thread about Pitfall II. The Atari VCS (a.k.a. 2600) was not known for the quality of its music. For sound effects, especially noise effects like blasts and booms, it was fine, but its TIA chip didn’t have the frequency resolution to produce every musical note precisely, meaning some of it notes would sound a bit off.

Pitfall II’s music, some of the best on the system in the classic era

There was technically a way to produce almost arbitrary waveforms, though like many techniques on the system it was processor-intensive. It involved changing the volume on one of its sound channels in real time to simulate the waveform of the sound you wanted to make. That was fine so long as you didn’t need the processor to do anything else, and sadly, on the VCS, just displaying graphics relied heavily on the processor.

Pitfall II, VCS/2600 version. Image from Mobygames.

David Crane managed to get decent polyphonic music out of the VCS by using Pitfall II’s DPC chip, which Crane created himself, as a co-processor that figured out the right values to set the volume to produce the mixed waveform for the music at a specific time, which the machine’s overworked 6507 CPU could then read and send to the right volume register in the TIA every scanline. The process is explained (to the understanding of a sufficiently technical frame of mind) here. I think I understand it myself!

The fact that David Crane is still around, and so willing to discuss the many tricks he came up with to make his games, is a great blessing, as is the existence of the AtariAge forums themselves, which are a trove of classic gaming information.

Nowadays this technique has been refined and utilized in homebrew cartridge productions. A particular standout is the music from Champ Games’ version of Mappy, which is frankly amazing. Check it out:

The NES Sample Encoding Error

There was an error in the data prep in many NES games that caused them to reverse the bit order of samples. Or more accurately, the games encoded the samples correctly, but the flaw is in the NES sound hardware.

The result is, many games with samples sound notably worse than they should. The most infamous example of this is the sound in Double Dribble, which sounds particularly bad on its title screen. The difference can be heard on the game’s page on The Cutting Room Floor. There’s a hack for Double Dribble on romhacking.net that corrects the samples in-game.

Another game this affects is the unlicensed Tengen NES game KLAX. In the arcade KLAX had very little music, but the NES version has excellent music that relies heavily on sampled instruments. There’s a fixed patch for that game on romhacking.net, too!

ABAgames’ “Good Old Game Sound Generator”

Kenta Cho is a brilliant game maker, and he’s come up with a couple of generators that can generatively make short stretches of music, suitable for classic-inspired arcade games.

Short VGM Generator is on itch.io, and works by taking a pre-existing piece of music and attempting to make another piece of a similar style.

The Good Old Game Sound Generator is on GitHub, but for playing around you might be more interested in its Demo page. It takes a bit more effort to make something with it, but it’s a much more flexible tool. I must leave you to your own devices to make something of value, or at least of interest, using it.

The process that let him to create these tools is up on a page he made on dev.to. If you’re interested in generative music you should take a look!