|Re: [hatari-devel] MFP timing|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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 ?
> 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.