| Re: [hatari-devel] Problem with SCSI initiator command register |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 07/06/2012 11:39, Uwe Seimet a écrit :
Hi,
As I told in my previous mail, this is much less risky to wait for 0
than to wait for $ff if $fffa23 was started with a> 0 data register.
In that case, the transition to $ff / bmi will be very brief (maybe 20
cpu cycles or less), while the transition to 0 should be a least longer
(depending on the divider in ctrl reg)
I'm sorry, but I cannot follow you on this point, because I don't wait for
$ff in particular, but any negative value will do. I.e. I don't wait for
the transition to a particular negative value, but any negative value.
Or maybe I am missing your point?
Yes, that the whole point of the discussion : if you don't set $fffa23
yourself, you can't be sure there will be negative value when reading it.
You're waiting with bmi, but if timer was started with $fffa23 = $18 for
example, the transitions when reading $fffa23 will be :
$18, $17, ..., $2, $1, $0, ($ff) (very brief), [timer loops], $18, $17,
$16, ...
As you can see all the value are >0 except one. So your bmi test has to
succeed in a very short time frame. You don't get <0 values half of the
time and >0 value on the other half.
What I mean is that your code could lead to bmi not being detected if
the initial data register in $fffa23 is< $80. And as you don't set this
value yourself, it could happen to have $fffa23< $80.
Yes, this is also a risk, I agree, but as I already indicated, if
someone changes the timer frequency the SCSI timing will be wrong in any
case, because the timer would run too fast or too slow. So from a
practical point of view, i.e. for a correct SCSI arbitration timing, any
timer manipulation will result in a wrong timing.
I don't understand "the timer will be too fast or too slow". You don't
set data reg yourself before doing the loop with bpl/bmi, yet you expect
the timer to be at a given speed ?
Do you mean you change $fffa23 later yourself ?
By the way I changed the sample program according to your suggestion,
using bne/beq, but it still hangs. So there is probably something else
that's still wrong, any idea? I get an endless loop here now, i.e. the
data register never seems to be 0:
wait1: tst.b $fffffa23
bne wait1
It appears to me as if Bxx simply does not work when being applied to
test the data register of timer C.
No, there is no specific behaviour between tst and mfp. Internally this
is a read from $fffa23, then a comparison, then a branch. Bxx is
completly working with any register. The problem could be when computing
what the value of $fffa23 should be a the time of the read (but there're
plenty working demos/games under Hatari that uses this, so this is
certainly a very rare case here)
Nicolas