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

[Nicolas Pomarède]

Le 13/01/2011 22:54, Laurent Sallafranque a écrit :
> Nicolas, Do you plane to upload my DSP patch or do you want me to do it ?
>
> Regards
>
> Laurent
>
>

Hello

I would like to try EKO, I don't understand why moving the last DSP_Run 
inside "if (regs.spcflags)" at the end of m68k_run is causing an error, 
this should not be the case if the 680xx cpu count was not increased above.

If you leave it outside of this "if" (as it is now), there will be some 
cases where Cycles_GetCounter(CYCLES_COUNTER_CPU) = 0, so DSP_Run will 
be called with 0, which is useless (we will have 0 because DSP_Run will 
be already called by the 2 patches you proposed to add above)

I will try to have a look this week end.

Nicolas


> Le 11/01/2011 23:07, Nicolas Pomarède a écrit :
>> Le 11/01/2011 22:16, Laurent Sallafranque a écrit :
>>> Hello,
>>>
>>> I've generated a bad patch for Falcon DSP.
>>>
>>> With this patch, sound quality is really so much better with some demos.
>>> I've tested with EKO_System, Illusion demo, R U Experienced.
>>>
>>> It's what I thought. I need a precise 60 cycles clock for the SSI
>>> tranfers (DSP <-> Crossbar).
>>>
>>> I've called DSP_Run inbetween each 68030 instruction cycles computing.
>>> With this, instead of having a 100 cycles instruction (1 big call to
>>> crossbar and DSP), it generates more intermediate calls.
>>> My timers keep OK and sound is nice.
>>>
>>> I'm still sure that the 68030 as a clock for the Falcon is not good
>>> enough (cycles are too long).
>>>
>>> Cycles ARE important in falcon emulation too (look at my previous patch,
>>> DSP timings change let some demos run).
>>> FalcAmp and Crown of creation complain about "bad timings", ...
>>>
>>> Any suggestion here ?
>>>
>>> Regards
>>>
>>> Laurent
>>>
>>
>>
>> Hello,
>>
>> yes, it's sure that you should call DSP_Run as frequently as possible,
>> each time M68000_AddCycles (or equivalent) is called, else you will
>> miss more cycles when calling the DSP emulation.
>>
>> In the current m68k_run, the main cause of possible "error" is that
>> DSP_Run is not called each time we process an interrupt.
>>
>> In the 3 patches you propose, I think the 1st one is not necessary. In
>> case SPCFLAG_EXTRA_CYCLES is set, we will add most of the time 4
>> cyles, so calling DSP_Run again just after 4 cycles might be counter
>> productive.
>>
>> I think the 2 patches before "#if 0" can be kept and the original last
>> call to DSP_Run should be changed from :
>>
>>
>> if (regs.spcflags) {
>> if (do_specialties ())
>> return;
>> }
>>
>> /* Run DSP 56k code if necessary */
>> if (bDspEnabled) {
>> DSP_Run( Cycles_GetCounter(CYCLES_COUNTER_CPU) );
>> }
>>
>> to
>> if (regs.spcflags) {
>> if (do_specialties ())
>> return;
>>
>> /* Run DSP 56k code if necessary */
>> if (bDspEnabled) {
>> DSP_Run( Cycles_GetCounter(CYCLES_COUNTER_CPU) );
>> }
>> }
>>
>> -> No need to call DSP_Run again if M68000_AddCycles was not called by
>> do_specialties, because the cpu cycle counter would be the same since
>> the latest call to DSP_Run.
>>
>> In the end, there would be 3 calls to DSP_Run : 1 would be made every
>> time, the 2 others only when there's an exception.
>>
>> Could you try this ? If that's OK I can commit a patch to do this
>> (this would not really impact emulator's performance)
>>
>>
>> Of course, the final stage of this to get perfect emulation is to do
>> the same as WinUae in its most precise mode : each cpu instruction is
>> split into 4 cycles and all components (blitter, copper, dma sound,
>> ...) are called every 4 cycles to see if they need "to work" -> really
>> more cpu intensive.
>>
>>
>> Nicolas
>>
>>
>>
>>>
>>>
>>> diff -r 1ea504dede73 src/uae-cpu/newcpu.c
>>> --- a/src/uae-cpu/newcpu.c Tue Jan 11 21:08:35 2011 +0100
>>> +++ b/src/uae-cpu/newcpu.c Tue Jan 11 22:09:16 2011 +0100
>>> @@ -1737,6 +1737,13 @@
>>> Cycles_SetCounter(CYCLES_COUNTER_CPU, 0); /* to measure the total number
>>> of cycles spent in the cpu */
>>>
>>> M68000_AddCyclesWithPairing(cycles);
>>> +
>>> + /* Run DSP 56k code if necessary */
>>> + if (bDspEnabled) {
>>> + DSP_Run( Cycles_GetCounter(CYCLES_COUNTER_CPU) );
>>> + Cycles_SetCounter(CYCLES_COUNTER_CPU, 0); /* to measure the total
>>> number of cycles spent in the cpu */
>>> + }
>>> +
>>> if (regs.spcflags & SPCFLAG_EXTRA_CYCLES) {
>>> /* Add some extra cycles to simulate a wait state */
>>> unset_special(SPCFLAG_EXTRA_CYCLES);
>>> @@ -1744,6 +1751,12 @@
>>> nWaitStateCycles = 0;
>>> }
>>>
>>> + /* Run DSP 56k code if necessary */
>>> + if (bDspEnabled) {
>>> + DSP_Run( Cycles_GetCounter(CYCLES_COUNTER_CPU) );
>>> + Cycles_SetCounter(CYCLES_COUNTER_CPU, 0); /* to measure the total
>>> number of cycles spent in the cpu */
>>> + }
>>> +
>>> #if 0
>>> while (PendingInterruptCount <= 0 && PendingInterruptFunction)
>>> CALL_VAR(PendingInterruptFunction);
>>> @@ -1757,6 +1770,12 @@
>>> {
>>> CALL_VAR(PendingInterruptFunction); /* call the interrupt handler */
>>> do_specialties_interrupt(false); /* test if there's an mfp/video
>>> interrupt and add non pending jitter */
>>> +
>>> + /* Run DSP 56k code if necessary */
>>> + if (bDspEnabled) {
>>> + DSP_Run( Cycles_GetCounter(CYCLES_COUNTER_CPU) );
>>> + Cycles_SetCounter(CYCLES_COUNTER_CPU, 0); /* to measure the total
>>> number of cycles spent in the cpu */
>>> + }
>>> #if 0
>>> if ( regs.spcflags & ( SPCFLAG_MFP | SPCFLAG_INT ) ) { /* only check
>>> mfp/video interrupts */
>>> if (do_specialties ()) /* check if this latest int has higher
>>> priority */
>>>
>>> _______________________________________________
>>> hatari-devel mailing list
>>> hatari-devel at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/hatari-devel
>>
>> _______________________________________________
>> hatari-devel mailing list
>> hatari-devel at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/hatari-devel
>>
>>
>
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel