Re: [hatari-devel] rev 3689 : splitting cpu cycles above 20

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi,

> The timings that are of most importance are CPU:DSP, many demos rely 
> on the ratio to be 1:2 and have the correct speed (also need memory 
> bandwidth simulation to be solid). Eg, a normal CPU-loop can be:

I totally agree here, that's exactly the point.

In the time , I've seen so many demos and games  working and then not 
working because of changes in CPU or DSP timings.
In general, they freeze at the DSP part or 68030 part in the hostport 
addresses.

I think I've seen all the Falcon programs by now under hatari.

- There are many programs that work well
- Some of them still don't work at all (eg pinball dream (videl), Build 
in obsolescence (DSP stack ??) ...
- The rest are programs that I've already seen working at least one time 
from begining to end (eko system, Hmmm, Moai96, LLamazap, ...).

These last ones are really DSP - CPU sensitive (they synch at the 
beginning of the 1rst transfer and then, they rely on CPU/DSP transfers 
without syncing again).

I'm pretty sure of the DSP cycles part (and in general, the DSP has 
enough time to compute it's datas before the 68030 asks for a value.

That's why I think the most important is the 68030 cycles accuracy (as 
they also drive the videl, the crossbar, ... and the DSP cycles).

A loop of moves that would be 1 cycle wrong would unsynch everything, 
and that's probably the case actually.


I'll play a bit with Videl to change my mind on the 68030 cycles.
I'll come back on this later.

Regards

Laurent