VOGONS


First post, by digger

User metadata
Rank Oldbie
Rank
Oldbie

Here's a question for dreamblaster.

I've been wondering... Could it be possible to combine the functionality of an OPL3LPT with that of a Disney Sound Source compatible DAC in a single device attached to one LPT port? And better still, allowing both FM and DAC playback at the same time through a single printer port?

Quite a few DOS games support the Disney Sound Source natively, or could be made to support it by replacing Miles/AIL or DIGPAK drivers.

The DSS has a 16-byte FIFO buffer that pulls status pin 10 high when the buffer is full. The Programmer's Guide to the Disney Sound Source makes it clear that the status of pin 10 should be checked before sending samples to the device. The Guide also describes how to piggyback on the system timer interrupt to play back audio on the device in the background in a non-blocking fashion.

Now I took a look at this example programming routine for the OPL3LPT and if I have understood it correctly, control pin 14 is always high whenever anything is written to the device. At https://www.serdashop.com/OPL3LPT, the following pinout is documented:


--- --- --- --- --- --- --- --- --- ---
OPL2LPT/OPL3LPT is wired up to the following pins
1: A0 -> /Strobe CTRL-0
2: D0 <-> Data0
3: D1 <-> Data1
4: D2 <-> Data2
5: D3 <-> Data3
6: D4 <-> Data4
7: D5 <-> Data5
8: D6 <-> Data6
9: D7 <-> Data7
14: /RD -> /Linefeed CTRL-1
16: /WR -> Init CTRL-2
17: A1 -> /Select CTRL-3 (only for opl3lpt)
--- --- --- --- --- --- --- --- --- ---

Pin 14 is marked "/RD", which I would interpret as it being reserved for read operations. However, the OPL2LPT and OPL3LPT in their current incarnations are output-only devices. Hence the lack of any method to autodetect the presence of such devices.

So if we want to design a hypothetical "DDS+OPL3LPT" device, could we repurpose pin 14 to override the signal of pin 10? So for instance, if we pull pin 14 low programmatically, the device will pull 10 high, making any DSS audio playback routines think that the FIFO buffer is full and wait until it's low again. In the meantime we can send commands to the OPL3 chip in the same (or in a very similar) way as with a regular OPL3LPT. Once we've sent out the byte to the proper register on the OPL3 chip, the device will switch the status of pin 10 from high to whatever the actual state of the FIFO buffer is.

The DDS programming guide does mention pin 17 being used as the on/off switch for the DSS, but in practice this would only mean that a game with DSS support would set it high once on start-up and set it back to low upon returning to DOS. That shouldn't conflict with what the OPL3LPT uses pin 17 for.

One potential issue might be the following part of the programming guide:

A good practice is to write the interrupt handler so that it always sends 8 samples without checking the status of the FIFO of the sound source, and it then sends up to 8 more while polling the status of the FIFO.

This could potentially form an issue in games that both originally support the DSS for digital audio output and have also been patched to play FM music through the OPL3LPT part of this proposed combined device at the same time, since bytes meant for the DSS could end up being processed by the OPL3LPT part of the device during those unchecked "bursts". As a workaround or solution for that, perhaps the input pins 11, 12, and 13, unused by both the original DSS and the existing version of the OPL3LPT, could be employed as a "counter" to indicate the number of bytes that have been sent to the DSS since the last time that pin 10 went from high to low. That way, the OPL3LPT driver routine could check the counter and wait for the counter to be past 8 (to be sure), before using pin 14 to block the DSS FIFO through pin 10 and send OPL3-specific data to the device.

Okay, this all may seem a bit complicated at first glance, but basically the trick is to implement both this combined device and its (OPL3-specific) drivers/patches in such a way that it retains out-of-the-box Disney Sound Source compatibility, while at the same time allowing DAC and FM to be played back simultaneously on DSS-supporting games that have been patched to output Adlib or OPL3 FM music through this device as well.

I believe this is possible, even though it would require some more logic in the device, as well as the drivers or patches for the FM-part of such a device to be a little more complex to enable simultaneous DAC and FM operation.

So TL;DR: a combined DAC/FM sound device on a single parallel port with out-of-the-box Disney Sound Source compatibility.

What do you think? Is this crazy? Or worth exploring?

It would be fun to at least try making a prototype of this. 😀

Reply 1 of 5, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie

The first question that crossed my mind was:
Has anyone ever tried to connect a Disney Sound Source and an OPL3LPT at the same time?
I'm asking because the Disney Sound Source obviously has a pass-through connector. Technically, it could work, because it does not use the strobe pin, at all, to improve printer compatibility.
The DSS uses the INIT signal on pin 16 as stobe, if I 'm not mistaken. So as long as the OPL3LPT ignores its WR signal on pin 16 unless there is a strobe, as well, the two should not interfere.

Reply 2 of 5, by digger

User metadata
Rank Oldbie
Rank
Oldbie
Benedikt wrote on 2020-08-05, 14:23:

The first question that crossed my mind was:
Has anyone ever tried to connect a Disney Sound Source and an OPL3LPT at the same time?
I'm asking because the Disney Sound Source obviously has a pass-through connector. Technically, it could work, because it does not use the strobe pin, at all, to improve printer compatibility.

At best, that would work if you only wanted to use the one or the other, and simply have them coexist on the same port. What I'm proposing is an additional mechanism that would allow them to be used simultaneously on a single LPT port, in games that already support both the Disney Sound Source and Adlib/OPLx FM music, with a simple patch or TSR.

The DSS uses the INIT signal on pin 16 as stobe, if I 'm not mistaken. So as long as the OPL3LPT ignores its WR signal on pin 16 unless there is a strobe, as well, the two should not interfere.

I checked the DSS programming guide again (see link to archive.org in my opening post), and it says the following about the control pins used:

  • Pin 10 will be high when the FIFO within the D/A chip is full. Thus when pin 10 is low, more samples can be sent to the D/A chip.
  • Pin 16 provides current to the collector resistor of a transistor inverter.
  • The rising edge of the pulse on Pin17 from the printer interface is used to clock data into the FIFO. Note from diagram 1 that the SELECT and -INIT inputs to the D/A chip are isolated from pin 17 by an RC time constant.

So if I understand correctly, pin 16 is only used to provide power for an inverter, which could be handled in a different way, since pin 16 is already used by the OPLxLPT, correct?

As for pin 17: In my opening post, I missed the part where pin 17 is used to clock the bytes on the data pins into the FIFO buffer. That could form a potential conflict with the OPLxLPT. But perhaps that could be worked around by having pin 14 (which I proposed as a "switch" between the OPL3LPT/FM part and the DSS/DAC part of the combined device) control whether pin 17 will affect the one part or the other.

Would that work?

Reply 3 of 5, by matze79

User metadata
Rank l33t
Rank
l33t

i would first check if its worth the work, how many Games will support LPT Disney Soundsource and Adlib at same Time ?
and how to fix concurrent writes/answers (FIFO full/empty etc..) without running into timing issues ?

This is already troublesome with many LPT Sound(Testing) Devices, as you write to TSR, TSR writes to LPT, Device responds ready, ready has wrong timing as TSR/Port Translation takes too much time (Tandy LPT..) so Software compatibility is further limited.

https://www.retrokits.de - blog, retro projects, hdd clicker, diy soundcards etc
https://www.retroianer.de - german retro computer board

Reply 4 of 5, by digger

User metadata
Rank Oldbie
Rank
Oldbie
matze79 wrote on 2020-08-06, 09:18:

i would first check if its worth the work, how many Games will support LPT Disney Soundsource and Adlib at same Time ?

Quite a few, I expect! I'm willing to state that most of the games that support the Disney Sound Source also support Adlib/FM for music, and many of them can be configured to select the DAC and the synth/music device separately.

Wolfenstein 3D comes to mind as an obvious example, but also a number of Sierra adventures that use later versions of the SCI engine. And then there is a long list of games that use the AIL 2 Miles Design drivers, or the DIGPAK/MIDPAK drivers from The Audio Solution.

and how to fix concurrent writes/answers (FIFO full/empty etc..) without running into timing issues ?

This is already troublesome with many LPT Sound(Testing) Devices, as you write to TSR, TSR writes to LPT, Device responds ready, ready has wrong timing as TSR/Port Translation takes too much time (Tandy LPT..) so Software compatibility is further limited.

Yeah, I'm not saying that it's guaranteed to be possible or successful. I'm just saying that it's worth testing and experimenting with.

My proposal basically comes down to the following question: Can the fact that Disney Sound Source support routines in games and drivers evaluate pin 10 before sending data (to check if the FIFO buffer is full or not) be used to arbitrate the sending of both DAC (DSS) and FM (OPLxLPT) to the same device?

Again, the one concern I have here is the 8 byte burst that the DSS programming guide recommends to always do first. Within such a burst, pin 10 isn't checked, so that part might prove problematic. Other than that, wouldn't this have the potential to work?

Reply 5 of 5, by NewtoM

User metadata
Rank Newbie
Rank
Newbie

I'd also be interested in a combined LPT sound card. I have a few older laptops lacking any sound output and for quite a few games it is an unpleasant decision whether to go with CVX4/DSS or with OPL3LPT.
So DSS+OPL3LPT would be a really good option.