[hatari-devel] Falcon (bad)Patch but sound quality increased a lot

[Nicolas Pomarède]

Le 15/01/2011 15:00, Laurent Sallafranque a écrit :
> Hi,
>
>
>> I don't run falcon demos that often, so could you tell if the demos
>> fully works up to the end without your proposed patch ? If it stops,
>> can you tell me where so I can be sure to really work on the same bases.
>>
>
> Without the patch, Eko_System crashes after 2 effect.
>
> First, there's the little presentation.
> Then, there's a tridi transparent gouraud ball (which doesn't display
> without the patch)
> Then, a little tridi word.
>
> Then 3d Gouraud fruits (apple, lemon, ...) (Demo crash here without the
> patch).
>
> With my patch (I mean not the latest proposition you told me to try), it
> runs to the end.
>

Hello,

I add some time to make a few tests, and I think some things are wrong 
in current approach and they appear in more complex demos like eko system.

As you say, removing the last call to DSP_Run as I proposed stops the 
first gouraud ball from displaying.
The problem is that if I add :

                 if ( Cycles_GetCounter(CYCLES_COUNTER_CPU) != 0 )
                         fprintf ( stderr , "cpu count!=0\n" );

before calling this last DSP_Run, you will see that there're very few 
prints, which is what I expected because the 2 calls added above should 
already run the dsp for the needed cycles (so DSP_Run will be called 
with a parameter "0").

What this means and is confirmed when looking at DSP_Run is that DSP_Run 
is calling dsp56k_execute_instruction() at least once, even if 
nHostCycles==0, which is not possible on a real falcon, you can't 
execute more dsp instructions if the cpu (which is bound to the master 
clock) did not have an increase in cycle counter.

So, at first sthg like :

         if (nHostCycles == 0)
                 return;

should be added to the start of DSP_Run. But this is not enough as the 
demos still doesn't work correctly.
I need to make more tests, but I have the feeling that the "- 
save_cycles + 1" and the "save_cycles = cycles" at the end are not correct.

save_cycles will be <=0, if it's <0, it means the dsp executed 1 more 
instruction that it should between the time allowed by the cpu. So, on 
next call, you should execute 1 less instruction and as save_cycle<0, 
the line should be more like :

Sint32 cycles = nHostCycles * ( DSP_FREQ / CPU_FREQ ) + save_cycles + 1;

But then, I don't see why a "+ 1" ? Once we test nHostCycles==0, we know 
DSP_FREQ=CPU_FREQ*4, so there should be no rounding error.

These are just some quick traces I made, I need to spend more time on 
this to correctly fix it. But in the meantime, I don't think it's useful 
to commit the patch to m68k_run1, the bases are not stable enough and 
this would not correct the real source of the problem (but in the end, I 
agree DSP_Run should be called more often in m68k_run1)

Regards

Nicolas