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

npomarede at corp.free.fr npomarede at corp.free.fr
Tue Feb 23 15:21:01 CET 2010


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