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

Laurent Sallafranque laurent.sallafranque at free.fr
Tue Jan 11 23:22:27 CET 2011


I test it immediatly.

Eko_system demo is a good candidate for this test, as it freezes without 
my 2nd patch.
My DSP timers patch is better with this demo anyway.

Do you think it would be possible to trigger the crossbar interrupt also ?
(I mean I'd like to have more calls to the crossbar too, as it is a 
sensitive component too).
(it needs 60 cycles for some sound frequencies). I reload this interrupt 
with the delta cycles each time, but some 68030 instructions + 
interrupts are giving too long cycles at once (and I loose some datas)



 > 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.

That's exactly what I dream of. With this, I could have a precise DSP, 
precise host port (8 Mhz), a precise crossbar (it would become a 
componant by itself) and a precise SSI port for the Falcon.
I think this would increase emulation quality (falcamp, crown of 
creation, .. suffers from timing problems).


laurent





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
>
>




More information about the hatari-devel mailing list