[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