Re: [hatari-devel] Problem with SCSI initiator command register

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

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?

> 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
       bne wait1

It appears to me as if Bxx simply does not work when being applied to
test the data register of timer C.

Cheers

Uwe