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

[Laurent Sallafranque]

I added the +1 to have the demo "ROT3DBMP.PRG" or "BOUND3.PRG" run. 
(probably some other programs, but I don't remember).

This +1 is really "the limit" to let these programs run correctly or not.

I've already tested some things without it, but it seems to be needed to 
work.

I agree it should not be there.

Perhaps DSP timings (cycles) are still not perfect, but I've done many 
tests with them.

I know that there can be differences in DSP cycles with interrupts, but 
to be completely perfect, we should had a 3 instructions pipeline in the 
DSP.
Until now, I haven't had to code this pipeline (I simulate it in DSP 
interrupts, and I take the extra cycles in account, according to the 
Motorola DSP documentation).

Maybe the problem is not there anyway. (There's still this 32Mhz problem 
with EKO_System demo that may explain some things).

Another try I tested without success : the Host Interface (DSP <--> 
68030 exchanges on portB) is running at 8 Mhz, not 32. I've tested this 
last week, but I didn't noticed any change.

Your "new look" on this problem is really welcome.

Regards

Laurent



Le 16/01/2011 13:12, Nicolas Pomarède a écrit :
> 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
>
>
>