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

npomarede at corp.free.fr npomarede at corp.free.fr
Tue Feb 23 15:53:52 CET 2010


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