** This is the quasi-official and semi-temporary T13 email list server. ** Hale L: > However, the Microsoft driver method would appear to be flawed and > not conform to the standard ... I didn't follow this criticism?. So long as the host includes all appropriate delays - in particular the 400ns delay for any write expected to flip DEV - the host remains free to poll whatever it wants to poll whenever it wants to poll it? > > Writing x1F6 Device/Head raises BSY as a side effect. > Please note that there is a BIG difference between writing the > Drive/Head register and changing the DEV bit value and writing the > Drive/Head register and not changing the DEV bit. I'll go ask my source whether we know if this makes a difference to the rude devices in question. ** This is the quasi-official and semi-temporary T13 email list server. ** On Fri, 4 May 2001 09:29:39 -0700, Eschmann, Michael K wrote: >Based on observation, most Microsoft drivers wait for busy to clear after >selecting the device and before writing the command (and rest of task file). >I know my drivers do this too. Please note that there is a BIG difference between writing the Drive/Head register and changing the DEV bit value and writing the Drive/Head register and not changing the DEV bit. This difference can be seen in the 'device selection' state diagrams vs. the 'command execution' state diagrams. The 'device selection' state diagram assume the DEV bit may be changing value and it requires the host to delay 400ns before accessing any of the device registers. The 'command execution' state diagrams say the host writes the command parameters into the registers, and that could include writing the Drive/Head register again. But in this case the host should not (shall not?) be changing the value of the DEV bit and no delay on the host side is required. Is this what is confusing some people? However, the Microsoft driver method would appear to be flawed and not conform to the standard. During device selection when the DEV is probably changing, polling for BSY=0 is of little or no value unless that polling is preceeded by that 400ns (or longer) delay. And no polling for BSY=0 is required if the Drive/Head register is being written to update the command parameters (when DEV is not changing value). *** Hale Landis *** [EMAIL PROTECTED] *** *** Niwot, CO USA *** www.ata-atapi.com *** -- If you have any questions or wish to unsubscribe send a message to Hale Landis, [EMAIL PROTECTED] To post to this list server send your message to [EMAIL PROTECTED] For questions concerning Thistle Grove Industries or TGI's list services please send email to [EMAIL PROTECTED] -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 7:33 AM To: [EMAIL PROTECTED] Subject: [temp t13] BSY spontaneously hi ** This is the quasi-official and semi-temporary T13 email list server. ** > (((... Thought number two...))) The discussion of trying to eliminate the check for either of x88 BSY|DRQ hi in x3F6 AlternateStatus before writing parameters and in particular before writing x1F7 Command did not reproduce all of my personal history of pain. I saw no discussion of the case where ... Writing x1F6 Device/Head raises BSY as a side effect. I hear this is popular among a significant population CompactFlash cards we can expect to stay in circulation for at least the next five years. I hear the device-side people were tempted into this evil by observing that both the Ansi texts and Microsoft either blindly wait for BSY|DRQ clear or else immediately write x1F7 Command after writing x1F6 Device/Head. When they wait blindly, everything eventually works. When they immediately write x1F7 Command, well, that's a write of x1F7 Command while BSY|DRQ set, which by and large quietly without notice cancels any command in progress and begins anew ... which in this case works. Pat LaVarre -- If you have any questions or wish to unsubscribe send a message to Hale Landis, [EMAIL PROTECTED] To post to this list server send your message to [EMAIL PROTECTED] For questions concerning Thistle Grove Industries or TGI's list services please send email to [EMAIL PROTECTED]
