The talk is, of course, about Turtle Beach sound cards. I finally got hold of a 1994 Turtle Beach Rio daughterboard which came mounted on an ISA sound card. On closer inspection the card turned out to be a Turtle Beach Tahiti, the second generation of Turtle Beach’s famous MultSound line of semi-professional cards. And while the Tahiti ($259) and Rio ($139) were available separately, they were also sold as a combo called Monterey ($349).
The first MultiSound (retroactively renamed to MultiSound Classic) was a 1991 design combining high-quality 18-bit converters, a Motorola 56001 DSP, and an E-mu Proteus 1/XR synthesizer. It is worth mentioning that the Proteus 1/XR was a very close relative of the original Wave Blaster and appears to be some variant of the E-mu SoundEngine.
In 1993, E-mu was acquired by Creative Technology, and the SoundEngine was no longer available to OEMs. In an unrelated development, Turtle Beach was bought by ICS, and ICS marketed the WaveFront synthesizer chipset.
With the Proteus 1/XR no longer available, Turtle Beach was forced to redesign the MultiSound for a 1994 release. The new board, MultiSound Tahiti, had minimal differences from the original, except it had no onboard synth at all and instead there was a 26-pin Wave Blaster connector. That connector ideally carried Turtle Beach’s own Rio, a General MIDI daughterboard based on the ICS WaveFront with a 4 MB ROM. More about the Rio later.
The MultiSound saga was not over. In December 1996, ICS sold Turtle Beach to Voyetra; the WaveFront synth was no longer marketed, so Turtle Beach had to switch suppliers again. The third and last synth was a Kurzweil MASS. There were two variants of the final MultiSound: A synth-less Fiji, and a full-length Pinnacle. The last MultiSound cards had 20-bit converters, slightly updated DSP, and were built at least until 1998, making them one of the last ISA sound card designs.
Turtle Beach Rio
The Rio is a standard Wave Blaster compatible daughterboard with one unique feature and one caveat. The unique feature is fairly obvious… yes, that’s a RAM module (30-pin SIPP no less) sticking out. The Rio is also a sampler with up to 4 MB RAM. It has just one huge downside: The only way to transfer samples is MIDI, and transferring a megabyte or two of sample data over MIDI (at slightly over 30 kbps) is… very… very… excruciatingly… slow.
As an aside, Turtle Beach offered several other boards (Maui, Tropez) with the exact same WaveFront synth which could address the sample RAM more directly and did not suffer from the extreme slowness (and also used SIMM rather than SIPP modules).
The caveat is indirectly related. The Rio is obviously an advanced MIDI device and it not only receives but also sends MIDI data. Turtle Beach learned the hard way that many cards (including some, but not all, Sound Blaster 16 models) do not support daughterboard to host communication. Turtle Beach worked around it in software and supported only slightly restricted operation on such crippled host cards.
I was eager to try the SampleStore (Turtle Beach’s marketing name) feature and upload a sample or two to the Rio. But despite trying several known good SIPPs and despite INI file tweaks to set the RAM size, the Rio Control Panel stubbornly refused to see any RAM at all.
Then I remembered that although the component side of my Rio looks like new, the reverse side had a suspicious gouge. And sure enough, one trace was broken, and it was a trace leading to the memory module. Duh!
After a short soldering session the broken trace was worked around and lo and behold, suddenly the Rio had RAM! The Rio is actually clever enough to detect and report the RAM size, and does not need to be told how much memory it has installed (in fact it actively ignores that setting). Plug and Play in action.
And yes, as mentioned earlier, uploading samples to the Rio really is really painfully slow.
Rio Questions and Some Answers
Examining the Rio, I had several burning question. I though I’d pose them on this blog, but by the time I managed to do that, I found most of the answers.
The first question was: What’s that funny chip on the Rio? There’s an 80-pin PQFP chip with a Motorola logo and SSP4240220FJ27 designation. No such chip apparently exists, or at least no documentation turned up.
Thinking about what the Rio can do, it should be an effects processor, especially since it seems to be hooked up to two RAM chips. The WaveFront has no built-in effects, but the Rio does have global effects, so those need to be implemented somewhere… and the mysterious SSP chip is really the only option. (The other Motorola chip on the Rio is an embedded 68k CPU driving the MIDI engine.)
Review of the ICS datasheets confirmed that the WaveFront synth (specifically the ICS2116 interface chip) can be hooked up to a DSP. The datasheet says: For systems not using the ISA bus, the WaveFront Interface can convert the serial output of the synthesizer into a form that a reduced-function Motorola 56001 DSP can read. This allows for global digital effects (such as reverb and chorus) to enhance the audio signal.
So yes, the Motorola SSP chip is probably some custom simplified version of the Motorola 56001 DSP. Note that this is only a global effects processor, with no control on the individual instrument/patch level. But it certainly helps.
Versions and Rework
There are several versions of the Rio. At least 2.0, 2.1, and 3.0 have been spotted. The differences between them are unclear, but I dug up evidence that the original Rios had a problem causing high-pitched whine on the Tahiti board.
Back in the day, Rick LaBach came up with a way to rework the Rio in order to get rid of the whine, and explained the whys and wherefores of the modifications. It can be only surmised that Turtle Beach made similar changes in later Rio revisions.
This Rio may have been subjected to a similar rework, or perhaps a different one.
My Rio has unpopulated space where IC U32 would be. It’s not the only one. But there are other Rios (Rev. 2.0, Rev. 3.0) which have an NE5532D dual op-amp in that spot. What’s up with that? I don’t know.
Tahiti Config Trouble
The Tahiti is not a PnP board (thank goodness); it needs one I/O port range, one IRQ, and a 32KB memory range below 1 MB. The board has DIP switches to select the I/O range which someone fortunately documented, and the memory and IRQ settings are software programmable.
I had no trouble with the memory range—it could be placed at C800-CFFF, causing minimal disruption. I did not have much luck with the default setting of IRQ 9 and moved it to 5. I believe IRQ 9 was configured for PCI use and I didn’t try to change that.
Some newer motherboards reportedly use IRQ 9 for ACPI and provide no setting to change that. In such cases, the Tahiti can’t use IRQ 9 even in a completely non-ACPI OS like DOS/Windows 3.1. I presume it’s because the interrupt controller is programmed for level-triggering which won’t work with an ISA board. It is possible (but untested) that reprogramming the ELCR would fix that.
And finally, for reasons I do not understand, I could not get my Tahiti to work with the default I/O port range at 290h. The board was simply not there, or in any other supported range. Setting it to 3E0h worked fine. I currently have no explanation for that. I don’t believe anything occupies the port range (Intel 430HX chipset) but have not yet tried multiple boards to determine if it’s the board or the Tahiti that’s causing the problem.
I apologize for not providing any recordings from the Rio at this point. Maybe later.
PIIX4 has IRQ 9 hardcoded for ACPI SCI, but this should not affect non-ACPI OSes.
See article. It will if IRQ 9 is programmed to level-triggered and OS expects it to be edge-triggered (which DOS does).
That would be a BIOS bug.
How so? The SCI is required to be PCI compatible. The only bug (so to speak) is that some BIOSes do not allow ACPI to be turned off at all.
I believe that the PIIX4 automatically change it to level triggered when SCI_EN is enabled.
I can’t find that documented anywhere in the datasheet. Could you please point me to the relevant text?
The spec update has a good table:
I see the table (page 37) and it’s even worse: “Any time an SCI, SMB or PIRQ is programmed to use the internal 8259’s IRQ9, the PIIX4/PIIX4E/PIIX4M will ignore the ISA IRQ9 and the interrupts will behave like level triggered interrupts.” I really don’t know why the chipset would ignore the ELCR, but if it does, undoing the damage done by the BIOS would just require a few more bits to be flipped.
First make sure PCI interrupts are not routed there.
It really depends on the board. Most of the 440BX boards I’ve had allowed ACPI to be completely turned off (and APM turned on), which freed IRQ 9 for other uses. I can’t recall if ISA devices worked on IRQ 9 or not though, its been awhile.
The DSP inclusion is interesting. The Atari Falcon of 1992 had that same model 56001 DSP and at 32mhz was powerful enough to decode and play 128kbps MP3s in combination with the 68030 CPU (also hamstrung with a 16bit bus to keep it compatible with older Atari designs). That means you could use this even on a low end 386 to play mp3s perhaps using the onboard memory of the card with the right software.
Interesting thought. Yes, I believe the Tahiti may well be capable of something like that, although I’m not sure how fast the DSP runs. (There’s a 40 MHz crystal next to it… does that mean 40 or 20 MHz clock speed? Or something else?) I believe Turtle Beach quoted it as running with ’16 MIPS’ (20 MIPS for the Fiji/Pinnacle). I think the Tahiti does not have a lot of RAM but it it can certainly transfer data fast enough.
The Rio is a completely different beast and it’s unclear how programmable the effects DSP really is, or what it can do.
Most DSPs sadly went unused due to the difficulty of programming them. Doubtful any MP3 player software actually exists due to the rarity of this hardware though.
Speaking of software, do these cards have any Soundblaster or DOS game support?
I think these cards were mostly gone before MP3s became really popular, too. The DSP on the MultiSound cards definitely was used by the drivers, but I don’t think the DSP was ever meant to be end-user programmable. It could do things like equalization which would have been quite time consuming on the CPU in the early 1990s.
The MultiSound cards had no DOS game support to speak of, and they were not SB compatible. They were never intended as game cards, not any more than DAL or RME or Marian or Egosys or similar cards. That said, the Rio was perfectly usable as a General MIDI wavetable daughterboard, with the caveat that neither the original MultiSound nor the Tahiti were MPU-401 compatible — but the Rio could be mounted on any card with a Wave Blaster header.
The MultiSound card as such was usable in DOS, and I think it was supported by packages like Voyetra’s sequencer. At least for the Tahiti/Monterey though, the software shipped with the card was essentially all Windows-based.
Only the TB Pinnacle was MPU-401 compatible, and the onboard synth can be used with DOS games for music without trouble (and it’s not a bad synth at all).
So speaking of DSP-assisted MP3 players. Not surprisingly, this has been already thought of — kinda. IBM’s Mwave DSP had support for decoding of the audio stream of MPEG video. I don’t know if it handled layer II or III or what, but it did something. Circa 1995.
With only MIDI to send digital data from the host to the daughter card, you would have to upload the MP3 file to RAM on the card before playing. Tedious but better than nothing if it were your only choice.
Michal Necasek says:
“the DSP on the MultiSound cards definitely was used by the drivers, but I don’t think the DSP was ever meant to be end-user programmable.”
The 56000 DSP in the original Multisound was meant to be programmed by users, there is a programming doc around somewhere, and I have a dos program that is supposed to use the DSP on the Multisound to give realtime basic effects (delay, chrous. reverb) from the input to the output of the card, but I could never get the program to work. Incidentally the main software that was sold with Multisounds was a four-track DAW called Quad. It and SAW were the first DAWs for PC (Windows 3).
Is any of the documentation/tools online? If not, any chance you could scan/copy? I have the original Multisound board with the Proteus synth in the basement, but not a lot of software.
I think the programming doc is here, as “Turtle Beach Multisound series Software Developers Kit”:
I’ll look around for the dos prog, I’m sure it’s on my win98 machine but I don’t have that operational at the moment, so it might take me a few days…
You’re right, I think I even saw that SDK before. From what I recall it assumed experience with programming the Motorola 56K DSP, which probably prevented a more widespread use (that plus the fact that the MultiSound cards themselves never were all that common). Too bad really, I’m sure the DSP could have been used for a lot of interesting custom applications.
I know proprietary software with its own low level drivers take advantage of this card fully (except the synth) for loud speaker analysis, Thiele-Small that kind of stuff. I know because I sold one from my stash to a person for that purpose not many years ago.
Also Turtle Beach sold a software for multitrack recordings called Quad which benefited from having 2 multisounds at the same time and you could capture 4 tracks at 16 bits 44.100 Hz at the same time supposedly in a 486 class PC