Re: [hatari-devel] MFP timing

[ Thread Index | Date Index | More Archives ]

On 30/08/2013 17:58, Roger Burrows wrote:
The TOS ACSI routines use 'tst.b $fffffa01' as part of a short-delay routine.
I remember reading somewhere a long time ago that this was supposed to give a 1
microsecond delay on all machines.

I'm implementing the equivalent delay in the EmuTOS ACSI routines (by a
different method), so I thought I should verify my vague memory.  I did some
timing tests on various machines, with accesses to $1000 (arbitrary) and to
$fffffa01.  This is what I found (all times in microseconds and probably
accurate to about 10%):
                      ST       Falcon      TT
tst.b $1000         1.6        0.36      0.17
tst.b $fffffa01     2.0        1.1       1.0

The timings for the first line are about what I would expect from the timing
tables in the appropriate manuals.  The second line *almost* corresponds to my
vague memory.

1. Can anyone here confirm (or refute) these findings?
2. I found a place in the Hatari code where extra wait states are added for
access to the MFP.  It adds 4 cycles, which seems fine for the ST but not for
the other machines.  Am I missing something?

Roger Burrows


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.

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.

Someone with better HW knowledge could certainly explain this better than me by looking at the clocks' schematic.

In the end, I don't know if this is reliable to get a constant delay for any cpu / atari model. If possible, you could as well start a real mfp timer with divider=1 and a low data value. By reading the timer's data register until it reaches 1 for example, you should get accurate timings for some small amounts of cycles (you don't need to enable the timer to produce interrupts, just start it with mask=0)


Mail converted by MHonArc 2.6.19+