This thread is supposed to cover sound cards based on the Ensoniq ODIE (ES5607) control chip, which connects a MC68000-family microprocessor, an Ensoniq OTTO wavetable synthesizer, some onboard RAM, a wavetable ROM and the ISA bus. You often see the name "Sequoia" associated with the ODIE chip, which is not surprising, as "Sequoia" is printed on that chip, while "ODIE" (which is the name of that chip according to the datasheet) is not printed on the chip! "Sequoia" refers to Sequoia Development Group, who designed the ES5706 chip and the "Mockingbird-OTTO" synthesizer firmware.

I know of these ODIE-based sound cards, which can all be found on http://www.yjfy.com/museum/sound/Ensoniq.htm as well.

• FCC ID KUIX-TECHSND001, as seen in Re: Found an Ensoniq Soundscape Elite... but it's corroded! . The FCC ID for this card is registered to a Taiwanese company called "X Technonolgy Co", and the product is named "X-TECHSND001" according the the registration document. I don't know where to find official software for that card.
• Suk Jung Eled.Co. SJ-MS01, which seems to be similar the the X-TECHSND001, but it has SIMM sockets, which can be used to add sample RAM.
• The Reveal SC600 (aka Reveal SoundFX Wave 32), which has FCC ID FODSWFX1000. The FCC ID belongs to Packard Bell, which is not surprising, as Reveal is a subsidiary of Packard Bell
• The Ensoniq Soundscape S-2000, which has the FCC ID LF7SS2016.
• The Ensoniq Soundscape Elite, which also uses the FCC ID LF7SS2016. This card is mostly the same as the S-2000, but it provides pin headers to connect a daugtherboard containing the Ensoniq ES5501. The Elite also has an IDE port, while the S-2000 only has the classic legacy CD interfaces.

There also is the later SoundScape Opus card, which again uses the FCC ID LF7SS2016. The OPUS chip on the Opus card likely integrates the ODIE and the OTTO into one chip, but I define the Opus as "out of scope" for this thread, because it does not use the original ODIE chip.

Furthermore, you might wonder why I didn't mention the V7 Spea MediaFX yet, especially as I am from Germany, and the Spea branded sound card was distributed by the budget PC retailer "Vobis", and had a significant market share in Germany. Actually, I met two people that owned a MediaFX, while I met no one that owned an Ensoniq-branded S-2000. The reason is that the MediaFX is just a slightly modified version of either the SC600, or the S-2000. As those cards are not identical, using the same name for both of them is unfortunate, as can be seen in this announcement by VOBIS for their distribution of driver updates. Currently, I assume, that the MediaFX cards behave identically to either the SC600 or the S-2000, and they will be treated in this thread.

The ODIE datasheet does not only describe the ODIE chip (to varying detail levels), but it also describes how to build a PC sound card around the ODIE chip, explicitly naming a lot of support components. Apart from the DAC, the support components match what's on the early cards, that's the X-TECHSND001 and the SJ-MS01. The ODIE datasheet names the Philips TDA1545A DAC(link to alldatasheet.com), while all ODIE cards I've looked at use the NEC µPD6376 (link to alldatasheet.com) instead. Both of these DACs are non-Sigma/Delta-16-bit DACs, if I understand the datasheets correctly, and use the same serial format to receive the samples. I thus assume that the X-TECHSND001 and the SJ-MS01 are the implementation of Sequoia's idea for an ODIE-based PC soundcard, which is already branded as "Ensoniq Soundscape" in that datasheet, and looking at document page 23 (PDF page 24), you actually see the name "S-1000", which I will use for that design.

This table contains a comparison of the ODIE cards:

1                     S-1000          SC600          S-2000
2Synth playback D/A   µPD6376         µPD6376        µPD6376
3Extra WSS codec      no              CS4248         AD1848
4Wave playback        via synth       synth or WSS   synth or WSS
5Wave recording       CXD2555Q        WSS            WSS
6Analog mixer         LMC835          WSS            WSS
7Tone control         none (?)        TDA8421        none

The difference between the CS4248 and the AD1848 seems to be negligible. The CS4248 datasheet explains some minor differences, but I don't think they matter for this thread, and they will collectively be named "WSS" (for "Windows Sound System") in this thread. My interpretation is that the original idea by Sequoia was that their firmware-based Sound Blaster Emulation is good enough for legacy software, and "serious software" will use native ODIE-based wave playback, which offers two pannable 16-bit stereo channels. It seems that this didn't work out (the Sound Blaster emulation was quite bad, by the way), and Reveal did the best thing to do to salvage the design: Put something that is kind of standard for wave playback alongside the ODIE/OTTO-based wave playback, which is an WSS chip, and it is jumperable to the standard WSS base addresses. DMA/IRQ of the WSS chip are routed through the CD interface channel of the ODIE chip (at least on the S-2000, likely on the SC600 as well.

It then seems that after seeing the success of the Reveal design, Ensoniq decided to copy the idea, but ditch the tone control chip, possibly for cost reasons. There are some technical differences between the cards I already know, possibly there are more.

• The ODIE offers four IRQ pins, that need to be routed to the ISA bus. The ODIE datasheet suggests to connect them to IRQs 2, 7, 12 and 15. This actually seems to be how the IRQ lines are wired on the X-TECHSND001. As I don't have a photo of the SJ-MS01, I can only guess that they used the same IRQ assignments. When Reveal designed the SC600, the "standard" Sound Blaster IRQ was changing from 7 to 5, but the suggested ODIE setup did not include IRQ5, so Reveal substituted IRQ12 (which happens to collide with PS/2 mice, but I don't think that was a notable consideration in 1993) by IRQ5, yielding IRQs 2, 7, 5 and 15 (in that order!). The S-2000 offers more conventional Sound Card IRQs: IRQ 2, 5, 7, 10 (in this order!). This means that a tool meant for the Reveal card that tries to set up the card to use IRQ 5 or 7 assigns exactly the other IRQ if it is interfacing with an S-2000 card.
• The Reveal cards connects the POWERDOWN line (which is also a RESET line) of the WSS CoDec to the RESET line of the MC68000 microcontroller, so the AD1848 automatically gets reset when the firmware gets loaded. The S-2000 connects the POWERDOWN line of the WSS CoDec to the CDRST (CD interface reset) line. I could not find a way to trigger a CD reset from software.

Now, these difference are minor and likely insignificant, unless you want to write a driver for those cards. There is a reason why I am quite interested in them, though. There are two entirely different firmware variants for the S-2000 card. There is an addendum to the user manual released with software version 1.2 explaining all the differences. While I know someone who was using the pre-1.2 software with a (likely?) type-2 MediaFX, the pre-1.2 software for S-2000 cards seems to have vanished from the internet. But Horun kindly uploaded the pre-1.2 software for the Reveal SC600 card to vogonsdrivers. I am trying to get that software working with my S-2000 card, and ran into various difficulties. While I already knew about the different IRQ routings, I tried to use the "safe" IRQ2, just to hit a supposed mainboard BIOS bug of my Biostar MB-8433UUD (as this is a community-modded BIOS, I won't blame the vendor yet, although that bug is unlikely to be affected by the community mods, mostly modbin-like stuff). On AT computers, IRQ2 does not exist, but exists as IRQ9 instead. The BIOS installs an IRQ9 handler that forwards IRQ9 to IRQ2, which provides compatiblity with PC/XT software that expects IRQ2 to be invoked. The IRQ9 handler forwarding to IRQ2 obviously only gets invoked if IRQ9 is unmasked, but my BIOS boots DOS with IRQ9 masked, and a program (like the early Reveal SSINIT.EXE) that just hooks IRQ2 and unmasks IRQ2 will not get IRQ9, because that one is still masked.

The next post is this thread will describe how to patch the SC600 SSINIT to be compatible with the Ensoniq S-2000 card. This does not only involve changing the IRQ routing tables (which then can be patched to use "9" instead of "2" as well), but I also noticed that SSINIT only works one time after a cold boot. The second time it complains that the WSS CoDec is not responding correctly. This is because the SC600 SSINIT tool expects to find the AD1848/CS4248 in the state after reset after uploading the firmware. On the SC600, every firmware upload resets the WSS CoDec, so this works. On the S-2000, the WSS CoDec is only reset by the ISA RESET line, so on the second run, the CoDec does not respond as expected, which will cause an error message.

Interestingly, the SC600 SSINIT seems to be compiled targetting the 8086/8088 processor, so it might actually be interesting to test the S-2000 in an XT, but this will be for a later topic.

To end this post, I will explain shortly, why I consider the "old" firmware quite interesting: While the post-1.2 firmware is definitely better for gaming (it has a kind-of okay soundblaster emulation), it did away with some interesting features of the old firmware, which seems to be the "Mockingbird-OTTO firmware" mentioned in the datasheet. The Mockingbird firmware has two features that set it apart from the later firmware: For one, it supports two pannable stereo playback channels through the ODIE/OTTO system. On WSS-equipped cards (i.e. everything except the S-1000), this yields 3 independent stereo wave channels, which are acutally all usable with the Windows drivers in the SC600 package. The 1.2 software (and all later software) only offers the WSS playback channel in Windows. But the real kicker is: The Mockingbird firmware allows custom samples for the MIDI synthesizer. This obviously is quite lame for the SC600 or S-2000 as they only have 128K of RAM, which also contains the firmware, but you should be able to bodge a 2MB RAM chip to an S-2000, and get it supported. Even without extra RAM, being able to tune the synthesizer parameters might prove interesting.

I know I repeatedly overpromised stuff I wanted to do, but I really try to document how the synthesizer parameters on the Mockingbird firmware work, how to upload custom waveforms and how to (re)program instruments. So while I recommend you don't hold your breath till this stuff is delivered, there is some hope I will deliver.