[hatari-devel] I'm lucky ;) K.prg is working
Laurent Sallafranque
laurent.sallafranque at free.fr
Tue Feb 23 15:44:43 CET 2010
> 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 ?
What should I search here ?
Regards
Laurent
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