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/