That is such a nice find! That is in my opinion completely rescueable. You can try some white vinegar and let it act for a few minutes. Rinse it with distilled water and clean again with IPA after the rinse. Applying some Deoxit would be nice too, and once you get rid of rust and oxidation might be a good idea to apply some flux and reflow the solder. It is best to remove those affected components so you do need to go into a few (as gentle as possible) reflowing cycles that involve applying flux and cleaning with IPA as well. When you have the affected components out it is a matter of checking traces and continuity.

You might need to fix traces. Hopefully you'll still have pads. Would be sad to see an Elite die out.

It is definitely possible to get it up and running again but it will not likely be pretty since the copper is likely to be unsolderable without some effort and that may lead to some creative solutions to get the needed connectivities. These cards suffer from bad capacitors so they should all be replaced too while the fixing is underway.

This reminds me... I have an Ensoniq Soundscape S2000 and a Yamaha SW60XG with these kind of caps... Mouser electronics to the rescue...

carlostex wrote on 2025-05-08, 13:42:

This reminds me... I have an Ensoniq Soundscape S2000 and a Yamaha SW60XG with these kind of caps... Mouser electronics to the rescue...

Sweet, I appreciate your help and kind words! Corrosion repair is all too familiar-- Sadly had to deal with a few Mac classics over the years as well as a Korg Poly61. The SMT components I highlighted are too corroded and their values are unreadable... nor is there a schematic or service notes for this card. If there's any way you might be able to check those values on your S2000 that would be so so so cool 😀

there is such a card
C99 labeled as A5
C90 labeled A2
R47 labeled 752 (7.5kOhm)
can't find c109 (where?)
unfortunately I can't check the capacity of the capacitors C90 and C99, but they all have the same marking, A2 and A5. You can unsolder them and measure them. They may all be the same.

In addition to the obvious corrosion, I recommend checking the ICs for loose pins. I've had a couple Soundscapes come my way with loose pins on the main IC.

What a monster card. Absolutely repairable, full recap is a good idea.

Jccwu wrote on 2025-05-10, 17:47:

unfortunately I can't check the capacity of the capacitors C90 and C99, but they all have the same marking, A2 and A5. You can unsolder them and measure them. They may all be the same.

According to this, the marking code A2 is 1nF (1000pF) and A5 is 0.1uF. Someone can desolder them and verify. C79 should be the same as C90 (same circuit, just on the other audio channel). C90 is probably an NP0/C0G type.

DundyTheCroc wrote on 2025-05-13, 07:56:

repairable, full recap is a good idea.

Full "recap" is alays a bad idea of those who can't make slightest electronics diagnosis on a circuit.

Anybody familiar with this card? I tried Ensoniq DOS drivers but with or without any sound card they always claim to initialize the card's hardware ... No sign of any hardware detection.

georgel wrote on 2025-05-23, 08:51:

Anybody familiar with this card? I tried Ensoniq DOS drivers but with or without any sound card they always claim to initialize the card's hardware ... No sign of any hardware detection.

Not that card specifically, no. It doesn't seem to be an Ensoniq-branded card, in spite of using their ICs. At best, maybe a licenced design, or just one where they purchased the chips. The FCC grantee code points to a Taiwanese company. Most actual Ensoniq-branded cards had FCC ID numbers beginning with LF7, and contained an AD1848-compatible CODEC on-board.

They share some parts: Ensoniq instrument ROM, small amount of RAM, OTTO, 68K processor, ES5706 host interface, so maybe you can expect some level of compatibility, but I wouldn't absolutely bet on it. Whether the standard code files have the data to match that particular 1 MiB sample ROM is not entirely clear.

There may be different versions, but the most common Ensoniq DOS-based tools definitely do try to detect the hardware before starting the initialisation routines. I just tested this with no Ensoniq hardware present, and it complains that the hardware was not found, and never displays the init message. In most cases, for non-PnP cards, the tools will probe the card at the base/MIDI port specified in SNDSCAPE.INI (on-board base port jumper must match). It isn't clear how JP1 is set from the photo, so it might help to double-check. Also, make sure there is nothing else at that port, once you sort out the jumper settings. Usually, I think code upload to the 68K happens via the DMA channel specified in the config file, too.

georgel wrote on 2025-05-23, 08:51:

DundyTheCroc wrote on 2025-05-13, 07:56:

repairable, full recap is a good idea.

Full "recap" is alays a bad idea of those who can't make slightest electronics diagnosis on a circuit.

Agreed. Unless it's hardware with known bad caps (e.g. cap plague era), doing a full recap of capacitors that might be perfectly fine isn't worth it and can do more harm than good.

georgel wrote on 2025-05-23, 08:51:

Anybody familiar with this card? I tried Ensoniq DOS drivers but with or without any sound card they always claim to initialize the card's hardware ... No sign of any hardware detection.

That's an interesting card. It's clearly not an SoundScape S-2000 like card, as the AD1848 for WSS compatible 16-bit stereo sound is part of the S-2000 design. There was an earlier SoundScape S-1000 design though that pushed 16-bit stereo sound through the Ensoniq bus interface chip, though, and this card might be a SoundScape S-1000 clone. I don't expect it to be an original SoundScape S-1000 copy, though, as this card uses a single 1MBit 64K * 16 RAM chip, whereas the later SoundScape 2000 uses 4 256kBit 64K * 4 RAM chips. If 64K*16 chips would have been available for the S-1000, why would SoundScape go back to 64K*4 chips on the S-2000?

I only know about the S-1000 from some Ensoniq datasheets, I don't know of any hardware produced, let alone production in volume. Possibly this is some vendor trying to realize the S-1000 design later on at a lower price point than the S-2000.

Thanks for your opinion. Are there any DOS drivers that don't rely on windows presence/installation?

georgel wrote on 2025-05-25, 15:53:

Thanks for your opinion. Are there any DOS drivers that don't rely on windows presence/installation?

I'm sorry, I don't know of drivers for the original SoundScape implementation.

I got the specification for it from the ODIE datasheet (actually, "ODIE" is the code name of the ES5706 sound card controller chips). https://www.dosdays.co.uk/media/ensoniq/es570 … %20-%20ODIE.pdf describes the Soundscape implementation in general, and the purpose and interface of the ODIE chip specifically. Note how the Soundscape description in the ODIE datasheet specifically mentions the Sony CXD2555Q Codec on PDF page 14, as well as the NS LMC835 equalizer chip and a NE5532 operational amplifier, all of which can be found on your card, which makes me believe even more that this card is a straightforward implementation of the "original SoundScape", but on the other hand, I found no confirmation for the "S-1000" name. There is a reference in the Linux ALSA soundscape driver using the name S-1000 for the PCB variant used by Spea for their "Media FX" rebrand of the S-2000, but I wouldn't trust that comment as source for the claim that the MediaFX actually is a "Soundscape S-1000".

From the ODIE datasheet I learned the original design was with 6 i/o ports, the first two of which are for MIDI emulation. From the soundscape 2000 windows drivers I learned they were using for "WavePort" 4 consecutive i/o addresses at different locations (534h, etc..). I decided that was a matter of address remapping only. I patched the DOS SSINIT.EXE V5.06 (compiled with Borland C 3.1) to accept 330h and 332h base addresses (the table of allowed i/o base addresses is in the executable stored in plain format). Since my card has two i/o address selection jumpers as per datasheet I decided to try iwith base address jumper setting at 330h. Unfortunately in this case (330h/332h) the SSINIT complains "error: Soundscape board-type not recognized". The original drivers for the card I have seem to be lost decades ago, and are not available on the internet, that's why I applied this dirty experiment.
I also tried SPEA V7 Meadia FX drivers for both their PCB layouts, their cards also use soundscape i/o ports at bases 534h, 608h, etc..

georgel wrote on 2025-05-28, 13:00:

From the ODIE datasheet I learned the original design was with 6 i/o ports, the first two of which are for MIDI emulation. From the soundscape 2000 windows drivers I learned they were using for "WavePort" 4 consecutive i/o addresses at different locations (534h, etc..).

This is mixing up the two quite distinct parts of the SoundScape S-2000. The primary interface to the ODIE is (given the default base of 330) port 330/331 for MIDI emulation, 332/333 for non-MIDI communication with the firmware running on the 68K processor, and 334/335 to control the ODIE operation itself. This is true both for the original design and the SoundScape S-2000 design. The ODIE then can be configured to also respond to 220'ish for SB emulation, as well as 388 for Adlib emulation. Nothing of this is related to the "WavePort".

On the other hand, the WavePort of the SoundScape 2000 is directly interfacing with the AD1848 codec chip, completely unrelated to the ODIE. I also remember I read something about an S-2000-like card that did not use a PAL to decode the WavePort, but used the CD-ROM interface decoder of the ODIE chip instead, so the WavePort assigned to the AD1848 is at 338 instead of 534. 534 is used because that port is also the default port of the Microsoft Windows Sound System implementation.

georgel wrote on 2025-05-28, 13:00:

I patched the DOS SSINIT.EXE V5.06 (compiled with Borland C 3.1) to accept 330h and 332h base addresses

SSINIT already uses port 330 and up to initialize the SoundScape S-2000 and later type boards, no need to patch anything for an ODIE at 330. The S-2000 photo at https://en.wikipedia.org/wiki/Ensoniq_Soundscape_S-2000 shows the jumper JP2 to chose the ODIE base address, and JP3 to chose the WavePort. Your small ODIE-based card offers the same port choices as the S-2000 ODIE base addresses. Your card entirely misses the "WavePort" part, though.

Thanks. Then the SSINIT should be patched to like the "small" card and ignore the WavePort absence. I am still unaware how SSINIT differentiates beteen different genuine soundscape models.

georgel wrote on 2025-05-28, 19:27:

Thanks. Then the SSINIT should be patched to like the "small" card and ignore the WavePort absence. I am still unaware how SSINIT differentiates beteen different genuine soundscape models.

I happen to have a disassembled SSINIT 5.06 at hand. It has the card detection function at 0562:0078 (relative address). It seems to work like this (assuming an ODIE base of 330):

• If any of the bits 3..6 of port 332 are set, there is no ODIE. The ODIE datasheet says that the host/firmware communication port powers up in MC6850-type mode, and the firmware is able to switch it into MPU401-type mode (although it is not recommended). As long as no firmware is uploaded, the port is clearly in MC6850-type mode. For that mode, the ODIE datasheet specifies that these bits are "always 0".
• If bit 7 in port 334 is set, there is no SoundScape.
• The ODIE, the data sheet specifies that bits 4..7 are clear. If this is the case, SSINIT assumes a "classic S-2000". This card class includes the Elite.
• If bit 6 in port 334 is set, the card is a non-PnP advanced card with an AD1845-compatible codec. (OPUS?)
• If bit 5 in port 334 is set, the card is a Plug-and-Play card with an AD1845-compatible codec. (VIVO 90?)
• The AD1845 codec on newer SoundScapes is not mapped to the standard WSS base addresses, but decoded by the "CD interface" of the bus interface chip (obviously no longer the ODIE). This is set up at 0562:014C, setting up the CD address decoder to base+8..base+F. The AD1845 thus appears at 338 if the base address is 330.
• This is where SSINIT is supposed to fail on your card: The ODIE is told to release the 68K from reset (seems pointless, as no firmware is uploaded yet), but this obviously also releases the AD1848/AD1845 from reset (offset 1B9..1D8), and the code then proceeds to wait for 1 second for the 1848 to become ready. This is indicated by bit 7 of at the WavePort becoming zero. The wait loop is 1D8..208, and a final readyness test directly after that, followed by a test for WavePort+2 not reading FFh.
• After the WavePort validation, the 68K processor is sent back into reset mode (234..250), which is expected to also send the wave codec into reset, which would be indicated by bit 7 of the WavePort becoming 1 again. Interestingly, this only works on the Spea MediaFX variant of the card (which connects the AD1848 reset to the 68K reset), but not on the original Ensoniq card. So if the AD1848 (or 1845) keeps being ready, the card is assumed to be an Ensoniq-Type card (non-PnP cards allow IRQs 2,5,7,10), but if the AD1848 gets non-ready in response to the reset, the card is assumed to be a Spea-type card (allows IRQs 2,7,5,15).
• Finally, the card is taken out of reset again (27D..29C), and a final wait (with timeout) for the AD1848 to become ready again is performed.

So for your card without a codec, you might want to patch 0562:0145 to be a jump 02C9, skipping over all the WavePort shenanigans. I don't see any loops waiting for the Codec outside of the card detection procedure outlined above, so this procedure might actually make SSINIT work on that card. Don't expect the mixer settings to work, though. The mixing on the S-2000 and later cards is performed inside the AD1848. Furthermore, don't expect the equalizer to receive valid initialization from SSINIT. If it is initialized from firmware (quite likely), you would need a matching firmware that contains equalizer support, which is likely not shipped with SSINIT for S-2000 and later cards.

Speaking about firmware... SSINIT is shipped with different firmware variants. The detection of the required firmware is not performed on the host, but by uploading a detection firmware, "SCOPE.COD" first, which is supposed to send a small integer number as byte through the firmware/host communication port. That byte is the number of the SNDSCAPE.COx file to upload. This mechanic is implemented starting at 0562:16E2. The firmware type is encoded in the low 3 bits of the returned value; the bit with value 08 needs to be cleared, otherwise the error "Soundscape board-type not recognized" is emitted. The bit with value 10 indicates whether the ODIE chip should be configured to DRAM (clear) or SRAM (set) for the working memory of the 68K processor.

Yes. The card is initialized with this but MIDI sounds way too off. Each firmware sounds differently except that FW 3 blocks the computer until reset. The crystal next to sequoia chip is 32MHz like on the original SS-2000.