The life and chimes of the Reveal SC600 sound card

In year 1996 I got my first sound card: a Reveal SoundFX Wave 32, codename SC600. Little did I knew, in that era of rapid hardware progress, that the quality of its MIDI rendering would not be matched by any of my later PCs. However, recently I managed to make a small step towards resurrecting those lost sounds: a small modification to the Ensoniq S-2000 soundfont has produced the first .sf2 file that can genuinely be named after the SC600.

The soundfont is not a masterpiece: the technique used to make it is barely more than a spray of vibe coding over the work of competent people, and I cannot even share the resulting file because I could not (yet?) convince the rightholder to give their permission. However, the project was a good occasion to piece together what it’s currently known about this obscure Reveal soundcard.

Before we go into the details, here a couple of MIDI demo videos, rendered with the SC600 font. You can compare them with the S-2000 version for reference.

A partial history of the SC600

The origins

The SC600 has two parents, Reveal Computer Products and Ensoniq Corporation.

Most of the technology was made by Ensoniq, by far the more important company of the two. Founded in 1982 by some of the designers of the Commodore 64, Ensoniq had gained a very good reputation as producer of samplers and synthesizers. They also made sound chips for other manufacturers like Apple and Taito. I never used their products personally, but many signs speak of a company loved by its customers: a slightly emphatic Wikipedia article, a user magazine (Transoniq Hacker) published throughout almost the whole company’s history, a dedicated subreddit still active decades after the company’s demise.

In 1991, Ensoniq decided to enter the emerging market of sound cards for computers. The development took years: only in 1993 they managed to produce their first product, a demo board called S-1000. The card was based on the homemade ES-5506 “OTTO” synthesizer chip and ES-5706 “ODIE” control gate array, complemented by a Motorola 68EC000 controller.

The S-1000 was not a commercial product: while Ensoniq meant it as prototype for their own future card, they also offered it as guideline for other companies showing how to manufacture a sound card using Ensoniq’s components. One OEM took up the offer: Reveal Computer Products.

The story of Reveal is short and unremarkable. It was founded in 1992 as subsidiary of Packard Bell, which in that era was the equivalent of modern-day Dell: a company focusing on the mass market, boasting huge sales numbers and providing adequate quality at cheap price, but not famous for revolutionary products.

Reveal took the S-1000 design and added two components: a CS4248 codec to offer better Sound Blaster emulation, and a TDA8421 chip adding hardware-based tone control. The Reveal card was apparently “built by Lung Wha in Taiwan”¹; I could not find out who or what Lung Wha is, but I suppose it refers to the Lunghwa University of Science and Technology.

The resulting product got the internal code of SC600. Its premises were good: base design from a reputed supplier, manufactured by a company with experience in delivering mass-produced items without cutting too many edges. I am perplexed by the marketing choices, however.

First: the card was baptised Reveal SoundFX Wave 32, a name that manages to be long and unmemorable at the same time, and also barely distinguishable from Reveal’s former cards SoundFX Wave (an unrelated Crystal-based design) and SoundFX (Reveal’s first model, without wavetable). Which is why I use the name “SC600” throughout this article.

Second: the packaging seems right out of the worst AliExpress shops. Even if the Nineties were more colorful than the present day, the box really does not inspire confidence in the seriousness of the company behind it.

The fall

The SC600 was offered as middle-of-the-road product: the Ensoniq components put it widely above cheap cards without wavetable synthesis, but not at the level of professional equipment. A comparative review by PC Magazine (October 1994) declares the SC600 as having “the best wavetable sounds of the group”.

I have no sales numbers, but Ensoniq must have liked what they saw, and they followed a very similar approach for their first commercial card, the Soundscape S-2000. Again, they took the S-1000 prototype and added a chip to improve the Sound Blaster emulation (in its case, the AD1848), but no tone control. The result was very similar to the SC600, moreso since the two cards shipped the same software suite, provided by Voyetra Technologies.

Even the drivers were probably developed in parallel: the Reveal SC600 uses an initialization program called SSINIT.EXE, an environment variable called SNDSCAPE and a firmware named SNDSCAPE.COD: everything was clearly taken and adapted from Ensoniq’s software. The resemblance is so strong that the SC600 is usually defined “a OEM clone of the S-2000”: it’s not technically true (rather, the two cards are close relatives of the common S-1000 ancestor) but very close.

The S-2000 never got the prestige of the top products by Roland and Turtle Beach, but it enjoyed a much better brand recognition than its Reveal cousin. Some games even support it natively. A 1995 PC Magazine review was not enthusiastic about it, speaking of “respectable” wavetable sound quality, “good for a card in this price range”: it’s quite inconsistent with the 1994 judgment, and neither the lack of tone control nor the later era justify such a fall in the evaluation, but it matches other contemporary reviews².

Ensoniq made good money on the S-2000 and went on to produce other well received cards. Reveal didn’t have the same luck, and apparently its financial condition deteriorated quickly. First it stripped the tone control chip from its card (producing the inferior SC600 rev. 3), then, around May 1995, it stopped its production, also informing its customers that it would not offer driver updates. Some months later Creative Labs expressed interest in acquiring it, but dropped the offer after seeing Reveal’s financials. After months of agony, Reveal went bankrupt in October 1996.

The owners of SoundFX cards were left with an orphan product. Ensoniq’s engineers, out of goodwill, adapted their drivers to partially support the SC600 – I can see why this company is still well remembered today – but Reveal and its products soon disappeared from memory.

Ensoniq did not survive for much longer: computers soon started to integrate low-cost sound capabilities directly on their chipset, destroying the demand for separate audio cards, and the other businesses of the company were not strong enough to support it. The owners saw the writing on the wall³ and sold out to Creative Labs in 1998.

The archaeology

The SC600 and its cousin S-2000 went largely forgotten for long time, as well as their technology.

An exception was the appearance of a driver to emulate the OTTO chip in MAME, written by Aaron Giles around year 2000. The source code and its comments may be just a footnote in Giles’s formidable career, but they reveal a lot about the component.

After this, not much appeared for years. But slowly, historians and nostalgics started to collect information about the technology and history of the Soundscapy soundcard family. Most of the action happened on the Vogons forum.

Some examples: a 2008 thread offers a dense but informative overview of the S-2000, as well as pointing out that a patent filed by Ensoniq contains information about the internal structures used by the initialization code. A 2009 thread provides detailed photos of the SC600’s jumpers.

But what revived my interest in the SC600 is the monumental Wavetable sample thread by user Boxpressed, who compared dozens of sound cards by playing the same set of game soundtracks on each. He published recordings of both the S-2000 and the SC600, and hearing the rendition of Doom’s level 1 music reminded me how much better were those cards in comparison to my current setup. Also, Boxpressed praised “Soundscape[’s] excellent GM music”, but he added “I prefer the sound of the SC600”, making me aware for the first time that my Reveal was not a simple clone, but it featured some mysterious extra component.

The next breakthrough happened in 2018. Michal Necasek, webmaster of the OS/2 Museum, published a program to dump the instrument ROM of the S-2000, and complemented it with an in-depth article about the soundcard. The dumper was an impressive hack in and of itself, but even more importantly, it inspired developer Dave Odell to publish a software to convert the downloaded data into a soundfont. The software, now called sdgi2sf2, was first published in 2020: finally one could listen to the sound of Ensoniq’s waveforms without needing to own a card and a PC with an ISA bus.

I have been happily using the soundfont producted by Odell’s converter till today. Something goes inevitably lost when squeezing a complex hardware device into the .sf2 format, but the result is still very satisfying. Yet, an itch remained: I would have liked to introduce that small perk that the SC600 had with respect to the S-2000. But my knowledge was too scarce, and dedicating months to learn the techniques would have meant neglecting other hobbies and projects. I shelved the idea for years, till LLM models provided what I needed: a way for the incompetent to jury-rig any project of his liking with a passable chance of getting a result.

And so, I decided to try my hand at building a SC600 soundfont. The time was favourable, since Michael Karcher, longtime contributor to Vogons and to the ALSA project, has recently published a extremely detailed analysis of the Soundscape family, illustrating the little differences between each card and providing technical details useful for future tinkerers. He is putting this knowledge to good use, in particular developing a tool to “upload custom waveforms and (re)program instruments”. His thread helped me to define a plan of action.

A tentative reconstruction

The strategy was to start from the S-2000 file produced by sdgi2sf2, and adjust it to fit the output of the SC600. My first idea was a full multidimensional optimization: given the soundfont parameters 𝒙, let 𝒀 = 𝑓(𝒙) be the wave emitted by playing a set of reference MIDI files with such soundfont. Find the parameters that minimize the loss function ‖𝒀 - 𝒀_ref‖, with 𝒀_ref being the output of the real card on such files.

I’d still like to go into this research direction one day, but the task seemed unpractical: my old SC600 is not functional at the moment, so the only available reference audio are the four recordings published by Boxpressed, which are complex polyphonic soundtracks and do not allow to isolate single notes and instruments. Instead, I went for a simple method: identify the differences between the S-2000 and the SC600, and try to mirror them in the soundfont. I knew that the Philips TDA8421 tone control chip was the main addition that set the SC600 apart from its cousin, but was there anything else?

The first possible difference was in the instrument ROM, containing the wavetable samples. This turned out to be identical between and S2000 and SC600, which was not a big surprise: the same ROM, with checksum 9FDC4825, was also used in various arcades featuring the OTTO chip, such as BloodStorm (an arcade that Aaron Giles had ported to MAME, likely the reason why he created the OTTO driver).

The other two candidates for the differential analysis were the firmware of the on-board processor (OBP) and the soundtrack recordings provided by Boxpressed on a post in his Vogons thread.

Diffing the waves

I started with the soundtracks. Even an untrained listener can hear differences in the renderings of the two cards, but it’s hard to describe them, and even more to find out the reasons. I limited myself to the spectral analysis.

Considering that the audio files were downloaded in .mp3 format, it’s hard to tell from a single recording how much is an effective discrepancy and how much is just recording noise and compression artifacts. However, after dividing the spectrum in discrete bands and comparing the other tracks, I was happy to find very consistent results across the different pieces:

Diffing the bits

I turned my attention to the OBP firmware (SNDSCAPE.COD), which can be found on the sound card diskettes since the driver must upload it after every reboot. For the S-2000, two version of the firmware where released; the later one is easier to find, but it’s less useful for a direct comparison. Thanks to a tip, however, I could locate the first version, which is much more similar to SC600 one.

As mentioned by Necasek in his article about ROM dumping, the OBP firmware is byte-swapped. Unscrambling the file reveals this message:

Copyright (c) 1990-1 David Sparks. Copyright (c) 1992-3 Sequoia Development Group, Inc. All Rights Reserved. This program is the proprietary property of David Sparks and Sequoia Development Group, Inc. and is protected by copyright law and international treaties. Unauthorized duplication is prohibited and will be prosecuted to the maximum extent of the law. Life is either a daring adventure… or nothing - Helen Keller

Unfortunately, the web reveals no information about Mr. Sparks; more fruitful was learning about Ms. Keller, but not for the scope of this article.

The message is preceeded by a timestamp, which differs between the two cards: “Mon Jan 24 1994 17:56” for the SC600, “Tue Apr 5 1994 10:55” for the S-2000. Again, this supports the fact that the Reveal card was the older brother.

The rest of the binary files is a mixture of data and Motorola 68000 machine code. Reverse engineering it by hand would be interesting but, alas, too much of a time investment. I used OpenCode to find out its structure and the differences between SC600 and S-2000 releases.

The analysis I run on the firmware was very coarse. One of the findings is that a chunk of it, about 8 out of 32 KBytes, consists of data resembling simple mathematical functions.

Whatever its meaning, this data segment is the same between Reveal and Ensoniq firmware, so the difference in timbre does not come from there. Moreover, the LLM reported that even the code parts were for the most part identical. There was only one relevant difference, a routine that the SC600 had and the S-2000 lacked, and that sends data through the I²C bus:

the computed routine 0x4EF4 (the 0x4F50–0x4F7A block). All I2C writes go through helper 0x4F7A, which has no other callers.

The helper 0x4F7A sends 3 bytes: address 0x80 (= I2C slave 0x40, write), then a register byte, then a value byte.

The bytes written during the initialization were given by the hard-coded table at 0x4DCE:

The case for this being the initialization of the tone control circuit was solid: the TDA8421 chip has an address of 0x40, as reported by the I2C Device Directory, and the values sent are consistent with the format of the registers, as documented in the TDA8421 datasheet. So, how was the chip set up?

• 0x00/0x01 = 0xEB → CH1 L/R volume, code 0x2B ≈ −24 dB
• 0x02/0x03 = 0xF6 → CH1 bass/treble code 0x6 = 0 dB (flat)
• 0x04/0x05 = 0xC0 → CH2 L/R volume code 0x00 = ≤−90 dB (headphone silent)

Also, there was a further write made by an instruction at 0x4F50:

• 0x08 = 0xCE|0x20 → CH1 switch: MU=1 (muted), spatial, stereo mode, IN1

Um, this is sure not what I was expecting. The equalizer is put in a neutral position and the output channel is muted. But the riddle is easily solved: the firmware can accept various commands from the host (the driver running on the user’s OS), routed through a dispatch table. One of these commands allows the host to write values into the OBP memory at the addresses 0xEE0C – 0xEE26. When some of them are touched, the function sending data to the tone control chip is run again, and converts those values into settings for the TDA8421:

The write to subaddress 8 should unmute the output channel, at least if some conditions are met. All that remained was to find out when and how the DOS driver sets the EExx memory cells. A look into SSINIT.EXE provided the answer: the program sends the values when it’s run, after uploading the firmware; the numbers are read from SNDSCAPE.INI. In particular, the values of keys Bass and Treble are sent unchanged to the OBP and written in locations 0xEE23 and 0xEE24. The firmware converts them into the gain settings for the tone control chip.

To adjust the tone, the user can either edit the INI file, or set the values in the GUI of SSINIT:

The results of this analysis were encouraging. Not only the final table matches with the findings documented by Michael Karcher, but the default INI file of the SC600 sets Bass=80 and Treble=80, which means the tone control normally boosts both by +3 dB. And this is consistent with what we saw earlier in the spectral analysis of the sample soundtracks.

Making the .sf2

All the evidence suggests that there is no “secret sauce” to the SC600 other than its tone control chip. Can we embed its effect in a soundfont? It takes real skill to do it properly, but I could be content with a symbolic attempt.

So this was the idea: instead of applying the effect of the TDA8421 filter to the output wave, I’d bake it into the original wave samples. The method is unsound – the samples store the reproduction of instrument sounds at an intermediate pitch, it’s the OTTO that plays then at higher or lower frequency to match the desired note – but it turned out to be effective.

To build my proof of concept, precision was not a priority. First I approximated the frequency response curves of the tone control chip with piecewise linear functions, then approximated those approximations with a family of shelving filters.

After that, I created a variant of sdgi2sf2 that passes the ROM samples through such filters before converting them to .sf2 format. The gain for bass and treble can be set via command line parameters.

Not yet done with fiddling, I made a further change to sdgi2sf2: some months ago the program has been improved, calibrating the “attenuation factor” to better match how a real Creative Labs sound card would interpret it. However, I prefer the old version, which I find to give a more pleasant balance of the instrument volume in some parts. So I added a flag to optionally use the legacy attenuation factor.

After some minor extra commits, the result was ready. Providing you have the instrument ROM, you can recreate the SC600 soundfont by building my sdgi2sf2 variant (commit 63e604e8) and running this command:

./sdgi2sf2 -i -c -b +3 -t +3 -p ensoniq-rom.bin sc600.sf2

# -i : detailed metadata
# -p : show progress

# -c : legacy attenuation factor
# -b +3 : +3 dB bass gain
# -t +3 : +3 dB treble gain

If you dislike my changes, you can use the original version by Dave Odell instead. In practice my clunky tone control and the other additions, for the good and the bad, do not change the result so much: as I said, creating a SC600 font was more about fulfilling a personal wish than about sound quality.

Conclusion

The last years have been good ones for the fans of the Soundscape family: the contributions on Vogons and other retro sites are revealing more and more of the lost knowledge about the card. Meanwhile, Dave Odell is still working on his sf2 generator, in the quest to produce the best possible soundfont out of the instrument ROM.

When it comes to audio I am a layman: hard to contribute to the work of the experts. But I hope, by collating together fragments of the SC600 story and publishing some attempts to revive its sound, to postpone the day when this small side branch in the history of computer audio will be forgotten.

Perhaps I will return on this topic in future. For now, as appendix, here’s a tour of the SSINIT tool used to initialize the SC600. The video description reveals an Easter Egg of the program.