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

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

> If the emulator doesn't take
> ST-RAM bandwidth into account, demos will crash because of the too fast
> CPU loop.
I don't think that's taken at all into account in Hatari...

Laurent?


Access to ST memory is only using the ST emulation code (eg memory.c).
I didn't change anything here.
So, for the Falcon, the memory access are strictly the same than for the 
ST emulation.

Laurent


Le 08/01/2012 16:48, Eero Tamminen a écrit :
> Hi,
>
> On sunnuntai 08 tammikuu 2012, Anders Eriksson wrote:
> > 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:
> >
> > move.w (a0),(a1)+
> >
> > Where a0 is the host port and a1 ST-RAM. The speed on the ST-RAM access
> > greatly differs between resolutions used.
> Because Videl transfers from video RAM to VGA/RGB at 50/60Hz in
> the "background" take part of the RAM access memory bandwidth?
> Does it correlate directly to Width x Height x Bitdepth data amount?
>
> Do you have numbers on how much this effect is at its smallest
> and largest?
>
>
> > If the emulator doesn't take
> > ST-RAM bandwidth into account, demos will crash because of the too fast
> > CPU loop.
> I don't think that's taken at all into account in Hatari...
>
> Laurent?
>
>
> 	- Eero