Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!ginosko!uakari.primate.wisc.edu!xanth!mcnc!ecsvax.uncecs.edu!jrw
From: jrw@uncecs.edu (James R. White)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Interleaving with WD1006V-SR2?
Summary: Perhaps the HD BIOS needs to be shadowed.
	 Also, why an extra copy of the AMI BIOS is at E000:
Keywords: Disk controllers, interleaving, WD1006
Message-ID: <1989Oct10.022055.13435@uncecs.edu>
Date: 10 Oct 89 02:20:55 GMT
References: <2127@tutor.tut.fi>
Organization: UNC Educational Computing Service
Lines: 50

> I've been reading a lot of good words on the WD1006V lately.  However,
> I have a question about the interleave factor with this board.  I'm
> running a 386/AT clone (C&T chipset) with a WD1006V-SR2 and a Seagate
> 65MB disk.  The disk has been formatted using the on-board BIOS setup-
> routine (WD1006V-SR1/2 MR1/2 SETUP REV. 2.0).
>
> ...  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
> reported as 2:1 and xfer rates are the same as before.  Toggling the on-board
> cache enable/disable jumper has no detectable effect whatsoever.
> ...
> If you have any information that would explain these numbers, I would
> be most grateful to hear (read) it.

I believe HDTST determines the "interleave" from the transfer rate, not
from the actual interleave.

I have a 386 with AMI bios and C&T chips. I don't know anything about the
WD1006V-SR2, but I recently have had a similar experience with an XT
controller (OMTI5527). This is a RLL controller that is supposed to handle
a 1:1 interleave, but I was getting a very low transfer rate on my 386.
It turned out that the controller was using single-transfer DMA. (Does
the WD1006V-SR2 support demand transfer DMA?) While the transfer was
taking place, the 8-bit HD BIOS (at C800:) was sitting in a waiting
loop. The 386 asks for instructions using 32-bit fetches, which the
bus circuitry would turn into four 8-bit fetches to the HD BIOS chip.
No DMA is allowed while these fetches are occurring. Thus, between each
DMA access there were four EPROM fetches as well as the overhead of
switching to and from DMA mode. None of this would happen if my controller
used demand-transfer DMA (which it can't). Eventually I figured out
how to configure the C&T chips using IN/OUT instructions, and I
shadowed the HD BIOS. (I couldn't figure out how to do this using the
setup options.) This doubled the transfer rate.

Someone else wondered why there was a copy of the AMI BIOS at E000:.
I have found that with certain bits set in the setup the AMI BIOS will
create a shadow of the BIOS at E000: (for no good reason). If I write
enable the ram at E000: (by talking directly to the chips), then I find
that I can write to this memory. And if I tell the chips to disable
this memory, I don't see anything at these locations. (I see F3s when
there is nothing at a memory location that I am looking at.)

So I have written a little program called MYBOOT using turbo assembler
to do things like enable the mem at E000:, turn off Num-Lock on my kbd,
and shadow the HD BIOS at C800:. It also ties the memory at A000: into
the main block and links D000:,E000: into the MS-DOS allocation
structure. I put COMMAND.COM and my TSRs into this second lump so
as to have as big a primary lump as possible (I get 647840 bytes in
this block according to MEM).