|Re: [hatari-devel] rev 3689 : splitting cpu cycles above 20|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 07/01/2012 00:22, Laurent Sallafranque wrote:
I've splitted cpu instruction not for the DSP, but for the sound (maybe
it's not useful and in this case, I'll remove it) :
At 50000 Khz 16 bits stereo, the crossbar needs an internal interrupt
every 60 cycles.
A movem with all the registers can take more than 150 cycles.
A demo like Amanita (DHS) uses a lot of these movem.
So, I've decided to split the big instruction (in cycle) to be sure to
execute all the sound updates between the crossbar and the DSP (in SSI
Do you think this is a good idea ? (I think Amanita sounds better with
it, but I'll have to listen many times with and without the cycle
splitter to be sure of this).
Well, in the way you split the code in a "while", I don't see any
theorical difference. For example, if curr_cycles is 60, you replace
DSP_run (120) by 3 successive calls of DSP_run ( 40 ) in the while loop.
But during this "while", nothing happens : M68000_AddCycles doesn't call
any interrupts or things like that, it just increments the cycle counter.
So, you could replace the while + the 3 calls to DSP_run (40) with a
single DSP_run (120) and it would be exactly the same.
That's why I think the while loop has no use : because it doesn't change
the CPU state at the same time the dsp state changes.
Also, a 50 kHz sound @ 16 bits stereo should be completly emulable when
you have instructions longer than 60 cycles. This is the same problem as
the STE dma, with more data, but it should work too.
If there're "clicks" or "holes" in the output sound, then it's a bug in
the falcon sound emulation code (bad emulation of the internal fifo).
How does amanita plays sound ? Does it uses dsp, or just playing sample
from the falcon's ram ?