While digging into the implementation of Sound Blaster compatibility on PCI cards, I found an unexpected gem. Ensoniq’s U.S. Patent 5,790,837 includes partial source code for the Sound Blaster emulation driver used with the Ensoniq Soundscape VIVO boards, SSINIT.COM.
Ensoniq Soundscape VIVO
The VIVO boards were Ensoniq’s last ISA-based product (introduced in 1995) and shared a common trait with the PCI-based ES1370 and later devices: There was no hardware Sound Blaster compatibility. Instead, Sound Blaster digital audio as well as AdLib FM synthesis were emulated.
Now the VIVO was a bit of a mixed bag. While the Sound Blaster compatibility wasn’t bad, it required EMM386 and a TSR and was therefore fundamentally incompatible with certain games. The AdLib emulation was not so much emulation as approximation, as it tried to replace a FM synth with wavetable synthesis, with mixed results. On the upside, the wavetable synth (1MB ROM) was not at all bad, and the cards were cheap (and therefore used in many OEM systems).
The card used Sound Blaster emulation not unlike that of old Gravis UltraSound cards. The VIVO chip decoded the Sound Blaster address ranges but only triggered an NMI. The software driver did the actual work.
Ensoniq used clever (or possibly insane) techniques to ensure that the emulation worked even in protected mode, which was rather important at the time (think DOOM II). The driver hooked into EMM386’s VCPI implementation in order to keep control when a DOS extender switched to 32-bit protected mode.
So this would all be quite interesting, right? Unfortunately, the patent text does not contain the code. It’s only in the PDF version of the patent, it’s not OCRed, and the scan quality isn’t great.
It’s around 50 pages of assembler printouts, with a few pages of C thrown in. It’s unclear how complete the source code is. It includes code to do the hooking and at least some Sound Blaster, AdLib, and MPU-401 emulation, as well as the loader (actual SSINIT.COM), and SCOPE.EXE (written in C). It does not appear to include code related to the wavetable synth on the VIVO.
It is apparent that Ensoniq put the bulk of the code into extended memory in order to minimize conventional memory usage, which is itself at least somewhat interesting, if not unique or novel.
The SSINIT.COM source code indicates version 3.22, which matches the released VIVO drivers. All in all, the patent and the source code are interesting reading.
Note: Several versions of the patent exist, with as yet unknown differences.
Pretty good analysis. I can’t believe anyone cares. I wrote it – the code and the patent. There’s more to it…
Ah, that probably explain why this patent is much more readable than the usual obfuscated legalese. Anyway, some people care — it’s part of the history of technology, for one thing. Also it’s pretty clever, and that’s always interesting.
Any hints as to what more to it there is? And how did you come across this post so quickly? It typically takes 2-3 years for completely unexpected yet relevant replies 🙂
The source code included was only that which represented the preferred embodiment of the patent – so, basically, the code that hooked the system. What was not included was the wavetable synthesizer and most of the actual device emulation code (SoundBlaster/Soundscape/WSS). And yes, all of this was in extended memory as flat-32 code. It was pretty much a big, 32-bit XMS TSR.
It’s hard to simply read that code and figure out what’s going on. But, aside from the emulation itself, there were two main components. The first was the hooking of the EMM386 protected-mode (PM) environment, most importantly the VCPI interface. This was done statically by ssinit/scope. (Scope itself was a 32-bit DOS Extender app running under DOS4GW, created using Watcom 10.0 compiler/linker. Without this, ssinit could not have gotten is claws into the PM environment.) The second was dynamically hooking into DOS extender applications (both 16-bit and 32-bit) as they launched, as they created parallel PM environments. Then, the extender’s IDT vectors had to be ‘monitored. ‘ All of this simply to ensure that the NMI got serviced by the right handler. (The default NMI behavior of the OS and the extenders was to reboot the system.)
VIVO was, of course, the first implementation. Interestingly, all this did was allow us to take a microprocessor (68EC000) off of the board and moderately decrease the cost. As you can see, the wavetable ASIC (OTTO) and sound ROM were still on the board. SB emulation was not that difficult with VIVO as it was on the ISA bus and directly drove IRQ 5 or 7. Things got way more interesting with the PCI devices.
When the PCI devices were developed (ES1370/1/3), the Pentium 90 with MMX was the baseline CPU. This allowed us to go totally soft with the wavetable synth. So, OTTO and the sound ROM disappeared and the wavesamples were moved into XMS. More importantly, the 8237A had to be partially virtualized in order to emulate ISA DMA programming and progress. Also, since we did not want to struggle with the IRQ mapping, the arbitrarily-assigned PCI IRQ was reflected as virtual IRQ 5 or 7, so the 8259 was also partially virtualized. During 137x development, the system hooking scheme evolved a little. For example, we moved some of the v86 hooks into the PM IDT. These improvements were filed in a followup patent which is why, as you noted, several exist.
There was an interesting problem with the NMI – whether it was ISA or PCI #SERR: The NMI was maskable (imagine that) via a register that was part of the RTC implementation. In the legacy implementations, this register (at IO port 0x70) had the RTC register index at bits 0-6 and the NMI mask at bit 7, and the register was not readable. For this reason, developers that messed with the RTC had to write some value to bit 7. A 1 was commonly written which masked the NMI. The ISA and PCI solutions solved this problem differently. PCI used ‘Mr. Hand,’ referred to in the spec as HIB. I’ll leave that one to your imagination …
I assume that “splonge386” is one of the inventors listed in the patent, right?
see first comment
Pingback: Dumping Ensoniq Soundscape ROMs | OS/2 Museum