[hatari-devel] Falcon (bad)Patch but sound quality increased a lot
Nicolas Pomarède
npomarede at corp.free.fr
Sat Jan 15 12:15:31 CET 2011
Le 13/01/2011 23:34, Laurent Sallafranque a écrit :
> Don't forget to activate 32 Mhz CPU with the Eko_System demo.
> Else, it doesn't work well.
>
> Regards
>
> Laurent
>
Hello,
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.
BTW : when switching to tos 4, Hatari ask to reboot and go in Falcon
mode. I think we should enable DSP now by default when doing so, it's
not easily guessable for a normal user to know he must also choose to
enable DSP in the UI.
DSP should be stable enough to be enabled by default ? If user wants and
know what it does, he can disable it later, but choosing a "Falcon"
should enable all possible component I think.
Nicolas
> Le 13/01/2011 23:28, Nicolas Pomarède a écrit :
>> 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
>>
>>
>>
>
More information about the hatari-devel
mailing list