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.
