I'm totally not knowledgeable concerning Ensoniq cards but do like some soundcard history. One thing that caught my interest: "The Mockingbird firmware allows custom samples for the MIDI synthesizer".

The Turtle Beach Wavepatch documentation mentions the ICS Mockingbird sample format:

"The Replace Internal Sample command is used to replace an internal sample with an external sample file. It differs from the SampleStore command and the various Load Sample buttons in two ways:

1. It allows internal ROM samples to be replaced, and
2. it allows samples in the proprietary ICS Mockingbird format to be loaded."

Seeing how the ICS WaveFront is clearly inspired by the GF1 and the GF1 is related to Ensoniq it makes me wonder if it's related.

From WFGATAPI.H (part of the WaveFront SDK):

// WFGATAPI.H
// Interface API for WaveFront Gatekeeper DLL (WFGATE.DLL)
// 2/1/94 J. Johnson
// Copyright ⌐ 1994 Turtle Beach Systems, Inc. All Rights Reserved

// Modified
// 7/18/95 Mark Otto - added functions for use in Tropez PnP for effects
// - Gate(Set/Get)ReverbType
// - Gate(Set/Get)ReverbDepth
// - Gate(Set/Get)ChorusType
// - Gate(Set/Get)ChorusDepth
// - Gate(Set/Get)OtherFXType
// - Gate(Set/Get)OtherFXDepth

#ifndef WFGATAPI_H
#define WFGATAPI_H

// Structures used by the API. These are exact representations of the
// structures specified in the Mockingbird docs.

The name "Mockingbird" is possibly used multiple times independently in the music synthesis business, so there may be a relation, but there need not be one.

The instrument data used by the Mockingbird-OTTO firmware is mentioned in https://www.os2museum.com/wp/dumping-ensoniq- … oundscape-roms/ , and https://gitlab.com/dmo2118/sdgi2sf2 contains a project that can read ROM dumps of the Soundscape cards and produce (approximately?) equivalent SoundFonts from it. This is definitely a valuable resource in understanding the data format.

That's true but seeing Mockingbird mentioned and modifications to code by someone with last name Otto does make you scratch your head. Is there a file date known for the pre-1.2 software? The Reveal package is a mixture of 1993 and 1994 dates, 1994 being the drivers and 1993 being software package? I'm trying to dig up old Turtle Beach stuff, can have a look at Ensoniq stuff as well.

Rawit wrote on 2026-03-24, 08:05:

Is there a file date known for the pre-1.2 software?

Yes, there is. The VOBIS MediaFX update announcement I linked in my initial post (I know, there are a lot of links, I can't expect anyone to follow them all) mentions these pre-1.2 releases:

• Releases dated November 1993, December 1993 and June 1994 for the rebranded SC600 ("MediaFX type 1")
• Relesaes dated April 1994 and June 1994 for the rebranded S-2000 ("MediaFX type 2")

The 1.2 release is dated March 1995.

I don't know about the dates of the files included, but recognizing old vs. new is likely quite easy: The old release only came with one firmware file named "SNDSCAPE.COD", while the 1.2 release started to include firmware files with different extensions for different cards (at some time, SSINIT learned to deal with both the SC600 and the S-2000, but that was not in the original 1.2). The firmware files from the 1.2 release are named "SNDSCAPE.COx" where x is a digit. AFAIK the firmware file for the S-2000 is named SNDSCAPE.CO0 which includes metadata for the sample set in 135-09-016-01 ROM, the usual ROM shipped with S-2000 cards.

Is this something: https://discmaster.textfiles.com/browse/28230 … rdsoft/sndscape

1994, uses the SoundScape name. Contains SNDSCAPE.COD.

And a seperate SNDSCAPE.COD dated 1993 from the Virtuality Arcade hardware:

https://discmaster.textfiles.com/view/7801/da … ts/sndscape.cod

Rawit wrote on 2026-03-24, 10:22:

Is this something: https://discmaster.textfiles.com/browse/28230 … rdsoft/sndscape

Probably that's the driver package I am missing. How did you find it? Did you know discmaster.textfiles.com before, or did some search engine lead you to that host? I never heard of it yet, but it seems to have a very nice file browser supporting nested archives. Most likely, using SSINIT.EXE from that package removes the need to patch the SC600 SSINIT.EXE which is incompatible with the S-2000.

Thank you very much! I will look into it shortly.

I do a lot of searching there, basically a search engine that goes through the Archive.org uploads. Since I discovered it a few years back it's my goto to dig up old stuff. I hope the driver is something useful!

Rawit wrote on 2026-03-24, 13:21:

I do a lot of searching there, basically a search engine that goes through the Archive.org uploads. Since I discovered it a few years back it's my goto to dig up old stuff. I hope the driver is something useful!

I just tested the driver pack with my Spea/V7-branded S-2000, and they worked out of the box, so this driver set removes the need to modify the SC600 driver set to suport the S-2000 instead.

The S-2000 package you linked has a README that contains a change log, with the newest version mentioned being 1.03. SSINIT claims to be version 1.21.

The SC600 package on vogonsdriver does not have a README, and SSINIT claims to be version 2.21.

I suppose that the different major version is just a renumbering. The user interface looks mostly identical, except that the Reveal SSINIT has controls for the TDA8421 bass, treble and stereo enhancement features, while the Ensoniq one doesn't (the Ensoniq card also doesn't have that chip). I also compared the firmware files, which are different as well. Possibly, the TDA8421 support has been removed from the Ensoniq variant of the firmware.

Nevertheless, this is exactly the driver package I assumed to be lost in time, so thanks again for finding it.

So, XT test results are in. With a V20 processor (can execute 286 real mode opcodes), I can initialize the card, and play back MIDI using the DOS drivers/tools delivered with that card. With an 8088, ssinit still works, but the DOS driver for sound/midi playback crashes.

I had issues with digital sound, but I also had issues with digital sound in the computer I tried the card in before, so this might be a general problem with either that driver or my hardware. Furthermore, my XT is acting up, seems the 64k x 1 parity RAM chips are dying and the replacements I ordered from AliExpress are dead on arrival. I tried downgrading to 512K RAM using 256k x 1 chips only, which seems to have cured the problem. Digital sound with V20 does not play back anything and the 8088 still crashes. So I don't think it's my XT hardware, but possibly some issues are in fact due to the XT hardware anyway.

For completeness sake here a link to the SPEA branded one. SSINIT and SNDSCAPE.COD appear to be the same.

Disk 1: https://discmaster.textfiles.com/browse/33128 … 68/FX206941.ZIP
Disk2: https://discmaster.textfiles.com/browse/33128 … 68/FX206942.ZIP

So, this is some intermediate post regarding technical details of the interface between the Mockingbird-OTTO firmware and the host PC. Much of the information contained in this post can also be obtained from the ODIE datasheet, but I'm trying to describe the stuff in more detail with more background and application information.

The ODIE chip provides two bidirectional 8-bit wide communication ports between the ISA bus and the on-board processor (OBP). Each bidirectional port has two 8-bit latches, one for the PC-to-firmware and one for the firmware-to-PC direction. This is a very typical microcontroller interface, and it can be found in a similar way on the Intel 8042 (used for the keyboard controller in the AT) and the Creative Labs SoundBlaster (the SB 1.0 actually did have dedicated latch chips for that). The PC-side of these ports support two modes. One mode is called "6850 emulation", while the other mode is called "MPU401 emulation" mode. It seems the "6850 emulation" mode is closer to the metal, and more flexible, and the MPU401-compatible interface has been added on-top of it due to the sheer amount of MPU401-compatible software. Both modes require 2 I/O ports per communication channel.

So lets get into the basics of the 6850-compatible mode first: In that mode, the first I/O port is the status/control port, while the second I/O port is the data port. The data port is quite straightforward: Reading the data port yields the current content of the firmware-to-PC latch, and resets the "firmware-to-PC latch filled" status bit. Writing the data port updates the PC-to-firmware latch, and set the "PC-to-firmware latch filled" status bit. The control and status port mimick the layout of the 6850 ports, with a slight extension. The "6850" refers to the Motorola MC6850, a common UART chip originally designed for the 6800-series 8-bit microprocessor series.

The control port has this layout

• Bits 0&1: On the MC6850, these bits set the clock divider, allowing 3 different choices, and if both bits are set, the MC6850 including the divider enters reset. On the ODIE chip, only 11b (both bits set) is recognized. The OBP firmware has access to a status bit indicating whether the port is in reset mode or not.
• Bit 2: This bit is entirely different from its use on the MC6850. This bit is just mirrored to the OBP side and can be seen as a "9th data bit" associated with the byte currently in the latch. It is used to provide two logical channels over one port: If this bit is clear, the data byte is intended to be sent to the "command stream"; if this bit is set, the data byte is to the "data stream". The meaning of "command stream" and "data stream" as assigned by the Mockingbird-OTTO firmware is described later.
• Bit 3/4: Ignored
• Bit 5/6: Transmit mode. The MC6850 allows multiple choices, including generating a BREAK condition. ODIE just recognizes 01b as "Transmit interrupt enabled" and all other combinations as "Transmit interrupt disabled". This matches the interrupt enabling behaviour of the MC6850. If set, an interrupt is requested if the firmware-to-PC buffer is empty.
• Bit 7: Recevie interrupt enable: If set, enable interrupt generation if the firmware-to-PC buffer is filled.

The status port on the other hand has this layout:

• Bit 0: Just like on the 6850: Set if the firmware-to-PC buffer is filled, i.e. a data byte is available to be read from the data port
• Bit 1: Just like on the 6850: Set if the PC-to-firmware buffer is empty, i.e. a data byte may be written to the data port
• Bit 2: Just like bit 2 of the control port, this bit mirrors a bit writeable by the firmware, which indicates whether the byte currently available on the data port is part of the "command stream" or the "data stream".
• Bits 3-6: Documented to be always 0 on the ODIE. They indicate various serial port status bits on the 6850.
• Bit 7: Interrupt status bit: This bit is set if an interrupt request is currently active. This is the case if bit 0 of the status port is set and bit 7 of the control port is set, or if bit 1 of the status port is set and bits 5-6 of the control port are 01b (or both conditions apply).

That's basically all there is to say about the hardware interface of that communication channel. The idea of the command/data distinction might be inspired by the host interface of the Intel 8042, which provides two different 8-bit ports the host might write to, and allows the 8042 firmware to look up which port the data was written to. To avoid any confusion: While this command/data distinction is similar to the MIDI protocol, in which bytes less than 128 are data bytes and bytes of 128 or bigger are command bytes, this distinction happens on a lower layer and is not used to distinguish MIDI data bytes from MIDI command bytes. Instead, the Mockingbird-OTTO firmware uses this command/data distinction to multiplex two logical communication channels over the same port (of which there are also two). This means there is support for up to four streams: The data stream on the first communication port, the command stream on the first communication port, the data stream on the second communication port and the command stream on the second communication port. A later part of this post will explain how these streams are used by the firmware.

For compatibility with MPU401 software, the communication ports can be switched into an MPU401-compatible mode. In that mode, there no longer is a control port. Instead, writing to the first I/O port populates the PC-to-host latch and sets the command/data indication to "data", while writing to the second I/O port also populates the PC-to-host latch, but it sets the command/data indication to "command". This is very much like the Intel 8042 operates as well. The contents of the data latch is available on the first I/O port in MPU401 mode, which behaves on read just like the second I/O port does in 6850 mode. On read, the second I/O port is the MPU401 status port:

• Bits 0..5 are always set
• Bit 6 is clear if the PC-to-firmware buffer is empty, i.e. you may write data to the data I/O port or the command I/O port
• Bit 7 is clear if the firmware-to-PC buffer is filled, i.e. you can read (new) data from the data I/O port.

Note that there is not command/data distinguishing bit in the MPU401 status port (for compatibility with the MPU401, which also doesn't have a bit like this), and there are no interrupt enable control bits. The missing command/data bit in the MPU401 status means that the PC software is unable to tell whether the firmware tagged a byte as being part of the "command stream" or the "data stream". In the other direction, tagging still works, because the MPU/6850 mode toggle only affects how the PC/ISA side sees the communication port, but does not change how the OBP sees the communication port. The PC-side interrupt enable bits are fixed: The interrupt indicating an empty PC-to-firmware buffer is always disabled, while the interrupt indicating a filled firmware-to-PC buffer is always enabled. The datasheet stresses this point, because it means that the interrupt is stuck active while a data byte from the firmware to the PC software is pending to be read. On a system like the IBM PC/XT/AT with edged triggered interrupts, this means no further interrupts can be triggered on that line, on a system with level triggered interrupts (e.g. MCA), this would mean the host interrupt will be invoked in an inifinite loop if it does not read the data byte.

The ODIE architecture including the MPU-compatible mode is quite smart for the target application: The ODIE has a dedicated IRQ line associated only with the first communication port, allowing the first communication port including its IRQ to be handled by different software than the remaining SoundScape stuff which can use the second communication port and its own interrupt. For example, this might mean in Windows 3.1, a DOS program can interface the MPU401-compatible port, while at the same time the Windows driver can talk to the firmware to adjust mixer settings (especially on the S-1000 with the firmware-controlled LMC385 chip, but also on the SC600 with the firmware-controller TDA8421) or wave playback.

The mode (MPU401 vs. 6850) is controlled by the firmware, and because unread bytes can cause stuck IRQs in MPU401 mode, MPU401 mode is only recommended for application compatibility (on the first communication port), but warned agains on the second communication port. The Mockingbird-OTTO firmware actually implements two different mode settings, which can be switched using a firmware command.

In 6850 emulation mode, both communication ports (the primary one at 330/331, the secondary one at 332/333) are set up in 6850 emulation mode. This mode is not MPU401 compatible. The stream assignment is

• data stream on primary port: MIDI in/out at the game port.
• command stream on the primary port: not used (actually, MPU401 commands are processed there, but this is likely not intended usage)
• data stream on the secondary port: MIDI data for the internal synthesizer, responses to MIDI SysEx commands from the internal synthesizer.
• command stream on the secondary port: firmware control commands and their replies; wave playback status notification ("unsolicited replies")

On the other hand, in MPU401 mode, the primary port is switched to MPU401 emulation mode, allowing compatiblity with MT32/GM games. The stream assignment also changes:

• data stream on primary port: MIDI data. MIDI sent to the card is sent to the internal synthesizer and/or the game port depending on configuration. MIDI input is an uncoordinate mix of MIDI in data and SysEx replies from the internal synthesizer. This means that using SysEx commands to interrogate the synthesizer status does not work reliably if MIDI in on the game port is used at the same time. This typically is no issue in practice.
• command stream on the primary port: As discussed above, for data flowing from the firmware to the PC, there is no distinction between command and data stream bytes in MPU401 mode, so the command stream on the primary port can be seen as unidirectional stream. That stream is used for MPU401 commands.
• data stream on the secondary port: unused (actually, MIDI data written to it get forwarded to the external game port)
• command stream on the secondary port: firmware control commands and their replies; wave playback status notification ("unsolicited replies")

In summary, this means that 6850 mode provides easier control over the two MIDI devices (the internal synthsizer and the external MIDI at the game port), while MPU401 mode provides better application compatiblity. You can get full control over both MIDI out channels by configuring the MPU401 to "internal synth only" and using the data stream of the second port to address the external game port, even though I assume the possiblity to output data to the game port via the data stream of the second port in MPU401 mode is just an artifact because this is a desired feature in 6850 mode.

In MPU401 mode, the target MIDI port is selected by writing 00 to 03 to the MPU command port. Using the command port while in UART mode is not supported on a physical MPU401, these commands work on the Mockingbird-OTTO firmware even after "enter UART mode" has been sent. The low two bits are enable bits: Bit 0 if set enables playback using the internal synthesizer, while Bit 1 enables forwarding the MIDI data to the game port.

The first release (consider it more like a tech demo and proof that the project setup works) is ready, see

https://github.com/karcherm/mockbird/releases/tag/v0.1

You can use that tool to reconfigure which patches are used for a melodic program. Look at https://karcherm.github.io/mockbird/v0.1/ for some documentation what "patch" means in this context.