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