Re: [hatari-devel] Falcon raster emulation

Yes I think it would be enough to emulate effects which would still work with different CPU speeds. I don't think many Falcon coders actually depended on exact 16mhz performance of the CPU (since that was nearly impossible anyway with all the strange stuff going on inside the machine - and many machines are accelerated in some way). So just MFP and some Videl state (like palette) effects would cover a lot of useful things.

I think any code which attempts to race the beam with CPU cycles is going to soon fail on a real machine anyway.

The real problem is perhaps interfacing with the CPU core as the 'clock master' when it should probably be a slave to a system clock structure of some kind (which also drives MFP and display timing). The CPU timings are actually much less important in the real world. The actual changes involved and amount of work though - I have no idea... possibly quite a lot!

I think 'limited' scanline-level effects and TT ram are my two top Hatari requests at the moment :)

On 12 December 2013 09:11, Miro Kropáček <miro.kropacek@xxxxxxxxx> wrote:

On Thu, Dec 12, 2013 at 10:02 AM, <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..

--
MiKRO / Mystic Bytes
http://mikro.atari.org