[hatari-devel] I'm lucky ;) K.prg is working

Laurent Sallafranque laurent.sallafranque at free.fr
Tue Feb 23 16:35:17 CET 2010


OK, I'll try all these tests tonight.
But just a last question :

Why shouldn't we execute some DSP code if there was an exception or 
interrupt ?
(the return after do_specialties ())

Regards

Laurent



npomarede at corp.free.fr a écrit :
> On Tue, 23 Feb 2010, Laurent Sallafranque wrote:
>
>>> It would be interesting to know which part of do_specialties is causing 
>> K.prg to freeze before moving code.
>>
>> Ok to investigate deeper, but :
>>
>> What is do_specialties code ?
>
> It mostly handles all exceptions/interrupts that can happen after a 
> cpu instruction (as well as other less frequent things).
>
>> What should I search here ?
>
> I don't have the exact idea ; but first thing would be to run with 
> --trace all, and see if your printfs (for cycle > 50) are correlated 
> with a stange dsp behaviour and if there's a cpu exception or 
> hbl/vbl/timer just before or after the last cpu instruction.
>
> No need to look at do_specialties for now, but you should try to 
> isolate a piece of cpu/dsp code that causes the lock in K.prg and see 
> if that's always in the same cpu context (interrupts, particular 
> instruction, ... ?)
>
>
> Nicolas
>
>>
>>
>> npomarede at corp.free.fr a écrit :
>>> On Tue, 23 Feb 2010, Laurent Sallafranque wrote:
>>>
>>>> Hello,
>>>>
>>>> I've had a lot of chance today.
>>>> I was investigating about 68030 Cycles, and I saw in newcpu.c that DSP
>>>> call was after a potential return.
>>>>
>>>> I've inverted the DSP call and the potential return and I've tested 
>>>> K.prg
>>>> It's working.
>>>>
>>>> Returning to previous state freezes K.prg
>>>>
>>>> I've been really lucky, because I've tested all the non compatible
>>>> programs and demos and they're not concerned by this patch.
>>>>
>>>> Here is the patch.
>>>>
>>>> diff -r 4a0c21b49fb4 src/uae-cpu/newcpu.c
>>>> --- a/src/uae-cpu/newcpu.c      Sun Feb 21 23:00:19 2010 +0200
>>>> +++ b/src/uae-cpu/newcpu.c      Tue Feb 23 13:41:23 2010 +0100
>>>> @@ -1759,15 +1759,15 @@
>>>>          }
>>>> #endif
>>>>
>>>> +       /* Run DSP 56k code if necessary */
>>>> +       if (bDspEnabled) {
>>>> +           DSP_Run(cycles);
>>>> +       }
>>>> +
>>>>        if (regs.spcflags) {
>>>>            if (do_specialties ())
>>>>                return;
>>>>        }
>>>> -
>>>> -       /* Run DSP 56k code if necessary */
>>>> -       if (bDspEnabled) {
>>>> -           DSP_Run(cycles);
>>>> -       }
>>>>     }
>>>> }
>>>>
>>>> @@ -1812,15 +1812,15 @@
>>>>        while (PendingInterruptCount <= 0 && PendingInterruptFunction)
>>>>          CALL_VAR(PendingInterruptFunction);
>>>>
>>>> +       /* Run DSP 56k code if necessary */
>>>> +       if (bDspEnabled) {
>>>> +           DSP_Run(cycles);
>>>> +       }
>>>> +
>>>>        if (regs.spcflags) {
>>>>            if (do_specialties ())
>>>>                return;
>>>>        }
>>>> -
>>>> -       /* Run DSP 56k code if necessary */
>>>> -       if (bDspEnabled) {
>>>> -           DSP_Run(cycles);
>>>> -       }
>>>>     }
>>>> }
>>>>
>>>>
>>>> Do you think there's no risk to apply it ?
>>>>
>>>> It doesn't seem to break the working programs.
>>>
>>> I'm not against moving this part if you can find the explanation on 
>>> why it works better this way :)
>>> The fact that moving some code fixes the problem is usually hiding a 
>>> deeper problem.
>>>
>>> It's good that it doesn't break anything, but what you do with that 
>>> is that :
>>>  - you emulate 680xx
>>>  - you emulate dsp
>>>  - you emulate 680xx exceptions from the latest 680xx instruction
>>>
>>> So the flow :
>>>
>>>  - cpu
>>>  - exception
>>>  - dsp
>>>  - cpu
>>>  - exception
>>>  - dsp
>>>
>>> becomes
>>>
>>>  - cpu
>>>  - dsp
>>>  - exception
>>>  - cpu
>>>  - dsp
>>>  - exception
>>>
>>> And in the end, 2 dsp calls are separated by cpu+exception or 
>>> exception+cpu, which take the same time just in a different order.
>>>
>>> So, I'm not sure this is a general solution ; perhaps do_specialties 
>>> is changing some values before the dsp emulation that would cause 
>>> the problem ?
>>> But in that case we should find which values instead of just moving 
>>> the block of code.
>>>
>>> It would be interesting to know which part of do_specialties is 
>>> causing K.prg to freeze before moving code.
>>>
>>>
>>> Nicolas
>>>
>>>
>>
>>




More information about the hatari-devel mailing list