[hatari-devel] some videl emulation news

[Laurent Sallafranque]

OK for video.

All these questions for DSP < - >  68030 synchro.

As we use the 68030 as main clock, if we don't take into account all the 
waitstates (DMA sound, videl, ...) we can miss a lot of clockedges for 
the DSP speed, no ?

The problem with falcon emu is (I think) that we need to be synchro 
between 68030 (main clock), DSP and crossbar.
If the 68030 eats some waitstates because of sound DMA or Videl, I think 
we should take them into account for better synchro with the DSP and 
crossbar.

Maybe I think wrong and shouldn't worry about these cycles, but they 
seem to be "time consuming" (from Mikro's doc about stRam timings and 68030)

If I try to take them into account, hatari becomes horribly slow.

Regards

Laurent



Le 06/06/2011 22:49, Nicolas Pomarède a écrit :
> Le 06/06/2011 22:44, Laurent Sallafranque a écrit :
>> OK, thanks for the explanations.
>>
>> So, hatari takes into account the ram access time every 16 pixels ?
>> (sorry, but video.c is quite complex to read)
>
> No, because it would be too difficult to handle with the current 
> infrastructure, as it would require to be able to plot pixel every 16 
> cycles, including in the middle of any cpu instruction.
>
> So, Hatari draw one line every 512 cycles in low res for example 
> (there're very few program/demos that require to update the video 
> every 16 cycles, "Gen4 Demo" by ULM is one of these but you need good 
> eyes to see where's the error :) )
>
> Nicolas
>