Category : Alternate Operating Systems - Quarterdeck DesqView, CP/M, etc
Archive   : QWHITE13.ZIP
Filename : BUS-MAST.TEC

Output of file : BUS-MAST.TEC contained in archive : QWHITE13.ZIP

ID:BU QEMM-386: Using Bus-Mastering Devices
Quarterdeck Technical Note #121 Filename: BUS-MAST.TEC
by Quarterdeck Technical Support CompuServe: BUSMAS.TEC
Last revised: 10/27/92 Category: HW

Subject: Notes on bus-mastering devices and why they may require a Virtual DMA
Services (VDS) driver on 386/486 machines in Virtual 8086 mode.
Owners of SCSI hard drives should read this note.


Q: What is a bus-mastering device and what problems might be seen when
using one?

Bus-mastering devices are ones which do their own direct memory addressing
(DMA) without going through the machine's processor or its DMA controller.
The most common bus-mastering devices we see currently are SCSI hard disk
controllers, but, technically, other types of devices could be bus-mastering
as well. We have seen bus-mastering ESDI disk controllers and an increasing
number of bus-mastering network cards as well. The problem seen with bus-
mastering devices is that while they are high-performance devices and quite
often found on 386 and 486 machines, they are unfortunately, in their design,
incompatible with one of the most common operating modes of the 80386 and i486
processors -- the Virtual 86 mode.

Specifically, the problem is that the device puts data into absolute memory
addresses and assumes that the contents of those memory addresses will always
remain constant. However, on a 386 machine with the processor in Virtual 86
mode, this can often be an incorrect assumption. When QEMM-386 is providing
High RAM, it is typically associating PHYSICAL memory with unused LOGICAL
addresses. When a bus-mastering device refers to data, it presumes that
physical and logical addresses are the same. In Virtual 86 mode, the same
logical memory addresses can, at any given moment hold different data from
various regions of physical memory, depending on which virtual machine is

If you are using a bus-mastering device on a 386 or 486 that is in Virtual 86
mode and memory paging is occurring (when QEMM-386 is providing High RAM, when
QEMM-386 is providing expanded memory, or when the processor is switching from
one virtual machine to another), your machine will probably hang when you use
the bus-mastering device.

Quarterdeck first became aware of the problem from customers who had bus-
mastering SCSI hard disk controllers. Users reported that they could boot
their machines, start our multitasking DESQview software and as long as they
ran only one application, their system ran fine. As soon as they opened a
second application, the system would hang. The problem was also seen by users
who were not using DESQview, but who were using the LOADHI feature of QEMM-

In this case, the hang occurred because the disk controller would prepare to
load some absolute memory addresses with data pertaining to an application
that was running, but by the time the data was actually transferred to these
addresses, QEMM-386 had switched the memory map. Those absolute memory
addresses no longer belonged to the application which could process the data.
They belonged instead to some other application or process. In theory, this
could have caused data corruption, but in reality it never did. The memory
corruption was typically so extensive that the systems simply hung as soon as
a change in the memory map occurred. Other 386 memory managers would exhibit
exactly the same symptoms. The problem mentioned here is also a problem for
Microsoft's "Windows" version 3, when Windows is in Enhanced Mode. Worse,
since QEMM-386 is almost completely disabled when you enter Enhanced Mode, any
solutions to the problem which depend on QEMM-386's memory management may

See the reference to SMARTDRV in item 4, below.

Q: How can the problem with running Bus-mastering devices in Virtual 86
mode be corrected?

There are four possible solutions:

1) THE BEST SOLUTION: Contact the maker of your bus-mastering device and see
if they have a driver available which supports the VDS (Virtual DMA Services)
specification. VDS is now an industry-wide specification supported by IBM,
Microsoft and Quarterdeck, as well as many other hardware and software
suppliers. A VDS driver allows a bus-mastering device to find the real
physical address of its data when the processor is in Virtual 86 mode.

QEMM 5.00 (and later versions) supports the VDS specification. A VDS driver
provides the best solution to this problem in terms of reliability, speed and
memory efficiency. A VDS driver may be loaded into High RAM if it appears in
the CONFIG.SYS file after the QEMM386.SYS line; you may need a DB=1 parameter
on the QEMM386.SYS line to accomplish this; see section 5 below.

2) Similarly, the drivers of many bus-mastering hard disks have proprietary
buffering options. Check the documentation for your disk controller to see if
the driver has a parameter to set up buffering for disk operations. Some
drivers will also document parameters that are specific to 386 operations. For
example, the early Adaptec drivers SCSIHA.SYS and AHA1540.SYS included both
386 and disk buffering options invoked by the parameters "/v386" and "/b:64."
"/v386" stands for virtual 386; "/b:64" allocates a 64k buffer, for DMA.

Unlike the drivers in (1) above, these drivers do not provide VDS services. If
you are using a driver such as this, make sure that it is not loaded high. The
purpose of such a driver is to provide buffering into physical addresses that
are the same as logical addresses; if the program is loaded high, its buffer
will be in logical addresses that are not the same as their physical
addresses. Please read the section below titled "Making Sure Your Device
Driver Loads Low".

3) Check the documentation for your bus-mastering device and see if it can be
configured to use the BIOS or any one of the standard DMA channels. QEMM-386
can correct the problem if the BIOS or standard DMA channels are used.

4) As mentioned above, bus-mastering hard drives can also cause problems for
Microsoft Windows 3. Microsoft's solution is in its SmartDrive disk cache.
SMARTDRV (and other disk caches) contain code that can buffer direct memory
access. Since QEMM-386 and its VDS services are almost completely disabled
when you enter Enhanced mode, this is a good thing. If you have a bus-
mastering disk controller and wish to run Microsoft's "Windows" program in
Enhanced mode while loading any programs high, you must use SmartDrive.

a) As of this writing, Microsoft Windows 3.1 provides you with a copy of
SmartDrive v. 4.0. This has two functions: it provides disk caching, through
a module loaded in AUTOEXEC.BAT, and it provides buffering for SCSI hard
drives, through a module loaded in CONFIG.SYS. If you are using Windows 3.1,
and a bus-mastering hard drive, and you are not using any of the options
numbered 1 through 3 above, make sure that the following line appears in

device=c:\windows\smartdrv.exe /double_buffer

(If your path to SmartDrive differs, change c:\windows above to the
appropriate path.)

Please read the section below titled "Making Sure Your Device Driver Loads

b) Windows 3.0 and DOS 5 shipped with SmartDrive version 3 or lower. If
you are using one of these versions of SmartDrive, make sure that the
following line appears in your CONFIG.SYS file:


(If your path to SmartDrive differs, change c:\windows above to the
appropriate path.)

Please read the section below titled "Making Sure Your Device Driver Loads

5) QEMM-386 5.00 (and later versions) has a DB=xx (DISKBUF=xx) parameter which
should prevent QEMM-SCSI problems at the expense of a little conventional
memory. "xx" is the number of K used for buffering. Any value for xx is
sufficient to correct the problem. DISKBUF=2 would be fine for most cases.
Higher numbers, -- up to 10 or so -- may improve performance. Setting DISKBUF
to more than 10 is probably a waste of memory. This approach will not work in
cases where the bus-mastering device is something other than a hard disk. If
your bus-mastering device is something other than a hard disk the solutions
above, especially #1, are your only options.

QEMM-386's DB= parameter can also be used to buffer DMA by bus-mastering
devices until a VDS driver is loaded; this allows you to load a VDS driver
into High RAM. Place the VDS driver after the QEMM386.SYS line in CONFIG.SYS,
and run the OPTIMIZE program.


Q. I've read the sections above. I don't have a VDS driver, and I think
that my proprietary device driver or my disk cache should be loaded
low. How do I prevent it from loading high?

For double-buffering to work properly, the device driver for your bus-
mastering hardware must be loaded in conventional memory, where physical and
logical addresses are almost always the same. You must therefore make sure
that it loads low if you are depending on it to provide DMA buffering. We will
use SMARTDRV as an example of such a program; change the instructions below to
fit your device driver.

Ensure that there is no LOADHI command preceding SMARTDRV on the line which
loads it.

OPTIMIZE will very likely try to load SmartDrive high, unless you tell
OPTIMIZE not to do so. This is most easily done in the following way:

1) Using a text editor, create a text file called OPTIMIZE.EXC in the QEMM
directory. Note that EXC (not EXE) is the extension on the file name. If
such a file exists already, simply open it for editing.

2) Put a line in OPTIMIZE.EXC that says:


Do not specify a pathname nor an extension to the file name.

3) From now on, OPTIMIZE will not affect the SMARTDRV line in either
CONFIG.SYS or AUTOEXEC.BAT. As long as SMARTDRV is not being loaded
high already, it will not load high.


Q: I know I have a bus-mastering device on my computer, but I haven't seen
any problem. Why not?

It's possible that your bus-mastering device uses a standard DMA channel for
DMA operations. QEMM-386 can correct the problem when standard DMA channels
are used.

It is quite possible that your bus-mastering device was shipped with a VDS
driver. Bus-mastering hard disk controllers are starting to ship with drivers
that make VDS calls, and these drivers do not require the DB parameter or any
other buffering. We expect that most bus-mastering devices will eventually
include VDS drivers and therefore will not exhibit any problems when run in
Virtual 86 mode.

*This technical note may be copied and distributed freely as long as it*
*is distributed in its entirety and it is not distributed for profit. *
* Copyright (C) 1990-2 by Quarterdeck Office Systems *
************************ E N D O F F I L E *************************