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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/