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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 07/06/2012 10:55, Uwe Seimet a écrit :
> Hi,
>
> > This code from my previous mail should do the same as bpl/bmi and works
> > under Hatari :
> >
> >       move.l #12000,d1
> > wait1:    tst.b $fffffa23
> >       bne wait1
> > wait2:    tst.b $fffffa23
> >       beq wait2
> >       subq.l #1,d1
> >       bne wait1
> >       illegal
>
> I see, but this is too risky. It depends on the code actually detecting
> a particular register value (0) instead of just checking the sign. Of
> course it is unlikely that the value 0 would appear too fast for the
> code to "see" it, but you never know ...
>
> Take care
>
> Uwe

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)

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.

So, if your code is able today to detect a very short transition for 
$ff, it should have no problem detecting a transition with a $0 in data reg.
Your "sign checking" approach can have 2 different results depending on 
the initial $fffa23 value.
I have the feeling you only see the safest case, but consider the case 
where $fffa23 starts with $18 for example, and you will see the bmi 
phase is much shorter than a beq phase.


Nicolas