X3T9.2/88-119




September 29, 1988

Ms. Caressa Williams
X3 Secretariat CBEMA
311 First Street, N.W., Suite 500
Washington, DC 20001-2178

Dear Ms. Williams,

Please register our comments on the ESDI dpANS (BSR X3.170-198X) 
which is currently in its first public review period.  Our four 
comments are as follows:


1.  Hard Sector PLO Sync Format Timing (8.3.6)

PROBLEM:

Currently for hard sector formatting, Alternative 2 is not 
required for High Speed Port operation.  Not requiring drives to 
also work with  Alternative 2 is too restrictive for controller 
manufacturers, especially those that currently implement only 
Alternative 2.  This requires that the controller be able to 
support two different format types because of the dissimilarity 
between Alternative 1 and soft sector formats.  Most current 
controllers can implement soft sector formatting by using 
Alternative 2 with only slight modifications.  Alternative 1  
requires a minimum transition of WRITE GATE of two bit times 
before the ID sync field.  Some existing controllers may have 
difficulty pulsing WRITE GATE for that short of time, especially 
at 24 MHz, thus introducing needless void areas into the format.  
Also, existing controllers that can run at 24 MHz but only 
implement Alternative 2 for hard sector formatting will have 
compatibility problems with new drives that implement only 
Alternative 1.

PROPOSED SOLUTION:

Require both Alternative 1 and Alternative 2 for High Speed Port 
operation as is required for Low Speed Port operation.  This 
would allow controllers to maintain compatibility between High 
Speed and Low Speed Port operation and allow existing controllers 
to use similar implementations for hard and soft sector 
formatting.




2.  READ GATE Window (7.7.1.4.1)

PROBLEM:

There is some uncertainty about what setting the READ GATE Window 
to zero means.  The current text states "If no window is required 
by the drive, it shall set this value to zero, indicating to the 
controller that the default value applies."  This could be 
wrongly interpreted as meaning that the 16 bit maximum applies 
when the READ GATE Window value is set to zero.

However, setting this value to zero actually means that there is 
no maximum time requirement for asserting READ GATE relative to 
the write splice.  READ GATE assertion after a write splice 
depends only then on guaranteeing that READ GATE is asserted at 
least the number of bytes defined by the drive prior to the ID or 
Data Sync Bytes.  In this case, the controller may pad the sync 
field with extra bytes to allow more time for decision making.

PROPOSED SOLUTION:

Change the wording to say, "If no window is required by the 
drive, it shall set this value to zero, indicating that READ GATE 
assertion time depends only on guaranteeing the minimum number of 
PLO Sync bytes."


3.  Command Complete after Head Switch (9.3.1.12 and 6.3.8.1)

PROBLEM:

Currently if the time required to switch heads is greater than 15 
usec. the drive must negate Command Complete within 15 usec. of 
the head switch and assert Command Complete when the head change 
has been performed.  If for some reason the drive normally 
switches heads in less than 15 usec. and only sometimes takes 
longer than 15 usec., the controller will have no way of knowing 
whether or not Command Complete will transition or not.  This 
results in lower than optimal controller performance because the 
controller must wait the full 15 usec. before checking for 
Command Complete, even if the drive switched heads in a 
significantly shorter amount of time.

PROPOSED SOLUTION:

Require that drives needing longer than 15 usec. deassert Command 
Complete within 5 usec. (or possibly less) of the head switch in 
order to give the controller a chance to see if the head switch 
has completed early. The controller could then proceed when 
Command Complete comes back on (provided that other requirements 
such as .7*ISG have been met) before the full 15 usec. time has 
elapsed.



4.  Transfer Rate (7.7.1.2)

PROBLEM:

Currently drives are required to return their transfer rate only 
if they support High Speed Port operation.  Some controllers 
exist which measure time intervals in absolute time instead of 
bit times.  These controllers need to know the exact transfer 
rate in order to optimally adjust their timing parameters.  Also, 
there appears to be a conflict in the definition of High Speed 
vs. Low Speed Port operation.  The text states in Section 
7.7.1.2, "If the drive does not support this command it has a low 
speed data port, and the data rate is determined from the General 
Configuration response settings."  This conflicts with the 
definition of the High Speed Data Port bit in subscript 1 of the 
General Configuration response and must be clarified.

PROPOSED SOLUTION:

Require that any drive which supports subscripting must return 
transfer rate information when requested by the controller, 
regardless of the transfer rate bit settings in the General 
Configuration Response and regardless of high-speed or low-speed 
port operation.  Remove the sentence that says, "If the drive 
does not support this command it has a low speed data port, and 
the data rate is determined from the General Configuration 
response settings." 


Sincerely,



Bret Weber and Tim Hoglund,  NCR Corporation




cc: Mr. Del Shoemaker, X3T9 Chairman
    Mr. John Lohmeyer, X3T9.2 Chairman
    Mr. Dal Allan, X3T9.2 Vice-Chaiman