Beegle wrote:

James-F wrote:

It would be great to have a TSR for the Covox to emulate a Sound Blaster so any game can be heard.

I believe there exist one already, Virtual SoundBlaster if I recall.

Yes, VSB, but it only emulates the SB 1.0 DAC, and nothing else. It also uses a lot of memory, and insists on running only in real mode (there's supposed to be a version that runs with QEMM but it doesn't work).

Scali wrote:

Yes, from the same guy who also did TEMU (which emulates Tandy audio over LPT DAC, or PC speaker): http://web.archive.org/web/200805140428 ... dldos.html
It does not emulate FM though, or so it says.

keropi wrote:

Tried to make some recordings with my Disney Sound Source but I totally forgot it does not work with covox/lptdac stuff... anyone knows a game (preferably) that supports both options so a comparison can be made?

TEMU works better for its purpose than VSB... it will also emulate a Disney Sound Source on the LPT DAC or PC speaker which is useful for games like Wolf3D.
And yes, no FM emulation on either of those.

It would be nice to have a TSR that emulates a SB 2.0 with OPL2 on LPT DAC or PC speaker. Can someone whip that up real quick? 🤣

gdjacobs wrote:

Exactly. You want to preserve the data and none of the analog noise. I would probably favor optocouplers as logic gates aren't generally intended for isolation purposes.

I don't think you understood the true purpose of my suggestion of the logic gates then.
The isolation would be a bit of a side-effect. You can still place optocouplers behind them.
But as I said, they should latch whenever a new value is on the datalines, and retain that value until a new one is sent, by looking at the strobe-line.
Because, since the datalines were never intended to have a 'constant' output, I'm not sure what happens during the transition from one value to the next. The datalines might have random output for a while (or output a logical 0 until the next value is ready).
Perhaps that differs from one printer port implementation to the next. It would be interesting to put the signals on a scope, for various computers. Especially very slow ones, like an IBM 5150/5160.

If you wanna go all the way, why not start here? http://cd.textfiles.com/thegreatunsorted/text … sc/pcstereo.gif
Has a latch + proper DAC + output amplifier (shouldn't be too hard to cut the circuit down to mono). The amplifier circuit isn't very good tho.

EDIT: I actually have a schematic/PCB layout for the stereo variant ready (with the original amplifier - ready because I never had them produced) - in case anyone wants to start from there, be my guest.
Preview here: http://i.imgur.com/gRyakfV.png

shock__ wrote:

If you wanna go all the way, why not start here? http://cd.textfiles.com/thegreatunsorted/text … sc/pcstereo.gif
Has a latch + proper DAC + output amplifier (shouldn't be too hard to cut the circuit down to mono).

Ah, interesting. For me, the latch was merely a theory I had. I didn't know if it was actually necessary (as I say, we'd have to measure with a scope, and perhaps it differs from one implementation to the next). But the fact that this circuit also includes latches seems to imply that perhaps I was onto something there.
It seems to use the 'busy' signal rather than the 'strobe' signal though. Not sure if that's correct. I thought the 'busy' was the signal from the printer that it received the strobe and is taking the data off the bus.
I really wonder if the real Covox has anything like that.
The Disney Sound Source does, by default, because it uses a FIFO buffer.

The mere reason for that latch in above schematic is for the stereo-on-1 implementation to select the active channel since the DACs don't have flow control (it offers stereo at the cost of double/half the sample rate). There's also a 1-chip implementation (I think the schematic is at the end of the Crystal Dream 2 readme)

For future reference: DSS schematic (using off the shelf parts without the actual covox output stage) - http://i.imgur.com/Ss9CHJd.png

Scali wrote:

Ah, interesting. For me, the latch was merely a theory I had. I didn't know if it was actually necessary (as I say, we'd have to measure with a scope, and perhaps it differs from one implementation to the next). But the fact that this circuit also includes latches seems to imply that perhaps I was onto something there.

The latch is only necessary because this is "stereo-on-1", so you can store a sample into left or right latch separately with LPT control pins #1 and #14. Sometimes DACs include a latch but DAC0808 don't.

A latch is not needed on a plain old regular "Covox", because the LPT port data pins are already latched. Therefore if you do have two LPT ports, it's easier to have two Covoxes for stereo output.

But you are onto something here. I have toyed with the idea of buffering the LPT data pins with a CMOS buffer powered from a clean 5V supply, so I could get symmetrically driven noise free signals into a precision resistor ladder (designed for DAC usage), even if the original LPT was 5V TTL or 3.3V CMOS like on newer motherboards. Further improvement would be to buffer the ladder output voltage with an opamp, or even better to convert the ladder current into voltage for output. But as always, simply using a proper DAC instead of resistor ladder might be better anyway so buffer is not needed. But the fact is that 8-bit audio with some timing jitter is not that great anyway, so the random 1% resistors are just as good.

Jepael wrote:

A latch is not needed on a plain old regular "Covox", because the LPT port data pins are already latched. Therefore if you do have two LPT ports, it's easier to have two Covoxes for stereo output.

Yes, but are they latched in a way that we want for a Covox? I mean, the use-case for LPT is to only latch the data pins as long as it takes for the data to transfer.
But for a Covox, we are not actually transferring data. We are feeding the data signals directly into a DAC.
So I have this 'region of uncertainty'...
What happens when you send a new command to the LPT? Will it retain the latched values up to the moment that the new data is latched (the behaviour we want)? Or will it drop the current values immediately, and how long will it take for the new data to arrive? There could be minuscule glitching involved here.

Jepael wrote:

But as always, simply using a proper DAC instead of resistor ladder might be better anyway so buffer is not needed.

Yes, I suppose a DAC IC would already have some kind of latch/buffer internally, and also 'cleans up' the signal? Because it is safe to assume that it sees its input strictly as 'data', and not as an audio-quality conditioned 'analog' signal?
It might also take care of the 'transition' mentioned above, because it may only read a new byte from the input based on some kind of clock or other signal. So 'invalid' input while there is no signal for 'new data' would get ignored.

Jepael wrote:

But the fact is that 8-bit audio with some timing jitter is not that great anyway, so the random 1% resistors are just as good.

Yup, so a FIFO-based solution like the Disney Sound Source would be even more interesting. You remove the timing jitter from the input that way.
I wonder if there's a way to make it compatible with Covox. DSS was fixed at 7 kHz... Covox can be any sample rate. I guess it would be difficult to sample the strobe signal to get an approximate sampling rate. I mean, doing that is one part of the job (you can average it over a given period of time). But then you'd have to be able to generate a reliable clock signal at arbitrary speed. I think that may be the real problem.
Perhaps with a PIT-like circuit? From a clock of 1.19 MHz you can divide reasonably accurately to a wide range of clockspeeds, good enough for sample playback anyway.
Yea, that might actually work... You'd need to have a circuit that counts and averages strobe pulses at the input, and that 'smoothed out' count has to be translated to a counter value and fed to the PIT, which generates pulses for when to output a new byte to the DAC.
I don't know how difficult that would be in discrete logic, but being a software-guy, I can see this working with two microcontrollers (you could do it with one, but then you'd need to handle two interrupts: one for the strobes, and one for the PIT interrupts... that would probably cause jitter as well in some cases... although, the rates will never be far apart, so if you get the interrupts to fire in discrete time windows far enough apart, and the microcontroller is fast enough, it may just work... except for extreme cases where the samplerate changes... but that is generally only during init/deinit, and is acceptable).
Overkill probably 😀

Also: some more reverse engineering stuff I did for the DSS - http://i.imgur.com/sMTdFhD.jpg (in German but I guess you could figure out most by guessing).
The DSS programmer's guide actually has a simplified flowchart which shows the basic functions (which was the base I used for my compatible schematic).

Scali wrote:

Yes, but are they latched in a way that we want for a Covox? I mean, the use-case for LPT is to only latch the data pins as long […]
Show full quote

Yes, but are they latched in a way that we want for a Covox? I mean, the use-case for LPT is to only latch the data pins as long as it takes for the data to transfer.
But for a Covox, we are not actually transferring data. We are feeding the data signals directly into a DAC.
So I have this 'region of uncertainty'...
What happens when you send a new command to the LPT? Will it retain the latched values up to the moment that the new data is latched (the behaviour we want)? Or will it drop the current values immediately, and how long will it take for the new data to arrive? There could be minuscule glitching involved here.

The IBM PC came with a LPT port built with discrete logic chips. Writing to data port will trigger the 74LS374 latch on rising edge of port-decoded write signal (at the end of the write cycle), so bogus data is never loaded into the latch (it's edge triggered, not level triggered). But as these are real world chips, it will take some time for the data at the output to settle to its new value, and each data bit has its own settling time within a given tolerance. The time for the signal to rise high can be different from the time it takes the signal to fall low, but after about 30 ns all the outputs have settled to the latched value, depending on chip manufacturers specifications and what kind of load you have on the data pins. So yes, there could be 30ns glitching as each data output settles to new value at their own pace every time you write a different value than previous value was. The reciprocal of 30ns is 33MHz, so this minuscule glitch is easily filtered by just the low pass filter after the DAC, or just a few tens of picofarads deglitching capacitor.

So for a simple mono Covox DAC, there is no need for external latching. And buffering will also cause individual delays to each data bit, but this rippling also should not take more than 30ns.

Scali wrote:

Yes, I suppose a DAC IC would already have some kind of latch/buffer internally, and also 'cleans up' the signal? Because it is safe to assume that it sees its input strictly as 'data', and not as an audio-quality conditioned 'analog' signal?
It might also take care of the 'transition' mentioned above, because it may only read a new byte from the input based on some kind of clock or other signal. So 'invalid' input while there is no signal for 'new data' would get ignored.

Not all DACs have latches or buffers internally, and even the ones that do still has the same issue, each data bit latched in takes some finite amount of time to settle. So to alleviate the issue, what people usually do is that they have an analog sample/hold after the DAC, and during DAC updating the output is fed from the hold citcuitry and DAC can glitch as much as it wants and after the DAC output has settled, it is sampled to the output again. So this is another way to make stereo-on-1, not with two DACs with latches, but one DAC demuxed to left and right channels with the same control signals.

Scali wrote:

Yup, so a FIFO-based solution like the Disney Sound Source would be even more interesting. You remove the timing jitter from the input that way.
I wonder if there's a way to make it compatible with Covox. DSS was fixed at 7 kHz... Covox can be any sample rate. I guess it would be difficult to sample the strobe signal to get an approximate sampling rate. I mean, doing that is one part of the job (you can average it over a given period of time). But then you'd have to be able to generate a reliable clock signal at arbitrary speed. I think that may be the real problem.

Yes but you can't detect the rate at which samples are fed to the LPT data port. The strobe signal is just another GPIO pin like data pins are, it can't be used for this. There is no way to detect externally when LPT data port has been written, except the fact that data pins change. You only have the information if you build your own ISA card of course,

Jepael wrote:

So for a simple mono Covox DAC, there is no need for external latching. And buffering will also cause individual delays to each data bit, but this rippling also should not take more than 30ns.

That's good to know. That was my point exactly: we have to analyze the signal going out, and then we get an idea of how much glitching is there.
If it is indeed no more than 30 ns, then it's not a practical issue.

Jepael wrote:

Not all DACs have latches or buffers internally, and even the ones that do still has the same issue, each data bit latched in takes some finite amount of time to settle. So to alleviate the issue, what people usually do is that they have an analog sample/hold after the DAC, and during DAC updating the output is fed from the hold citcuitry and DAC can glitch as much as it wants and after the DAC output has settled, it is sampled to the output again.

Is this not built into some DACs then?

Jepael wrote:

So this is another way to make stereo-on-1, not with two DACs with latches, but one DAC demuxed to left and right channels with the same control signals.

I believe this is how stereo is done on the SB Pro?
The problem with the SB Pro is that it has really poor channel separation, there's a lot of crosstalk.

Jepael wrote:

Yes but you can't detect the rate at which samples are fed to the LPT data port. The strobe signal is just another GPIO pin like data pins are, it can't be used for this.

Ah yes, reading this, it seems the program should 'manually' set the strobe signal: http://pinouts.ru/ParallelPorts/ParallelPC_pinout.shtml
In which case it's useless, because Covox software won't do that.

Jepael wrote:

There is no way to detect externally when LPT data port has been written, except the fact that data pins change. You only have the information if you build your own ISA card of course,

That is one way. Another way would be to virtualize it on 386+. Every write to the port would call your own handler, so you can insert extra information. You could then use eg the strobe signal as a toggle. For every byte that is written, you invert the signal. That would give you some clocking information.

Scali wrote:

I don't think you understood the true purpose of my suggestion of the logic gates then. The isolation would be a bit of a side-e […]
Show full quote

I don't think you understood the true purpose of my suggestion of the logic gates then.
The isolation would be a bit of a side-effect. You can still place optocouplers behind them.
But as I said, they should latch whenever a new value is on the datalines, and retain that value until a new one is sent, by looking at the strobe-line.
Because, since the datalines were never intended to have a 'constant' output, I'm not sure what happens during the transition from one value to the next. The datalines might have random output for a while (or output a logical 0 until the next value is ready).
Perhaps that differs from one printer port implementation to the next. It would be interesting to put the signals on a scope, for various computers. Especially very slow ones, like an IBM 5150/5160.

I see what you're saying. However, considering the slow sample rate vs CPU clock speed, even if the parallel port is directly outputting bits as they're filled I doubt it would represent a significant amount of jitter.

I Build this Thing on my homemade PCB, which plugs beetween LPT and Covox :

Shockwav3 designed this Thing,
Reversing the Disney Sound Source

Why not combine the Covox and the DSS on One Plug.
I wanted to do this for a while now.. but still had no time 🙁

Just add Latches to bypass DSS Part and a Jumper to set the Plug to Covox or DSS.

Works well, even Duke Nukem 3D and Shadow Warriror support this Thing.

another Idea of me was to use a MCU and feed the Data into a 8Bit Port and output via PWM.
So we can simulate also DSS, FTL Soundadapter and Covox on one Device.
And maybe Stereo on 1.

Maybe some sort of Busdriver helps to get Noise down.
Before the R2R DAC -> 74HC244 maybe.

Wayne Foletta (Silicon Shack / SiliconSoft) produced a neat little LPT DAC known as the "SoundJr" back in the late 1980s. It's not as advanced as some of the designs being discussed, but has a few interesting features. Instead of discrete resistors, this device employs a pairing of either 767163103 and 767163203, or 8A103 and 8A203 resistor array ICs. In addition, the SoundJr features software-controllable, 8-step volume attenuation. These (or similar) elements might be worth considering as part of a new design.

I have an extra unit, if there's any interest in a reverse-engineering effort. Otherwise, there's a passthrough version of the SoundJr on eBay that could be looked at, and isn't too terribly priced. The listing even includes some oddly nice photos of its PCB.

DSS can also have volume control via software as seen in Duke Nukem 3D
I've seen a few implementations of Covox compatible R2R ladders in resistor network packages (albeit leaded) - even Konami did that at one point.

I'm pretty sure the SoundJr doesnt work with every LPT Port.
As it seems to draw its power from LPT.

Does it really worth to build a lptdac device that sounds "perfect" ? I can understand that one might want to create a version with the cleanest sound but these things are supposed to be cheap, simple and have a unique output. If you take that all away then they lose their magic IMHO
Personally I'd love a clone as close as possible to covox/ftl/dss and if these 3 can exist on a single adapter then it would be ideal.
Not trying to take away your joy, jm2c 😀

matze79 wrote:

I'm pretty sure the SoundJr doesnt work with every LPT Port.

The SoundJr doesn't strike me as a high-power device. The design seems thorough enough that power draw would almost certainly have been taken into account, with respect to "standard" parallel port implementations.

Wich sounds the best? Hmmm... I can't make up my mind. 😀
Can a switch be added to select between the different values and then no cap?

brostenen wrote:

Wich sounds the best? Hmmm... I can't make up my mind. 😀
Can a switch be added to select between the different values and then no cap?

Could add a header instead of soldering the caps in,
then you can insert the cap you want.

Or alternatively some jumpers on a next revision pcb

What about a variable capacitor? So one can tune it to their liking?