Re: [hatari-devel] Falcon raster emulation

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


Le 12/12/2013 10:11, Miro Kropáček a écrit :

On Thu, Dec 12, 2013 at 10:02 AM, <laurent.sallafranque@xxxxxxx
<mailto:laurent.sallafranque@xxxxxxx>> wrote:

    Accurate cycles is nearly impossible (at least, we don't know the
    exact div/mul algo), but much better approx should be OK for a
    complete VIDEL emu.


I don't think we need a super-accurate cycle state machine. Timer-B
effects are derived from MFP, HBL is virtually identical, so right, the
main thing needed is a stable screen timing. I guess a lot things can be
derived empirically, i.e. if you see that 320xYYY in TC takes such and
such time on Falcon, you can easily guess the "noise" if you know Videl
cycles. Fortunately, due to a Videl bug it is not possible to do the
famous change-in-the-middle effects so per-line accuracy is more than
enough.


Yes, I second that, cpu emulation now handles caching, maybe not all instructions will give good cycles, but I think it's a very good base.

If it's not too much work, we should add hbl and timer b interrupt for falcon (it should be similar to the STF, starting a timer that last the equivalent of one raster line) ; it's sure that we will see situation where the raster colors will not be stable, but at least it will give a visual feedback of what it working and what is not, which could help to isolate cpu instructions that create problems.

We don't want to reach cycle precision as on STF where it's required to do fullscreen, having a interrupt on every raster should be enough to improve a lot of things


Nicolas



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