This message is from the T13 list server.
[ BC [EMAIL PROTECTED];[EMAIL PROTECTED];[EMAIL PROTECTED] ]
Agreed waiting for INTRQ before sampling the task file is part of the TalkLikeWindows
rule of interoperability.
Agreed waiting for x3F6 & x10 DSC to go hi again will make some old devices behave
better - Windows does this after Atapi op x2B Seek's.
You might also want then to look for all of BSY DRQ ERR C/D I/O = 0 0 0 status in. If
in fact you see something else, then you know you've got trouble. Exactly what kind
of trouble is hard to say: the Scsi analogue to this is "unexpectedly bus free" if BSY
= DRQ = 0, else "phase error". The only cause I've seen produce this kind of trouble
intermittently is an asynchronous and separate power cycle of the device.
Pat LaVarre
-----Original Message-----
From: Harlan Andrews [mailto:[EMAIL PROTECTED]]
Sent: Thu 4/25/2002 5:52 PM
To: Hale Landis; [EMAIL PROTECTED]; Gilles Mollié
Cc:
Subject: Re: [t13] ATAPI "naive" question
This message is from the T13 list server.
On 4/25/02, Hale Landis <[EMAIL PROTECTED]> wrote:
>....
>As soon as the device has status of BSY=0 DRQ=0 the command is
>completed at the interface, the actual writing to the media may not
>be done yet but that doesn't matter, the device is ready to receive
>the next command from the host.
>....
You might also want to wait for INTRQ. Some devices get unhappy if you
send the next command before INTRQ has been sent. Most operating
systems wait for the interrupt by default. But if you have some embedded
application or low level control of the registers then it's best to wait
for INTRQ ( or the bit in the host interface chip which indicates that
INTRQ was received ).
Actually, if the op sys doesn't already do it for you, it might be wise
to check INTRQ ( either the actual interrupt or the interface chip
register bit) BEFORE reading ALT STATUS to check for completion.
...Harlan
