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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


> If Hatari evolves (and I really really hope it will) to support faster CPU and FastRAM, the huge work on clockcycle exact 030-Videl won't be of any use (perhaps even make things worse?).

If you speak about an emulation of the 68040/68060 CPUs or accelerated cards (68060+fastRam), all the work on the 68030 cycles would't be a problem, as I think we would choose a generic 68040/60 CPU (CPUEMU_31 for example).

All the cycle closk I've included (and I'll continue to include) is limited to the 68030 cycle exact CPU (CPUEMU_21)

Regards
Laurent


Le 08/01/2012 10:51, Anders Eriksson a écrit :
On Sat, 7 Jan 2012, Nicolas Pomarède wrote:

> (I don't even know if some falcon demos are doing "sync" code with
the video beam ?)

I think I've seen most, if not all, Falcon demos and so far no hardsync demos. I don't think it's possible to do in a reliable way with all DMA stuff affecting CPU bus access.


I don't think timings are not important, I just say it's *really really* complex to measure on the falcon, and that the falcon mode is not ready enough for this.

I don't think it's necessary to have the 030/Videl in exact sync, HBL would be a good thing to have though (a few demos uses HBL/Timer-B for splitscreen/rasters).

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. If the emulator doesn't take ST-RAM bandwidth into account, demos will crash because of the too fast CPU loop. This is also the reason why a lot of DSP demos fail on accelerator boards, the 1:2 ratio is off. Of course, cleanly coded DSP programs won't crash, but they will also have slower transfer (sync code in the CPU-loop).


There're many roads to reach a good falcon emulation, my opinion is that focusing too much on cycle exact problems for now is not the most efficient way, I'm sure there're many other parts to improve that don't require 100% accuracy and that would improve user experience a lot in demos for example (sound problem as reported by anders in dspmod, videl)

If Hatari evolves (and I really really hope it will) to support faster CPU and FastRAM, the huge work on clockcycle exact 030-Videl won't be of any use (perhaps even make things worse?).


--
Anders Eriksson
ae@xxxxxx     http://www.dhs.nu/
ae@xxxxxxxxx  http://www.atari.org/




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/