[hatari-devel] Filters utilized more effectively

[Nicolas Pomarède]

Le 18/05/2011 09:19, David Savinkoff a écrit :
> I checked a STE schematic and found a 8.010613 MHz crystal associatied with
> dma sound. To find the actual sampling rate frequency you would divide
> 8.010613 MHz / 50066 Hz and get 160.0010586026445092, but 160.0015..
> is not an integer value (the hardware divider is going to be 160). So now you
> divide 8.010613 MHz / 160 and get 50066.33125 Hz for the sampling rate.
>
> Thus, 50066.33125 Hz is 'nominally' 50066 Hz; by Atari literature.
>
> But, crystals are usually accurate to about 100 parts per million 'and'
> are pullable (by changing the parallel or series capacitor) by even more.
>
> So, +/- 100ppm at 8.010613 MHz is: +/- 801 Hz
> (and pullable by a few times 100ppm)
>
> If a crystal and capacitor on an STE result in a clock frequency of
> 8.010613 MHz +/- 801 Hz, then the Sampling frequency will be within
> the range of 50061.325 and 50071.338 Hz.

Hello

I agree, but you're mixing the measured output on a real STE with the 
theorical hardware values from the documentation. Hatari is not 
"analog", all the computations are based on the fixed theorical values 
of each components, so Hatari is a kind a "ideal" Atari.


> Furthermore (and beside the point) Hatari has this:
> #define CPU_FREQ   8012800
> ..which when divided by 160 'would on real hardware' be 50080 Hz for the
> sampling rate.

cpu_freq is not the same as the FCLK used on STE. On STE cpu freq can 
change if you connect a video genlock for example, because the shifter 
will need to get its input master freq (approx 32 Mhz) from the external 
source. In that case, using cpu_freq/160 would be wrong.

Anyway, Hatari doesn't work at a master clock level, as an approximation 
it uses the cpu as its master clock (which is not the case in real ST) 
and adapt other components to work this way (Hatari only has 1 "input 
clock" not several as on real hardware).

>
> All of this makes for a justifiable argument that 50000 Hz through 50100 Hz
> are realistic sampling rates on a real Atari STE (and Hatari). I believe
> CPU_FREQ / 160 is better, because a real STE does it this way.

I don't agree. The fact that a real Atari doesn't precisely output at 
the requested freq is not a reason to allow more freq on Hatari. Due to 
its "digital" nature Hatari really outputs at 50066 Hz (minus some 
rounding errors).

What is important is to emulate the requested freq (25033, 50066, ...), 
not to emulate the measured freq we could have on several STE models 
(due to different PLL, components, ...).

If an Atari's program has only 4 theorical values to choose from, I 
don't see why we should allow more frequencies in the emulator.

We're emulating based on values from the doc, we don't try to simulate 
some possible cristal's errors or things like that.

Nicolas