Re: [hatari-devel] rev 3689 : splitting cpu cycles above 20

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 07/01/2012 11:47, Laurent Sallafranque wrote:
> Hi,
>
> I reply to both Nicolas and Anders.
>
>  > 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.
>
> Ok Nicolas, I agree here this patch is useless like this.
> I first thought AddCycle would compute the internal interrupts (I didn't
> pay enough attention here).
>
>
> I try to explain again why I tried this : let's take a movem 150 cycles.
>
> During this time, the DSP can run 300 cycles (between 100 and 150
> instructions), while the CPU runs 1 instruction.
>
> In the same time, the crossbar will send 2 datas and a half to the DSP
> and the DSP will send 2 samples and a half to the crossbar (both for
> 25Mhz clock, it increases a bit with the 32 Mhz clock).
>
> My aim was to split the 150 cycles into packets of 20 cycles, add these
> cycles (AddCycles), compute if there's a crossbar internal interrupt (to
> send some datas from <-> to the DSP and let run the DSP for an amount of
> 40 cycles).
> Like this, during the movem, the DSP continues to run, get the datas
> without hole and then back the result to the DAC.
>
> This is of course useable not only for movem, but for all big cycles
> instructions

I understand what you meant, but as I said in a previous email, 
AddCycles doesn't do anything regarding interrupts, so splitting a "big" 
680xx instruction in small chunks of 20 cycles won't solve anything. To 
achieve what you describe in a "real" falcon way, cpu and dsp need to 
run in parallel, which is what I described as being able to have the 
"micro code" of the 68030 to split each instruction in very small chunks 
(of 2 or 4 cycles) and call DSP_run every 4 cycles (expect major slow 
down of the emulation).

I don't know how the replay in Amanita works, but if it doesn't rely 
explicitly on the sound FIFO and don't use some kind of "single 
buffering where data is computed at the same time it's played by the 
audio", then I think it should work and should be used a starting base 
to improve falcon audio.

As seen with the problem reported by Anders, I think there're much 
"serious" problems to fix in audio before going to cycle exact problem. 
The randomness of what Anders reported looks like some indication for 
some deep bugs. Finding why those bugs happens, would certainly help a 
lot to improve.


Nicolas