This message is from the T13 list server.
When the host reads from the Data register it is actually reading from a FIFO, each time the register is read new data appears at the output of the FIFO. Thus I don't think getting a specific value anytime the Data register is read when BSY is cleared to zero is practical. However, I do think the making a set of values in the Data register as part of the signature that is placed in the registers at the completion of a Power-on, hardware or software reset or at the completion of an EXECUTE DIAGNOSTIC command is possible. That is, the first time the Data register is read after those events values indicate "I'm Device 0 and there is no Device 1", "I'm Device 0 and Device 1 exists" or I'm Device 1". Device 0 shall not respond to a read of the Data register when Device 1 is selected. It seems this will give the host a quick and simple means of determining what's there without causing problems for existing software. Regards, Pete > -----Original Message----- > From: Eschmann, Michael K [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 08, 2002 1:31 PM > To: T13 List Server > Subject: RE: [t13] going beyond e00160 > > > This message is from the T13 list server. > > > Hale, > > What would be the scope of the drive responding with a data > value of 0x33cc > or 0xcc33? Does this happen only if the data read > immediately follows the > writing of the device/head register, or is this going to > happen all the > time? > > As for the cycle counting problem, how feasible would it be > for the device > to make the number of words transferred available after data transfer > completes? This could be accomplished through a read of a > device register > that is undefined at completion of data transfers? The > sector count is open > for errors, so a transferred sector count could be sent. > Drive folks, how > feasible is this? A single bit in status (for example, bit 1) could > indicate any data versus no data was transferred. > > Regards, MKE. > > > -----Original Message----- > From: Hale Landis [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 06, 2002 8:41 AM > To: T13 List Server > Subject: [t13] going beyond e00160 > > > This message is from the T13 list server. > > > There are many things in the ATA/ATAPI interface that need to be > addressed in order to fix all the data integrity problems. Here > several including a solution or two... > > A) Which device is selected? > > Today there is no positive feedback to tell a host that the most > recent write to the DeviceHead register was acted upon correctly. I > propose the following, which BTW, solves the device old question of > how many devices are there? > > At all times a device has BSY=0 and DRQ=0 the device shall respond to > a read of the Data register as follows: Device 0 shall respond with > the data value 0x33cc and device 1 shall response with the data value > 0xcc33. Device 0 shall respond with the data value 0x33cc even when > there is no device 1 and device 0 is responding for device 1. If a > CFA device is in 8-bit data transfer mode then only the upper 8-bits > of these values are returned (device 0 returns 0x33 and device 1 > returns 0xcc). > > B) How does the host know it read valid data? > > As a said in my previous email about e00160, e00160 does not provide > the host with a way to know if data read from the device registers > (not including DRQ data bursts) is valid. This is very important for > reads of the Status or Alternate Status and for any values returned > by commands in the ATA Command Block registers (such as the failing > sector address when a Flush Cache command fails). > > I don't have a quick solution for this problem but perhaps... a) some > CRC computed by the device over all the device registers whenever the > device has BSY=0 DRQ=0, or b) ??? (any ideas out there?). > > C) I know there are more of these areas that need to be fixed... > > > > *** Hale Landis *** www.ata-atapi.com *** > > > > Subscribe/Unsubscribe instructions can be found at www.t13.org. >
