[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