Path: utzoo!attcan!utgpu!watmath!att!rutgers!texbell!merch!cpe!adaptex!neese
From: neese@adaptex.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: SCSI Controllers & disks
Message-ID: <6100031@adaptex>
Date: 15 Nov 89 19:32:00 GMT
References: <311@km4ba.UUCP>
Lines: 58
Nf-ID: #R:km4ba.UUCP:311:adaptex:6100031:000:3029
Nf-From: adaptex.UUCP!neese    Nov 15 13:32:00 1989


>>
>>The Adaptec 1542 looks like the [SCSI] contoller to have!
>>
>The 1542(A) (and others, such as the WD, as far as I know) have a
>problem, in their current implementation, working together with
>386^MAX (from Qualitas).  In short, they DON'T work together.
>
>The technical support folks at Qualitas they are aware of the
>problem but that it has to be solved in the SCSI controller's BIOS
>routines.  Something about properly identifying some buffer meory or
>something used by the controller that conflicts with whtat 386^MAX
>is trying to do.

The problem is the 1542 and WD7000 are bus masters and as such require
physical addresses be passed in the INT13 call.  With the 386 in virtual
mode this can't happen.  A dirty fix for Windows 386 was to do a driver
that allocated an amount of memory as a buffer.  The driver would then
intercept the INT13 call and pass the address of the buffer to the 1540
and then when the command completed, move the data from the buffer to
the funny address via a move string instruction.  This works okay with
Windows as Windows doesn't move the lower 640K of memory around, so the
logical address in the lower 640K is also the physical address.  This is
not the case with 386^MAX.  It moves everything around and thus the driver
has no physical address to use.  There is absolutely nothing that can be done
in the BIOS of the 1540 and the WD7000 to correct this.  There are two
ways to correct this problem.  One is the application could be made to pass
a physical address to the adapter BIOS.  This is fairly trivial for the
application to do this as it has full access to the 386 page registers.
BIOS's do not have privilege to these registers.  The other way is to
standardize on a call that a BIOS might make that would return a physical
address.  There is currently a move in this direction, but I don't know the
status of this.

>I've called the Adaptec SCSI guru a couple of times, leaving
>messages for a return call, but so far no response.  I'll update
>this note when/IF I find out anything.

My calls are all screened.  If you are not a OEM or distributor in my
region, then I cannot return a call, and probably won't even get the
message.  I worked this deal out with my boss.  I can respond to the
net and can E-mail as well, but I cannot accept calls from those that
I do not have responsibility for.  I already get up to 60 calls a day
from the people I am responsible for.  I do not want to sound like a
horse's-ass, but I don't make the rules.

>Bottom line: I still use the 1542A, but I'm switching from 386^MAX
>to a slightly different scheme, using VM/386, and I'll set up one
>virtual machine to do the networking (the reason for needing 386^MAX
>in the first place is the ungodly amount of memory PC-NFS hogs).

Be sure to ask the VM386 folks if they have gotten the support for the
1542.  They were working on it last I had heard.  

			Roy Neese
			Adaptec Central Field Applications Engineer
			UUCP @ {texbell,attctc}!cpe!adaptex!neese
				merch!adaptex!neese