Re: [hatari-devel] MFP timing

["Roger Burrows" <rfburrows@xxxxxxxxx>]

Hi Nicholas,
On 4 Sep 2013 at 0:02, Nicolas Pomarède wrote:
> tst.b $1000.l will take 16 cycles
>
> tst.b $fffffa01 will take 16+4 cycles due to wait state when accessing mfp.
>
> So, access to mfp in this case is coherent with your microsecond values
> for ST.
>
> I can't say for falcon or tt, as I don't have one to test ; there's
> certainly wait state too, but the tst.b instruction is certainly faster
> on those cpu.
>
Yes, the 68030 "tst.b $ffffa01.w" instruction should take about 2+4=6 cycles
(ignoring head/tail).  That's about 0.18 microseconds at 32MHz, which
corresponds with my measurements when accessing RAM.

> Also, you don't tell the cpu freq in those cases ? It seems TT is 32 MHz
> against 16 MHz for falcon ?
>
That's right.

> As wait state are required to have the cpu/bus clock in sync with the
> mfp clock, it's quite possible cpu accesses to mfp are slown down by the
> mfp clock, even if you have a faster cpu, which would explain that
> falcon and tt have approx the same timing in the end despite different
> cpu clock. It could be a different values than 4 cycles, but so far only
> some timing critical demos for 68000 ST are requiring correct cycles
> when accessing MFP, so the value used is the one for STF.
>
OK, that means about 12 cycles of wait state for the Falcon, about 24 cycles
for the TT.  Thanks for the explanation.

Roger