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

[ Thread Index | Date Index | More Archives ]

Le 07/06/2012 10:36, Uwe Seimet a écrit :

I didn't follow the whole discussion on SCSI, but what does this
transition in fffa23 helps to measure for SCSI ? Could you describe the
logic behind it to better understand what could be missing in Hatari ?

At the core it's not SCSI-specific. I just need this code in order to
check for timeouts.

Also, relying on "standard" values after a reset seems dangerous to me,
a program running before yours could completly change those values or
even set the control register to 0 and the counter would never
decrement. Or maybe some TOS/Emutos versions would not start control
register in the way you expect it.

Yes, but in this case HDDRIVER would not work anymore anyway. I have to
rely on the timer in order to be SCSI-compliant as far as timeouts
during the arbitration phase are concerned, and with the code I am using I
can at least avoid a deadlock if somebody disables the timer interrupt.
And I cannot simply use the timers for my own purposes, this would
interfere with other applications.
If the timer does not run at all HDDRIVER is not able to drive the SCSI
bus. But this has never been a problem for the last 20 years, so I guess
it also won't be a problem in the future ;-).

Take care

So this test is just to ensure there's a working mfp in the host machine ?

In that case, I think using the bne/beq variation in my previous mail should at least unlock the situation under Hatari (with no side effect on real ST) while waiting for a better fix for this very rare mfp transition.


Mail converted by MHonArc 2.6.19+