Re: [hatari-devel] no more sound in falcon ?

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 31/12/2015 15:03, Douglas Little a écrit :
>  From what I can understand so far, and what I've seen in tests, there
> is an underlying problem which will foil attempts at fixing the cycle
> accuracy of the Falcon CPU.
>
> I believe the CPU/core is reporting divergent elapsed-cycles information
> to the DSP and to the rest of the devices (particularly MFP). Or some
> functional equivalent - duplicate and divergent calculations of elapsed
> time.
>
> This is what my tests are saying to me. If somebody can figure out
> how/why that is happening and fix that, then it will be worth spending
> time on cycle accuracy. Trying to fix the cycle sums before solving this
> will probably be quite frustrating, at least in terms of making demos
> etc. work and perform properly. :-/
>
> If I can find some time I'll try to look at how that stuff actually
> works inside Hatari. All I can say for now is that the DSP and MFP
> receive divergent time information, however good or bad that information
> happens to be in absolute terms.

I would say that MFP receives the same "number of cycles" than the CPU 
used per instruction.
But from my changes affecting wait states for IO registers, I see that 
the DSP receives less cycles than what it should really receive (long 
standing bug), and still it works "better" than if I really count wait 
states (at least there's sound in your demo, but this can have more 
subbtle wrong impacts than just breaking sound)

So my conclusion would be : cycles are not correct yet in Hatari with 
68030, but this is partially compensanted (by luck :) ) by a wrong count 
of CPU cycles (wait states not counted) that still allows the DSP to 
work (even if it's often faster than a real DSP).

In short : it's quite a mess :)  Fixing 68030 cycles is the 1st required 
step to a correct emulation of DSP cycles. Once CPU cycles are correct, 
everything else should fall much better into place.

Nicolas