WD1006V-SR2: Interleave factor + an inexpensive source

Tuomi Jyrki Juhani jt19840 at tut.fi
Sat Oct 14 04:54:36 AEST 1989

About a week ago, I posted a query in comp.sys.ibm.pc about setting the
optimum interleave factor with WD1006V-SR2 ctrl.  My query was probably
too much system specific, as there has been only one reply (by James White,
jrw at uncecs.edu), which was most informative even though my problem wasn't
directly related to ROM shadowing as he suggested.  Anyway,
I have solved my "problem", and I'll post my experiences here, in case
someone may find this useful.

BTW, I bought my WD1006V-SR2 from Express Micro Mart (in USA, tel 1-800-
533-0177).  They had an ad in August 1989 issue of PC Magazine, where
the 1006V-SR2 was priced $146.  By the time of order (end of August) they
had dropped the price to $136!  Homesmart Computing (800-627-6998) seems
to be selling the same board for $129.  Pretty cheap, considering that some
ads list the WD1006V-SR2 for about $210!

In article <2127 at tutor.tut.fi> I wrote:
>65MB disk.  The disk has been formatted using the on-board BIOS setup-
>routine (WD1006V-SR1/2 MR1/2 SETUP REV. 2.0).  Spintest reports a
>transfer rate of 399 360 BYTES/s with 2 revolutions/track, i.e.
>interleave 2:1.  CORETEST 2.8 reports a transfer rate of 437 to 438
>Kbytes/s.  HDTST128 reports an interleave of 2:1.  I have done a non-
>destructive re-format (using HDTST128) to change the interleave to 1:1.
>However, when I check the interleave after re-formatting, it is still
>2:1 and xfer rates are the same as before.  Toggling the on-board cache
>enable/disable has no detectable effect whatsoever.

So, I became more and more suspicious about the reposted 2:1 interleave
factor, as the xfer rate measured by CORETEST is M O R E than theoretical
maximum rate achievable using 26 sectors/track formatting.

This was confirmed in <1989Oct10.022055.13435 at uncecs.edu> by James White:
>I believe HDTST determines the "interleave" from the transfer rate, not
>from the actual interleave.

Then, the disk must have been formatted to 1:1 interleave, but the data
wasn't moving with the speed it should (438 KB/s isn't bad at all, but I knew
that more - upto 790 KB/s - could be expected).

My next guess was that problem was with the motherboard,
as the only (?) reason that the problem was with the disk drive, would
have been that it wasn't spinning at proper speed, and I felt that to
be a little far-fetched.  I have a C&T-based 386/AT-motherboard (a Taiwanese
clone), so I started checking what was stored in 82C301 bus controller
configuration registers.  I was somewhat amazed to find out that the
AT bus was running at an extremely conservative 1/3 of processor clock
rate, i.e. 5.33 MHz!  A four line assembly program with DEBUG changed
the AT bus speed to 8 MHz (1/2 of processor clock rate), and CORETEST
told that disk data xfer rate had risen to 622 KB/s.  Some further checking
revealed that 2 wait states were specified for every 16-bit AT bus transfer.
After that was changed to 0 ws, the xfer rate was upto 737 KB/s!
I'll settle for that...

Very crude measurements indicate that copying a file to null device (dos
COPY command) yields about 500 KB/s xfer rate.

Jyrki Tuomi
Tampere University of Technology, Finland
Internet:  jt19840 at tut.fi    UUCP:  ..mcvax!tut!jt19840

More information about the Comp.unix.i386 mailing list