From: Piotr Fusik <pfusik@op...>  20060227 08:01:34

Michael Borisov wrote: > PF> 1. mzpokeysnd seems to round the 1.77MHz rate to a multiple of the output > PF> sample rate. While this probably doesn't degrade the quality, > PF> it probably makes it impossible to emulate POKEY cycleexactly > PF> at the speed identical to the real chip. Normally the 1% difference > PF> in speed is not noticeable, but imagine that you want to play > PF> a music for exactly 3 minutes and 20 seconds (I want to > PF> implement song lengths in ASAP). 1% difference in speed > PF> makes a difference of as much as two seconds. > > The difference in Pokey clock frequency does not accumulate here, > because the update ratio (when Pokey registers are updated) is still > 50Hz or whatever the speed of the CPU is. Therefore, no difference in > music's length or tempo should be observed, only the pitch will be > shifted slightly. If some programs relay on cycleexact Pokey > operation, they may produce improper sounds with mzpokeysnd, but > otherwise it's okay. Also, such tweaking would probably consume all or > nearly all of the 6502's resources, hardly leaving room for screen > animation or the like. > > PF> I guess it is possible to resample from the rate of 1773447 + 100 Hz > PF> with just a longer table of coefficients, but no additional costly > PF> calculations ? > > The table of coefficients will be MUCH longer, by a hundred times or > so. Remez algorithm will take ages to compute such a filter, if it > converges at all. > > However, recently I learned a solution to this problem which does not > involve too much additional computational cost. It's still not for > free, however. We should keep this in mind and integrate that solution > into mzpokeysnd as soon as it will be top priority. Then we could make > our Pokey emulation cycleexact, and the Pokey frequency will be exact > too. Cycleexact POKEY emulation is toppriority for me. POKEY sound should be synchronized to the rest of the emulation down to a single 1.77MHz cycle. The emulation as a whole, however, does not need to run at exactly 1773447.00000 Hz. I don't know how precise are Atari clocks, but I guess that +100Hz or even more is possible. The other question is how precise are soundcard sample rates and PC clocks. Rounding 1.77MHz to a multiple of 44.1kHz introduces an error of about 1%  isn't that an audible difference in pitch? If so, we should minimize it to a difference that is not easy to hear for most people. For song lengths in ASAP, the precision should be like 0.1% I think. This would make a difference of just a second for 15minute music, which shouldn't be a problem provided that the difference is welldefined. We would choose a frequency near 1.77MHz within 0.1% that minimizes the number of filter coefficients. > > PF> 2. What is the mapping of (AUDC&0xf) to the output level? > PF> I mean, is it truly linear? > PF> atari++ seems to apply gamma mapping on the samples > PF> and the documentation of the NES sound chip gives an equation > PF> of the form: outvol = A / (B / sum(vol) + C). > > We were measuring the ouput characteristics of Pokey volumes on real > Atari. As long as one channel only is operating, the characteristic > does not deviate from linear by any measurable amount. When two or > more channels generate the same frequency being synchronized (STA > STIMER), the things change. Real Pokey becomes nonlinear, but this > research was not finished to give a plausible formula. I think I > should study the Atari schematics, perhaps I'll find the correct > dependency. Hmm, this could be more important than the quantization noise. :)  A month ago I started documenting POKEY for the purposes of cycleexact emulation. The existing docs aren't precise enough when it comes to single cycles. Perry did excellent work reading the schematics and making tests with a real Atari. Nearly all questions are mine and nearly all answers are his. I also included some of your comments. The current version of the documentation is available at: http://asap.sourceforge.net/pokeydoc.zip After extracting the zip, open index.xml in an XMLcapable web browser. The topic that is probably the most interesting for you is DAC. Piotr 