[hatari-devel] 68030 Debug mode and new CPU

[Nicolas Pomarède]

Le 15/02/2011 23:29, Thomas Huth a écrit :

> Sleeping there is certainly a bad idea, but maybe the loop can be
> improved so that it does not take so long?
> Currently we have:
>
>      while (regs.spcflags&  SPCFLAG_STOP) {
>              ...
>              M68000_AddCycles(4);
>              while (PendingInterruptCount<=0&&  PendingInterruptFunction) {
>                  /* 1st, we call the interrupt handler */
>                  CALL_VAR(PendingInterruptFunction)
>                   ...
>              }
>      }
>
> So this mainly decreases  PendingInterruptCount step by step ... maybe
> it would be possible to do
>             M68000_AddCycles(INT_CONVERT_FROM_INTERNAL(PendingInterruptCount,
>                              INT_CPU_CYCLE)
> instead, so that the first while loop is handled faster?
> Then Hatari could sleep longer in the VBL handler instead...?
> Just a though...
> What do you think?

Yes, you're right, this could be an optimisation to "jump" directly to 
the point where a possible interrupt could be tested to exit the STOP state.

But in the event where we would like to make a very precise shifter 
emulation for example (where we draw pixels every 4 cycles, to emulate 
some really special shifter effects), this would give bad results 
because it would "skip" the equivalent of PendingInterruptCount pixels 
in one go.

For such an extreme precision mode, we would certainly need a dedicated 
m68k_run function anyway, so we could have different strategies in each 
m68k_run to handle the stop state.

On the practical side, I'm not sure this would give us a noticable 
decrease in cpu usage ; main use I know for STOP is to wait for the next 
VBL int (stop $2300) and it's often used for only a few frames (during 
some initializations, or to save/restore video registers in a way that 
doesn't confuse the shifter).

An even more rare case is to trigger a first hbl interrupt and use stop 
to wait for next timer b interrupt (this is an alternative to reading 
$ff8209 when you want to get synced with the video signal, in order to 
remove lower border for example (when you don't need an exact 4 cycles 
precision)).

That's an idea we could keep for later, but I doubt there're a lot of 
real cases (games or demos) that make use of STOP in such a way we would 
really gain some CPU ressources and be able to measure it.


Nicolas