georgel wrote on 2025-05-29, 10:19:

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 issue you are experiencing is likely related to the fact, that the ROM chip on the card only contains the raw sample data. The information about the layout of the sample ROM chip is part of the firmware. If none of the firmwares provided with SSINIT sounds correct, this is probably due to the sample ROM on your card being different from the sample ROMs supported by those firmwares. I'm afraid you likely won't get good MIDI sound from that card unless you manage to find the matching firmware, or possibly swap the sample ROM chip with a chip that contains the S-2000 samples.

I can desolder this ROM and put some socket and 2MB EPROM 27C160 if I fugure out the wiring of the MS address line. Here is the dump of the present ROM...I do miss , so far, the original soundscape 2000 ROM dumps, though.

possibly interesting question wrote:

Is the SONY codec involved in the MIDI sound output?

The SONY codec is not involved. While it does contain a D/A converter, the SoundScape architecture does not use the digital sound output of the ODIE, but the digital sound output of the OTTO music synthesizer chip to play back all kinds of sound, even the Sound Blaster emulation sound or the SoundScape "Wave A" and "Wave B" voices. The ODIE datasheet is not very informative on how to use the D/A output of the ODIE chip. In the block diagram, it says the A/D input is connected to one of the two internal DMA channels, and the D/A output to the other one. In the register level description, they talk about a "A/D record mode" for both channels. This might be a copy/paste error, and possibly it should read "D/A playback mode" for the internal DMA channel "B". Your SoundScape card contains the SONY codec just for PCM recording.

The S-2000 architecture does not contain the SONY codec at all, because PCM recording is handled by the AD1848 instead, so the ODIE chip is not involved at all. This also means that firmware for the S-2000 or later cards do not contain code to interface with the SONY codec chip to allow PCM recording through the ODIE chip.

Sorry, I came to a conclusion the SONY IC is rather not involved and edited my message accordingly prior your reply. Now the dilemma is whether to spoil the appearance of this vintage card and solder a socketed EPROM on it and whether I will be able to find SS2000 ROM dumps to try with. Is it worth it, is the MIDI good, because if it is like on PCI 1370 ensoniq card under DOS it is not worth it? On the other hand here it is mentioned that the VIVO ROM is the same as OPUS, so technically I may have one ROM to try with.

https://www.os2museum.com/wp/dumping-ensoniq- … oundscape-roms/

That guy made quite decent soundscape ROM dumper.

georgel wrote on 2025-05-29, 12:01:

I can desolder this ROM and put some socket and 2MB EPROM 27C160 if I fugure out the wiring of the MS address line. Here is the dump of the present ROM...I do miss , so far, the original soundscape 2000 ROM dumps, though.

There is an overview on SoundScape ROMs in this thread: Difference between Ensoniq Soundscape ROMs? - but that thread does not include the 1350901501 chip of your card. It seems we can split the number like 135-09-015-01, and the first ROM mentioned in that thread is 135-09-016-01 and then a lot of ROMs of the 135-10 family. That thread also lists the CRC32 of the "original soundscape 2000 ROM" you are looking for, it is 9FDC4825. The thread about SSDUMP has a comment mentioning a filename for the S-2000 ROM cump. Files of that name can be found on the Internet Archive. Google found the link for me. I downloaded the first hit and can confirm the CRC matches.

Interestingly, http://www.yjfy.com/museum/sound/Ensoniq.htm has a picture of your card, but with the 016 ROM instead of the 015 ROM. So it seems that card existed with the same sample set as used by the S-2000 as well. Too bad that page has no further information on the card, like a link to a driver.

mkarcher wrote on 2025-05-29, 15:48:

Interestingly, http://www.yjfy.com/museum/sound/Ensoniq.htm has a picture of your card, but with the 016 ROM instead of the 015 ROM. So it seems that card existed with the same sample set as used by the S-2000 as well. Too bad that page has no further information on the card, like a link to a driver.

What's more interesting a couple of cards above on that page have the same ROM 1.00, and I remember for one of them xxxx1000 I already downloaded drivers, should try that firmware.
EDIT:Unfortunately they have 2M versions of that ROM 1.00
ADDED: It looks the PCB is wired for a 2M ROM/EPROM already (in 8-bit mode), but now I am thinking that the RAM chip HM511664 may not be up to the RAM of the original SS2000, and that may be another reason for a firmware inompatibility? Not to mention that RAM/ROM on the specific card is configured in the registers of the ODDIE, and I guess this is done from the PC side prior uploading of the 68K firmware?

georgel wrote on 2025-05-29, 16:42:

What's more interesting a couple of cards above on that page have the same ROM 1.00

Don't look at the version number, look at the model number! Your ROM is version 1.00 of the 135-09-015-01 ROM. The V7 media-fx, the Reveal SC600 and the "nameless" cards use version 1.00 of the 135-09-016-01 ROM. It seems Ensoniq switched to Macronix-manufactured ROMs with the 135-10-XXX-01 series, and they don't have a version marking anymore.

georgel wrote on 2025-05-29, 16:42:

ADDED: It looks the PCB is wired for a 2M ROM/EPROM already (in 8-bit mode), but now I am thinking that the RAM chip HM511664 may not be up to the RAM of the original SS2000

The original S-2000 has 4 chips of 4*64K. Your card has one chip of 16*64K. Both is 128KB with 16 bit bus access, the RAM should behave the same.

georgel wrote on 2025-05-29, 16:42:

Not to mention that RAM/ROM on the specific card is configured in the registers of the ODDIE, and I guess this is done from the PC side prior uploading of the 68K firmware?

That's true. SSINIT sets up a 2Mword ROM. If you have a 1M ROM that ignores the top address bit, you just get the contents twice. The SoundScape cards use an 8-bit floating point format, which is close to µLaw, so the ROM only needs to provide 8 bits per address. That's why it is wired in byte-wide mode even though the OTTO / Motorola 68K design uses 16 bit data width.

The original ROM desoldered; in programmer reads the same as from dumper. The EPROM is programmed; now I am deciding what type of DIL42 600 mil socket to synthesize. By the way all that time I did not pay attention to the way the detecting FW is deciding about which version of hardware it is running on -- is it checking some ROM bytes for that?

EDIT:Yes, it is checking ROM bytes. Now the firmare stub reports hardware version 0. The 2M EPROM installed successfully, dumps successfully via the dumper, and MIDI synthesizer now works well. I guess now I have Soundscape 2000 equivalent for MIDI. If someone wants me to check other soundscape ROM dumps, my configuration is convenient, just provide the dump you want to be tested. Thanks mkarcher.

georgel wrote on 2025-05-29, 22:02:

EDIT:Yes, it is checking ROM bytes. Now the firmare stub reports hardware version 0. The 2M EPROM installed successfully, dumps successfully via the dumper, and MIDI synthesizer now works well. I guess now I have Soundscape 2000 equivalent for MIDI. If someone wants me to check other soundscape ROM dumps, my configuration is convenient, just provide the dump you want to be tested. Thanks mkarcher.

Oops, I didn't see your edit, as it didn't show up as "new post", so I disassembled that ROM myself, too. To make the algorithm of the hardware detection ROM public: It works like this:

• Send FF to host, to confirm successful start of firmware code
• Write a byte to address 0x800 (2K) in firmware RAM space. That address will have address bit 11 set. When SSINIT uploaded the firmware, the ODIE chip was configured to "firmware RAM is DRAM", and bit 11 will always end up as row address bit. If the firmware RAM is SRAM instead, the row address is ignored by the SRAM (as it does not connect /RAS), so the write ends up in byte 0 instead.
• If byte 0 is affected by that write, the card uses SRAM as firmware RAM. SSINIT needs to reconfigure the memory controller before firmware images bigger than 256 bytes work (in case of 64KWord firmware RAM). In case of 4M firmware RAM, images up to 2K would work. That's why the stub firmware needs to be less than 256 bytes - that's the maximum size that works with any kind of mixed up memory configuration. If the firmware memory is found to be SRAM, set bit 4 in the output (0x10).
• Probe whether "memory bank 2" yields writeable memory. AFAIK no PC SoundScape cards have anything connected to "memory bank 2". "memory bank 0" is firmware RAM, "memory bank 1" is the sample ROM. If "memory bank 2" is writeable, set bit 5 in the output.
• Look at byte 0x24 in memory bank 1. As the sample ROM is mapped as 8 bit device, this is location 0x12 in the ROM image. All the odd bytes in sample ROM space are undefined. Here you get a lookup table: If that byte is oxFD, request firmware type 0; if that byte is 0x0F, request firmware type 1; if that byte is 0x19, request firmware type 2. If the sample ROM has not yet been identified, and that byte is nonzero, return unknown sample ROM by requesting firmware type 15.
• If byte 0x12 in the sample ROM (i.e. 0x24 as seen by the 68000 processor) is zero, this is a later card (probably one that no longer has the SDGI-type header). In that case, an advanced feature of the ODIE-like chip is tested: Some advanced chip (no idea whether OPUS or VIVO) has an extensino that responds to address beyong the the 0xA00000..0xA0001F range from the ODIE datasheet, and it allows a word write to 0xA00026 to be handled in a way that the more significant byte ends up in 0xA00006. If that feature is supported, request firmware type 4. If that mapping does not happen (no idea whether you get the low byte written to the "upper range"), request firmware type 3.
• Send FE to host, to confirm success of the hardware detection
• Send the output byte (requested firmware in bits 0..3, SRAM indicator in bit 4, extra sample RAM indicator in bit 5
• Start an endless loop.

The original stub code on georgels card would have reported "unknown firmware required, DRAM for firmware memory, no sample RAM", as the 1350901501 ROM has the unhandled value 3C in the location used to identify the sample ROM variant.

It seems the sample ROMs have some tables in the end that are not MIDI wave samples. If that data is sufficient to generate the instrument mapping in the firmware, a patched SNDSCAPE.CO0 for the old 1M sample ROM could be prepared.

EDIT notification: I rewrote the paragraph about the detecteion of the ODIE extended register.

The attached file is version of SSINIT 5.06 that allows cards with no "waveport" hardware to work. Probably similar should be done for windows drivers. The sound blaster emulation is very bad. It would be interesting to try another ROM bound to newer and probably better firmware. The XU4 unpopulated position next to the 34-pin header is a place for a DRAM chip in the corresponding package for RAM extension. I haven't traced the 34-pin header, so far, could be some debugging port for this 68K sytstem.

georgel wrote on 2025-05-30, 20:32:

The attached file is version of SSINIT 5.06 that allows cards with no "waveport" hardware to work. Probably similar should be done for windows drivers. The sound blaster emulation is very bad. It would be interesting to try another ROM bound to newer and probably better firmware. The XU4 unpopulated position next to the 34-pin header is a place for a DRAM chip in the corresponding package for RAM extension. I haven't traced the 34-pin header, so far, could be some debugging port for this 68K sytstem.

My guess is that the 34-pin header might be a Sony CD-ROM interface. ODIE supported decoding CD-ROM I/O ports from the start, so it would make sense to see this feature used on the "basic SoundScape implementation". XU4 is 40 pin ZIP, so it's for a 256K * 16 RAM chip. I'd guess that one will appear in "bank 2" and is meant for user-defined instruments. Now you just need a firmware that supports user-defined instruments. This makes me think I should continue looking into the old firmware/ssinit found here: https://vogonsdrivers.com/getfile.php?fileid= … 968&menustate=0 . These drivers are likely similar to the original drivers included with the MediaFX card. A friend had a MediaFX, and the original drivers it shipped with provided three wave voices in Windows, two of them via the ODIE chip, and the third one by the AD1848. The AD1848 is interfaced by AAPIPKB2.DRV, while the ODIE is interfaced by TAPIPKB1.DRV. TAPIPKB1.DRV also contains the configuration dialog, and cares about the WavePort, so it likely won't work on your card, even though most of the AD1848 stuff is in the other driver. Interestingly, the Windows configuration dialog shows an amount of "free sample RAM". Without extra RAM, that one is ridiculously low, but that driver set might actually support the extra 512KB that could be installed on your card...

If I remember correctly, the Reveal drivers didn't work out of the box with the MediaFX card I tried it on.

Can this "waveport" be "added" with another plugged ISA soundcard based on AD1848?

georgel wrote on 2025-05-31, 01:11:

Can this "waveport" be "added" with another plugged ISA soundcard based on AD1848?

This is likely not going to work with an unmodified SoundScape driver, because the SoundScape driver initializes the ODIE chip to drive the DMA and IRQ lines associated with the WavePort, so you can't have the other sound card drive the lines that are expected by the sound driver.