Possibilities - How to Tame SCSI and EMS

Contact:   eSoft, Inc. (Makers of TBBS)
           15200 E. Girard Ave., Suite 3000
           Aurora, CO  80014
           (303) 699-6565      Voice
           (303) 699-6872      Fax
           (303) 699-8222      BBS
           support@esoft.com   E-Mail

HOW TO TAME SCSI AND EMS
------------------------

*** From March 1993 Possibilities Newsletter ***
*** Copyright 1993 by eSoft, Inc.  All Rights Reserved ***

How to Tame SCSI and EMS
by Alan Bryant

Recently, TBBS users who install new computers (or upgrade their current 
computers) have begun reporting strange behavior, ranging from occasional 
lock-ups to damaged disk files to total system failure.  Although such 
problems can be caused by many different system configuration factors 
external to TBBS, one of the most common causes we are seeing is a SCSI disk
controller which has not been properly installed for its operating 
environment.  If you own a SCSI disk controller, and operate it with TBBS, 
this article will be of particular interest whether you're currently having 
trouble with your system or not.

What's the problem?

Most SCSI disk controllers are "bus mastering" devices.  In order to provide 
performance beyond that normally attainable by the PC bus, these controllers 
handle their own direct memory access (DMA) instead of going through the 
standard DMA facilities on the computer's motherboard. Indeed, SCSI disk 
controllers are generally known for their high drive capacities and high 
performance and that's why so many TBBS sysops are installing them.

The same design that provides this increased speed, however, is incompatible 
with the most common operating mode of the 386 or 486 microprocessor -- the 
so-called "virtual 86" mode -- which allows the 386 or 486 to remain DOS 
compatible and also provide EMS memory capability.  We should note that SCSI 
disk controllers are not the only bus mastering devices available, just the 
most common.  Some LAN adapter cards and some ESDI disk controllers are also 
bus mastering devices.

Bus mastering devices are potentially incompatible because they handle their 
own DMA accesses.  This means that the controller puts data directly into 
certain portions of the computer's memory and expects that it will remain 
there unchanged.  This is often not the case, however, with a memory manager 
installed (such as QEMM, 386Max, or the DOS 5.0 utilities HIMEM.SYS and 
EMM386.EXE).

Memory managers live up to their name -- they manage memory, and they 
typically expect to be managing ALL available memory on the PC.  It is this 
assumption which allows a memory manager to perform its array of tricks, 
including providing EMS (expanded) memory for TBBS' use.  When both a memory 
manager and a bus mastering device are expecting to deal with the same 
memory directly, however, there are inevitable conflicts.  These conflicts 
show themselves rather colorfully in typical TBBS installations which use 
EMS memory extensively.  Lock-ups, damaged files, line-to-line "bleedover," 
and TBBS simply not running are all ways that these conflicts can present 
themselves to you.

Why do these problems seem to be caused by TBBS itself?  The answer is that 
TBBS does disk I/O directly to EMS memory.  EMS is provided by the memory 
manager via a "page frame" which resides in upper memory blocks (UMBs) -- 
memory which may be accessed by the bus mastering device.  It's entirely 
possible that your PC will operate normally until you load TBBS.  TBBS 
itself is not the problem -- it just causes a pre-existing conflict to show 
itself by the way it uses EMS memory.

Correcting the problem...

Generally, it's best to correct this problem BEFORE it starts.  But whether 
you're having it now, or may have it in the future, the solutions are the 
same.  These are several ways to go about it:

Solution 1

The BEST solution is to obtain and install a VDS compliant driver.  VDS, or 
Virtual DMA Services, is a software specification which is supported by all 
major memory managers (including the DOS 5.0 EMM386.SYS).  It provides a way 
for a bus mastering device, like a SCSI disk controller, to "talk" to the 
memory manager and thereby resolve memory conflicts of this sort entirely.

In order for this to work, however, you must have a VDS compliant driver for 
the bus mastering SCSI controller.  Thankfully, VDS compliant drivers are 
available from the manufacturers of most SCSI disk controllers.  In fact, if 
you have installed drivers for your SCSI controller already, those drivers 
may be VDS compliant.  Check your manual, or contact the manufacturer to 
know for sure.

NOTE:  Often your controller is NOT supplied with the necessary drivers, and 
you will need to contact the manufacturer for information on obtaining what 
you need.  Further, some manufacturers do NOT have drivers available.  If 
your manufacturer does not have the necessary drivers, you may be able to 
buy them separately from a third party.  (On example is Micro Design 
International.  They sell VDS compliant drivers for a variety of bus 
mastering SCSI disk controllers from several manufacturers.  Contact them at 
(407) 677-8333.  TRY THE MANUFACTURER OF YOUR CONTROLLER FIRST!)

CAUTION!! If you load a VDS compliant driver high, then you may prevent it 
from being able to resolve the memory conflicts.  eSoft does not recommend 
loading any device drivers into UMBs (LOAD HIGH) in a TBBS environment for 
this exact reason.  If you want to load your device driver high, first 
install it without loading high and verify that your TBBS installation works 
properly.  Only then try loading it high, and if you start getting failures 
you know the cause.  There is no guarantee that you can load your device 
driver high had have it work in all cases.  See solution 4 for the last, 
best, hope if you have problems loading the driver high.

Solution 2

Some bus mastering devices can be configured to use the BIOS or a standard 
DMA "channel" for memory accesses.  Check the documentation for your 
controller (or other bus mastering device) and see if you have these 
configuration options.  The memory manager can accommodate these methods and 
compensate for conflicts, and the performance loss from this option is 
small, and is not usually noticable.

Solution 3

If you have non-VDS drivers for your controller, there may be command line 
options for them that enable certain types of buffering options.  Consult 
the manual for your controller, or contact its manufacturer.  Although this 
is not VDS support, these buffering options often can alleviate the problem 
by adjusting how the controller handles its DMA.  If you use this solution, 
make sure you DO NOT load the driver into UMBs (load high) because the 
problem will persist.

Solution 4

If you're using the QEMM memory manager, and you are using version 5.0 or 
higher, you can use the DISKBUF=x command line option for QEMM.  This MAY 
prevent the memory conflicts (but you CANNOT be assured that it will).  To 
try this option, add the following to your QEMM command line (in 
CONFIG.SYS):

DISKBUF=2

If the conflict cannot be resolved with this option, the setting of 
DISKBUF=x will not matter.  However, if it does resolve the problem, you may 
also get better SCSI hard disk performance by increasing the value to 
DISKBUF=10.

Note that you may also need to use DISKBUF= if you have a VDS compliant 
driver loaded, but you have loaded that driver into UMBs (load high). 

Summary

SCSI hard disk controllers (and other types of bus mastering devices) are 
becoming commonplace because they provide high performance.  Although not 
caused by TBBS in any fashion, the memory conflicts that can easily result 
from their use can render your TBBS system unusable.  Knowing about the 
issues these controllers present and how to compensate for them is criticial 
to ensuring the stability and reliability of your TBBS installation. 

- END -
PS0393-4
Rev. 3/93

Copyright (C) 1994 eSoft, Inc., All Rights Reserved.  Permission granted
to distribute this file in its entirety, without modification, to any
interested party.  Any other use requires the written permission of
eSoft, Inc.

IMPORTANT:  The information herein is subject to change without notice.
Please call or write to confirm factual information of importance to you
or your organization.

