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,