Have you ever wondered why some SNES music sounds so…
Yknow…
Samey?
The SNES used a sampler to generate sound, so the possibility for each sound is limited
only by your imagination, yet so many games appeared to share the same samples.
Why is that?
And…
This is the point where this video diverges from the Sega Genesis version.
Sega of America created a software-hardware combo that saw consistent use across the entire
continent, but the SNES never saw an equivalent.
In fact, information about how SNES music was made is surprisingly hard to come by.
This video is going to dive into a sort of overview, starting with…
Intelligent Systems is the second-party developer that you may remember from hit games such as
the original Paper Mario, or Mario Kart: Super Circuit.
Besides software development, they seem to be the go-to when Nintendo needs development
kits for their consoles.
For the SNES, they built several boxes with dedicated functions.
If you’re working with audio, you get the IS-Sound.
If you’re working with code, you get the IS-Debugger.
IS-Character is your graphic editor,
since this is still the era where graphics are divided into tiles.
These appear to be the oldest devkits, judging from their bulk and unoptimized workflow.
If you look closely at this 1994 pic from the development of Super Metroid,
it looks like they’re using the IS-Debugger, or at least a machine built off of the design.
...Which brings us to our next point:
These bulky machines were generalized into a more modular approach
by the time Americans got their hands on them.
The name of this new kit was changed to The Super NES Emulator SE,
which you can find a few mentions of in old magazines.
Do note that “SNES Emulator” means something different now than it did in the year 1991.
In this case, it means “in-circuit emulator”.
Since this console hardware was top of the line, you needed special equipment if you
wanted quality-of-life features like the ability to pause a program and step through your code
one line at a time.
This system was modular in a literal sense: each function had a physical board
that you could insert or remove as needed.
The audio board matches what you’d find inside the IS-Sound.
Whether that means the Emulator SE is just every board combined into one,
or that the Emulator SE was just as specialized, I have no way of knowing.
Oh, but check this out: in both kits, the board has a MIDI input!
Remember this for later.
Besides Intelligent Systems, Ricoh had also stepped
up to provide an alternative devkit.
You may remember Ricoh for their involvement in creating the literal CPU for the SNES,
and its predecessor.
Their first kit, the SF-Box, is extremely rare.
The only photos that exist of it are tiny thumbnails from an ancient ebay auction.
I’m not sure how it works.
It shows a modularity similar to the Super NES Emulator, though these might just be the
usual ISA-slots you’d find in an IBM compatible.
One of these is wired to what appears to be a modified Super Famicom,
allowing you to plug in an existing cartridge.
The front of the box has an extremely convenient socket for EPROMs.
For reference, it was common practice to burn the latest build of your game onto an EPROM,
attach it to a special cartridge, and then plug THAT into your system.
This eliminated the middle step.
Ricoh followed this up with a much more compact SF-Box 2.
This version looks a bit more familiar:
vaguely console shaped, with a cartridge port on the top
and 2 controller ports in the front.
The “break” button is used to pause the game and step through your code.
Not all of these had a socket for EPROMs.
This machine is much more common, with plenty of pictures available.
You can even see it in some development pictures from Dragon Quest 6!
Of course, some companies decided to save
money by just buying a regular SNES and tearing it open, reverse engineering everything until
they have their own devkit.
Pictured here is what Factor 5 came up with,
which was likely the kit used to code Super Turrican.
But let’s shift our focus back to Nintendo’s recommended kits.
Along with the hardware, Nintendo provided some instructions and examples on how to actually
use their kits.
This is important, because it brings us to our first sound driver.
The patient zero of SNES music.
Nintendo created several tools to work with audio.
First was “Tako Sample”, to get the audio from your microphone into the SNES.
“Tako” in Japanese means “octopus”.
This is probably a reference to the 8 channels of sound that the SNES has available.
Next up is “Ika listen”, which is used to preview the samples
(and maybe compositions) on your hardware.
This translates to “squid-listen”.
I don’t know how squid is relevant.
Most importantly was "Kankichi-kun".
This is the sequencer.
No pun in the name, as far as anyone can discern, anyway.
This is where your early 90s Japanese SNES game soundtracks came from.
This is the original name of what the SNES hacking community calls “N-SPC”.
And it’s lost to time, as far as I’m aware.
So how is this “patient zero”?
When companies outside of Japan received devkits,
they also received Kankichi-kun as an example sound driver to study.
It was extremely common to, from there, say,
“This is my driver now.”
Let’s look at an example.
Barry Leitch was unfortunate.
He was working at Imagitec when they took on a SNES project in 1991.
This was extremely early into the SNES’s lifespan.
Imagitec couldn’t afford to give Barry a devkit,
so they sent him off to Gremlin Graphics since that studio had a spare.
Unfortunately, the manual for all of the sound editing tools was only available in Japanese.
And from the interviews Barry has given, it doesn’t seem like he even had all of the tools he needed.
So he found himself tasked with writing SNES music,
but with no way to get his samples onto the SNES.
He ended up contacting Kemco, and their resident musician Hiroyuki Masuno sent back a floppy
filled with usable samples.
Remember that harmonic-filled shortlooped bass sample from the beginning of this video?
It appeared on this floppy.
Twice.
Barry didn’t actually use this, but Hiroyuki did.
I don’t know if this originated from Hiroyuki or Nintendo, but the sample got around,
along with the slap bass from the intro of this video, among others.
Anyway, even though Barry had samples now, his troubles weren’t over yet:
he didn’t have access to the official sequence editor.
What he did have, however, was example code from the Kankichi driver.
He ended up editing the code Manually, then compiling it to hear the results.
This means his driver is technically the “N-SPC”,
but he never saw the user interface that Nintendo intended.
Alberto, pictured here surrounded by development kits,
received all of the tools from Nintendo, including the Sequence Editor that Barry never
got a chance to work with.
This allowed him to work with one of the best features that the Super NES Emulator offered
to musicians: MIDI input.
(Remember that from earlier?)
Kankichi offered the ability to record MIDI data, and then edit and optimize it for size.
For example, it could loop the drum pattern of a song so that only 1 bar of data needs
to be stored, instead of 3 minutes of the same repeating notes.
While this meant it was possible to plug your DX7 into your devkit and just bang out a keyboard solo,
Alberto had a better idea: Octamed.
This tracker supported MIDI, which allowed Alberto to compose entire songs start-to-finish
in tracker format, and hear the result played back live from the official hardware.
Octamed was technically separate from any of the SNES software, though.
In fact, it wasn’t even the only MIDI sequencer that Alberto used.
Besides a Windows-based MIDI sequencer that he can’t recall the name of,
he even started work on a completely custom tracker-based sequencer.
Sadly, this never got used, as Asterix & Obelix
ended up being the only SNES game he scored.
Regardless, Alberto lands in the category of people that used Kankichi.
He did modify the driver, expanding its capabilities and changing some playback features, but it
was still recognizable as Kankichi.
Remember, this was the example driver that
basically every developer received.
As such, there is a painfully wide spectrum of variations of it, ranging from “two opcodes
changed” to “almost entirely incompatible but the pitch bend algorithm is the same”.
Covering the minutiae would be both lengthy and tedious, so we’re skimming over it.
In short, it’s a lot of this.
What you’d expect to see, though, is developers writing custom drivers.
This happened! And there were two flavors of this: Drivers that were linked to musicians,
and drivers that were linked to companies.
So, first we have
David Whittaker. He got his start in the home computer scene of 80s Britain.
He wrote his own sound driver for every computer at the time: C64, Atari ST, Amiga.
In 1992, he was asked to port Mark Miller’s music for Krusty's Super Fun House to every
game console at the time.
This included the SNES, so he got busy writing some code.
This led to version 1 of his custom driver.
He spent a few years improving this, scoring any game that he was asked to, and licensing
out his driver occasionally.
This is pretty apparent, as every other game that uses this driver is from a different publisher.
He did eventually move to an in-house position at EA, but by that point, was focusing less
on composition.
Sadly, we only know all of this through driver analysis.
None of the source code remains.
Next was the second flavor of drivers:
The ones linked to companies.
MEdit was the solution to a problem that Imagitec faced:
The same composer would often be tasked with writing a soundtrack for several versions of the same game.
The process of converting from one tool to another is essentially just wasted time.
The goal for MEdit: have a single editor for multiple systems.
Initially this just meant SC-55, MT-32, and Adlib for PC games,
but its functionality was expanded over time.
This tool was primarily built by Barry Leitch and Leslie Long at Imagitec, but Barry brought
it over to Ocean in 1993.
Also at this time: Leslie reverse engineered the SPC-700 and connected it to MEdit.
Since MEdit was based on OctaMED, a popular tracker from the time,
it was incredibly easy to pick up compared to Nintendo’s tools.
As a bonus, it gave easy access to undocumented features, such as frequency modulation.
While the tool can still be run today, the SNES functionality has sadly been lost to time.
There’s a sort of third flavor of custom sound drivers though:
Drivers that are linked to a company founded specifically for sound driver work.
Slick/Audio is the shining example here.
It has some familiar features to anyone that’s familiar with GEMS:
You connect a cable to a special cartridge and play back audio straight from the hardware.
This specialized cartridge was developed and distributed by Chip Level Designs,
and was coupled with a user interface and sound driver
by Dave O’Riva of Bitmasters.
Because Chip Level Designs licensed out this combined kit to anyone who was interested,
the sound driver wasn’t linked to any particular game developer.
You could argue that it was linked to some composers, though.
For example, Tommy Tallarico started his own studio around this time and used Slick to
compose all of his SNES music.
He was just one of many users, though.
The hardware portion of this kit is a rarity these days,
though you occasionally find pics from collectors.
The software portion, luckily, is easier to find.
It doesn’t work very well without the hardware, but you CAN look at it.
Luckily, the manual was also included,
so we can walk through that and pretend that this still works.
The program is sorted into “groups”.
Each group contains the data needed to play music.
It generally holds a handful of modules:
Sample data,
Instrument data that references the samples,
and sequence data that references the instruments.
The Group Manager allows you to keep tabs on how many samples you’ve loaded
(since there is a limit of 64), and other stats.
It also tells you how much memory you’ve used, since the SNES’s APU RAM is so tiny.
Want to dive into these modules?
Unfortunately, that isn’t something that anyone has emulated yet.
You can open each of these windows, but they are entirely unresponsive unless you have the hardware.
The manual even says that the sample preview button starts by downloading your edits to the SNES.
Despite the lack of, uh, Anything functioning today,
you can still tell this is essentially the SNES version of GEMS:
every function you need has its own window, carefully organized by 90s standards,
and you interface with the program via MIDI input.
Ok, but really. How do you make SNES music in 1995?
In short, there is no standard.
It’s a free-for-all and your best bet is whatever tools your boss gave you.
Sadly, this hasn’t changed too much since then.
Most of the SNES tools today are very hacked together.
Literal hacks for popular games like Super Mario World,
or scripts that convert oldschool module formats to SPC files.
Ideally, there’d be a tracker that supports the hardware.
The multi-system tracker Deflemask currently doesn’t support the SNES.
“SNES Tracker”, what should be the monolithic unassailable program for working with SNES music,
is currently the name of two different programs,
one of which is unreleased, and the other is still in early development.
Personally, I recommend the VST C700 if you want to work with SNES music today.
And with that, I leave you with another cover of Laxity’s “I’m a Dick”,
this time with the Kankichi samples.