|Re: [hatari-devel] Problem with SCSI initiator command register|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
> 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?
> 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.
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
It appears to me as if Bxx simply does not work when being applied to
test the data register of timer C.