Re: [hatari-devel] Falcon raster emulation

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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