UMB_DRVR.DOC       Version 5.22             02/20/92             Page 1


                      UMB_DRVR.SYS Device Driver
           UMB provider for DOS 5.0 on 286 / 386 / 486 systems
              Copyright (C) 1991, 1992 All Rights Reserved

     Christopher Blum          CompuServe: 76625,1041
     1022 East Wayne Avenue      INTERNET: 76625.1041@compuserve.com
     Wooster, Ohio 44691              BIX: cblum
     (216)262-3786


IMPORTANT INFORMATION - DISTRIBUTION AND LICENSING


     UMB_DRVR.SYS carries no warranties expressed or implied.  It is
solely up to the user to determine its suitability for use on his/her
machine.
     This program is distributed as a self-extracting file containing
the device driver and its associated documentation. Copying and
redistribution is encouraged, but must be the original, unmodified
file containing this documentation, and the transfer must not carry
any fee or charge specific to this program: i.e. general BBS access
or line charges are OK, but no 'download fee' or similar charge. This
means that BBS operators may post this file for download, but may not
charge a specific fee for it, and 'Distribution houses' may charge a
disk-duplication fee, but not a specific charge for the program.
     UMB_DRVR.SYS is made available on a 'try before you buy' basis.
It is not crippled in any way, and has no 'advertising'. The latest
version will be available on CompuServe in the IBM forum ( 'GO IBMSYS',
lib 1 ).
     Personal use license ( U.S. funds ) is $25 which should be mailed
to the above address if the program is used after a reasonable trial
period ( 30 days ). Please use the registration form at the end of this
document. Users who register receive the latest version of the program,
and may at any time send a self-addressed *and postpaid* diskette mailer
and a diskette to receive further updated versions.
     Corporate users must contact me for corporate rate or site license
arrangements.


TECHNICAL SUPPORT


     Technical support, including pre-registration questions or install
assistance, is available at your expense at the above telephone number.
Please be aware that I am in the Eastern US time zone ( GMT-4 or GMT-5
depending on season ) and try to call at a reasonable hour: i.e. 9 AM to
Noon, 1 PM to 5PM, or 7 PM to 10 PM. Saturday is OK, but *PLEASE* avoid
Sundays. I can also be contacted via Email on CompuServe, BIX and
INTERNET ( IDs above ) - I monitor my mail almost every day. It is not
necessarily a good idea to leave me messages on CompuServe in the forum
sections unless your question or discussion is of general interest. The
Postal Service may also be used ( address above ).
UMB_DRVR.DOC       Version 5.22             02/20/92             Page 2


INTRODUCTION


     To start with, some definitions are in order. Hex addresses are
given in full hex notation as opposed to Intel segment:offset form,
i.e. A0000 in full hex is the same as A000:0 in seg:off form. The
memory sizes are referred to in Kilobytes ( 1,024 decimal ), Megabytes
( 1,048,576 decimal ), and Gigabytes ( 1,073,741,824 decimal ).

BASE MEMORY - Ram available to DOS and programs from location 0 to
  640K-1 ( 9FFFF hex ). All programs have access to this area.

UPPER MEMORY - The area between 640K ( A0000 ) and 1M-1 ( FFFFF ). This
  is the area where roms on expansion cards reside ( usually ), where
  the EMS base area ( the 'window' into EMS memory ) is ( usually ), and
  where Upper Memory Blocks ( UMBs ) are created for loading device
  drivers, programs, etc. 'high' with the DOS 5 'DEVICEHIGH' and
  'LOADHIGH' commands. DOS does not create UMBs itself, but rather
  relies on a program called a 'UMB provider' to supply them. DOS then
  manages the upper memory area as an extention of base memory with
  special characteristics when you use the 'DOS=xxxx,UMB' command.
  Programs like UMB_DRVR, QEMM, 386^MAX, and others are UMB providers.

HIGH MEMORY AREA ( HMA ) - The HMA is memory from 1M ( 100000 ) to
  1M+64K-16 ( 10FFF0 ), i.e. the first 64K-16 bytes of extended memory.
  It can be accessed on 286 and up cpus in real mode because the address
  calculation logic does not wrap to location 0 from FFFFF, allowing a
  program to use the segment 'FFFF' to access memory up to 10FFF0. On
  the earlier 8088 and 8086 processors, the wrap to location 0 was used
  by some software. To maintain compatibility, system designers have
  included a way to make the newer cpus act like the older ones. It is
  a 'gate' that can allow the cpu's address line 20 ( A20 ) to be held
  to 0 ( emulating the behavior of the older cpus ), or to be passed
  through. With DOS 5, use of the HMA must be through a program which
  controls access to it by opening this gate for times the HMA must be
  accessed and closing it so that other programs cannot accidently get
  at the HMA. The DOS 5 program which performs this function is the
  device driver 'HIMEM.SYS'. Other programs such as QEMM, 386^MAX et.al.
  also provide this function. The HMA is managed as a total unit, i.e.
  only one program 'owns' it, and 'owns' it all. This is where most of
  DOS is placed when you use HIMEM.SYS and the 'DOS=HIGH' command. As
  stated before, when DOS is loaded 'high', no other program can use
  this portion of memory. The definition of this area and its use is
  standardized in the Extended Memory Specification ( XMS ) issued by
  Microsoft / Lotus / Intel / AST Research, although there is question
  as to where the credit for the 'discovery' of the area and its first
  useage in real mode should go.
UMB_DRVR.DOC       Version 5.22             02/20/92             Page 3


INTRODUCTION continued


EXTENDED MEMORY - Memory starting at 1M ( 100000 ) that is accessible by
  the cpu in protected mode. On a 286, this range extends up to 16M-1
  ( FFFFFF ), and on 386 and above cpus up to 16M-1 ( FFFFFF ) in 16-bit
  mode and up to 4G-1 ( FFFFFFFF ) in 32-bit mode ( not used by vanilla
  DOS, but possibly by some DOS extenders ). Under DOS, this memory is
  accessed in several ways:

     1. BIOS INT 15H functions - This method is the oldest and least
          standardized, but requires no special drivers. Programs
          directly access the BIOS functions to utilize the memory, and
          must take great pains to avoid 'stepping on' other users -
          many different methods of 'marking' used memory exist, even
          not marking at all.

     2. DOS EXTENDERS - These facilities are supplied by several vendors
          including Phar-Lap and others. They are included within a
          program and allow that program access to extended memory using
          the extender's own techniques ( usually in protected mode ).

     3. XMS functions - This method is defined in the XMS standard that
          was mentioned earlier. It offers a way for many different
          programs to concurrently use extended memory easily without
          worrying about the underlying memory management problems.
          This method is the one used by all of the DOS 5 utilities that
          use extended memory to provide their services. A device driver
          is required to provide the XMS services. The DOS 5 driver is
          'HIMEM.SYS'. QEMM and other programs also provide XMS access.
          Most XMS servers including HIMEM.SYS will allow some portion
          of extended memory to be left outside their control so that
          programs using the BIOS INT 15H method can still work. Note
          that DOS 5 *requires* XMS services to access the HMA to load
          the major part of itself 'high'.

EXPANDED MEMORY - This is memory that conforms to the Expanded Memory
  Specification put out by Lotus / Intel / Microsoft. It is sometimes
  referred to as EMS, LIM 3.2, or LIM 4.0 memory. This type of memory
  is not directly addressable by the cpu, but requires use of additional
  facilities to be accessed. This memory is available via multiple 16K
  'pages' in a ( usually ) 64K 'window' called the EMS base page area
  within the 'Upper Memory Area', starting somewhere between C0000 and
  E0000 on a 16K boundary. The cpu can access this 'window' in real mode
  and uses the support facilities to map different 'pages' into the
  'window'. Although the cpu can only access EMS memory totalling the
  window size at any one time, it can 'move' the window to access all of
  the expanded memory available.
UMB_DRVR.DOC       Version 5.22             02/20/92             Page 4



INTRODUCTION continued



  Expanded ( EMS ) memory can be implemented in several ways:

    1. HARDWARE - Hardware support outside the cpu ( usually within the
         support chip set on the motherboard, or on an expansion slot
         card ) handles the mapping of the memory, controlled by a
         software driver which merely flips hardware 'switches', and the
         system runs under DOS in real mode with very little EMS
         management cpu overhead.

    2. SIMULATED - This approach uses extended memory to simulate
         expanded memory by moving 16K pages back and forth between
         extended memory and the window ( usually *below* 640K, which
         reduces the base memory area by the window size ). Although it
         has the disadvantages of ( usually ) reducing base memory and
         increasing the EMS management cpu overhead, it runs in real
         mode on any 286 or higher processor without requiring anything
         more than a software driver. This is the only software option
         available for many 286 systems. An example of this type of
         driver is UMB_EMS4, distributed with this package ( which,
         by the way, does *NOT* reduce your DOS base memory, because it
         uses a 64K window in the upper memory area! ).

    3. EMULATED - This technique is a sort of cross between 1 and 2. It
         uses the paging hardware built into 386 and newer processors
         in conjunction with virtual-86 mode to do the mapping tasks
         required to provide EMS memory. It is similar to 1 in that the
         mapping is really done by the hardware, and to 2 in that it
         also involves non-trivial software to provide the virtual-86
         mode environment necessary for it to work. Its advantages are
         that it works on any 386 or newer cpu without any other special
         hardware and does not reduce the base memory like 2, but it
         also has the drawback of restrictions, additional overhead and
         complexity introduced by virtual-86 mode. There are several
         packages that support this type of EMS, including EMM386.EXE
         supplied with DOS 5, and programs like QEMM, 386^MAX, NETROOM,
         and Memory Commander. Additionally, these EMS emulators can
         provide the Upper Memory Area using the same techniques, and
         generally are a good 'bang for the buck' in providing enhanced
         system functionality for a relatively modest impact on system
         processor overhead if you have the proper cpu.
UMB_DRVR.DOC       Version 5.22             02/20/92             Page 5


INTRODUCTION continued


     UMB_DRVR.SYS is a DOS 5.0 device driver that will use the 'shadow
ram' capability of the memory controller portion of many chip sets to:
     A) force all roms not specifically excluded to be shadowed, and
     B) expand DOS base memory beyond 640KB if possible, and
     C) provide UMBs ( Upper Memory Blocks ) to DOS for loading
        programs and device drivers into upper memory
while *NOT* using any memory below 640K and remaining in *REAL* mode.
     One advantage of this driver is that many if not all other device
drivers and TSR programs may be loaded 'high' including HIMEM.SYS ( even
though the DOS documentation says not! ).
     A second advantage of using UMB_DRVR is that some device drivers
that cannot be loaded high when a software EMS emulator is providing the
Upper Memory Area because of their use of DMA I/O ( this includes some
CD-ROM drivers, for example ) will work with UMB_DRVR.SYS. This has to
do with the characteristics of virtual-86 mode, 386+ memory management
facilities, and DMA hardware interactions. See MISCELLANEOUS NOTES - DMA
ACCESS TO UPPER MEMORY for more information and possible restrictions.
     In addition, remaining in real mode allows programs that must be
able to use protected or virtual-86 mode themselves, such as Borland's
Turbo Debugger ( TD386.EXE / TDH386.SYS ), to operate as intended ( and
yes, TDH386.SYS can be loaded high with no problems ).
     With respect to performance of UMB_DRVR.SYS versus the software EMS
emulator EMM386.EXE supplied with DOS 5, here are some benchmark results
supplied by a ( happy ) user:

" System: 386SX 20Mhz, VLSI TOPCAT chip set, 4MB ram, no math processor.
  DOS version: MS/DOS 5.0    UMB_DRVR.SYS version: 5.09
  Benchmark: CHECKIT 3.0 main system benchmark.

  CONFIG.SYS                           Dhrystones Whetstones
  ------------------------------------ ---------- ----------
  None                                    3767       76.7K


  DEVICE=C:\UMB_DRVR.SYS  /C=13           4042       77.1K
  DEVICEHIGH=C:\DOS\HIMEM.SYS
  DEVICEHIGH=C:\DOS\ANSI.SYS


  DEVICE=C:\DOS\HIMEM.SYS                 3683       45.7K
  DEVICE=C:\DOS\EMM386.SYS NOEMS
  DEVICEHIGH=C:\DOS\ANSI.SYS


  As you can see, there is a significant difference when using UMB_DRVR,
  not to mention the extra memory saved below 640k.  The benchmarks ran
  faster with UMB_DRVR than they did with no CONFIG.SYS at all. "
UMB_DRVR.DOC       Version 5.22             02/20/92             Page 6



INTRODUCTION continued



     The driver must be installed *BEFORE* HIMEM.SYS is installed. It is
an XMS 2.0 server providing UMBs to DOS via that standard. The chip
set parameter is processed and the proper routine called to remap the
unused shadow ram to DOS-useable memory. Available memory starting at
A0000 is used to expand DOS base memory beyond 640K, and other available
memory ( i.e. above the video memory ) is used for UMBs ( the areas
DOS uses for DEVICEHIGH or LOADHIGH commands ).
     The driver by default will not use any areas used for video memory.
It also forces all roms including the system BIOS ( F0000-FFFFF ) to be
shadowed unless forced to be excluded ( refer to MISCELLANEOUS NOTES for
considerations concerning disk controllers and network cards ). If the
BIOS has a 'boot page' at F0000-F7FFF that the driver can recognize
( containing system/CMOS setup code - AMI is one brand that has this ),
that area will be mapped in as available upper memory since it is not
needed after boot time.
     The driver should be loaded as the first driver if possible. This
allows following drivers and resident programs to be loaded high - even
HIMEM.SYS and EMM386.SYS ( DOS documentation says they can't, but it
works; see MISCELLANEOUS NOTES - WINDOWS and EMS DRIVERS, however ). It
will initialize, supply UMBs, and terminate leaving a small stub above
640K. To ensure proper chip set function, all warm boots ( CTL+ALT+DEL )
will be forced to be cold boots after UMB_DRVR is installed.
     Appropriate status and error messages are issued during processing
and a map of the driver's action is displayed.
     One of my systems is a 386SX with the Chips and Technologies NEATsx
chip set and an AMI ( American Megatrends ) BIOS dated 04/09/90. It has
4MB of ram and a Hercules Monochrome Graphics card. I load DOS into the
HMA using HIMEM.SYS, supply simulated EMS from the XMS memory pool using
UMB_EMS4, and load Borland's Turbo Debugger device driver TDH386.SYS for
386 virtual debugging ( TD386.EXE ). Using UMB_DRVR defaults and loading
all drivers ( except SETVER ) high gives me 704K base memory for DOS, a
maximum executable program size of almost 689K and 224K in one UMB
located at C0000-F7FFF with over 143K still free in that upper memory
block for any other TSRs or drivers I may want to load.  The following
information is extracted from that system ( Note: 1K = 1024 decimal ).


     UMB_DRVR.SYS initializes showing:


Chip-controlled ram at: AAAABBBBCCCCDDDDEEEEFFFF ([D]OS base memory,
                        048C048C048C048C048C048C  [e]ms base page area,
has been configured as: DDDDvvvvUUUUUUUUUUUUUUss  [s]hadowed rom,
DOS base memory expansion = 64K                   [U]pper memory area,
Upper memory block ( UMB ) area = 224K            [v]ideo, [-]excluded)
UMB_DRVR.DOC       Version 5.22             02/20/92             Page 7



INTRODUCTION continued



     The command 'MEM /C' displays the following:


Conventional Memory :

  Name                Size in Decimal       Size in Hex
-------------      ---------------------   -------------
  MSDOS              12304      ( 12.0K)       3010
  SETVER               400      (  0.4K)        190
  COMMAND             2624      (  2.6K)        A40
  FREE                  64      (  0.1K)         40
  FREE              705328      (688.8K)      AC330

Total  FREE :       705392      (688.9K)

Upper Memory :

  Name                Size in Decimal       Size in Hex
-------------      ---------------------   -------------
  SYSTEM             65712      ( 64.2K)      100B0
  HIMEM               1072      (  1.0K)        430
  UMB_EMS4           73136      ( 71.4K)      11DB0
  TDH386              7920      (  7.7K)       1EF0
  FREE              146976      (143.5K)      23E20

Total  FREE :       146976      (143.5K)

Total bytes available to programs (Conventional+Upper) : 852368 (832.4K)
Largest executable program size :                        705184 (688.7K)
Largest available upper memory block :                   146976 (143.5K)

   3080192 bytes total EMS memory
   3080192 bytes free EMS memory

   3145728 bytes total contiguous extended memory
         0 bytes available contiguous extended memory
   3080192 bytes available XMS memory
           MS-DOS resident in High Memory Area


     *NOTE* - If the video card were a CGA, the DOS base ram expansion
would be 96K(!) with executable program size a whopping 721K(!)...  a
pretty good cure for 'ram cram'! These same results can ( and have been
repeatedly ) achieved on *286* machines!
UMB_DRVR.DOC       Version 5.22             02/20/92             Page 8


MISCELLANEOUS NOTES


BOOT PAGE

     If UMB_DRVR.SYS uses the 'boot page' area ( see INTRODUCTION for
definition ) by default and your system crashes, you need to use the /M=
parameter to force it to be part of the BIOS ( use '##' or '--' ). If no
'boot page' is recognized, you may still try the /M= parameter ( with
'++' for F0000-F7FFF ) if you are brave enough. Heed the warning about
having a bootable diskette, however - you may need it.


EMS DRIVERS ( EMM386, QEMM, 386^MAX, NETROOM, MEMORY COMMANDER, ETC )

     If you run EMS, it is most efficient in terms of contiguous memory
to have your EMS base address immediately following your video ram and
any adjacent rom ( e.g. C0000-CFFFF for CGA or monochrome, C8000-D7FFF
for VGA ) or at the top of the useable area ( e.g. E8000-F7FFF with a
'boot page', E0000-EFFFF without ).
     It is also more efficient in terms of cpu usage overhead to use the
hardware EMS driver for your chip set or your EMS memory card instead of
a software emulation; see INTRODUCTION ( virtual-86 mode, benchmark ).
     If you use an EMS driver ( hardware or software emulation ), you
should use the /M= parameter to force UMB_DRVR to exclude the EMS base
area. Make sure you *DO NOT* have your driver try to map in the upper
memory ( 640K - 1M ) area ( other than the EMS base area ) - UMB_DRVR
has done that already ( refer to your driver's documentation ). You
should be able to use DEVICEHIGH/LOADHIGH to put your driver into upper
memory in most cases.
     If you do not have an EMS driver, try UMB_EMS4 ( please refer to
UMB_EMS4.DOC ). There have been some problems reported running EMM386
with UMB_DRVR - I recommend against it. UMB_EMS4 should provide the
services you need.


ROMS THAT CANNOT BE SHADOWED ( DISK CONTROLLERS, NETWORK CARDS )

     Some roms cannot be shadowed by normal means because they have some
ram or a memory-mapped I/O port they must use included in their address
space ( e.g. some RLL, ESDI and SCSI disk controllers, and also some
network cards ) and shadowing is done using protected ram. These roms
will sometimes work when shadowed by this driver if they are within a
protection block also containing UMBs. Try letting UMB_DRVR shadow the
rom and see if it works. If your system hangs up or you have problems
with disk or network access with the rom shadowed, you must use the /M=
parameter to exclude it from UMB_DRVR.SYS control. Refer to CHIP-SET-
SPECIFIC NOTES for any special considerations.
UMB_DRVR.DOC       Version 5.22             02/20/92             Page 9


MISCELLANEOUS NOTES continued


DMA ACCESS TO UPPER MEMORY

     DMA ( Direct Memory Access ) is a method of data transfer between
main memory ( ram ) and I/O devices without requiring cpu intervention.
Standard AT-compatible floppy disk controllers use it, as do some other
devices, such as CD-ROMs and data acquisition hardware. It is supported
through the Intel 8237A DMA controller chip, or by compatible integrated
devices like the 82C206, or even by compatible components within the
motherboard chip set. These devices control the data / address busses in
the system to do the transfer while the cpu does other work. They do not
have access to the internal 386+ cpu memory management facilities during
their operation, and so are unaware of remapping of memory done there.
Most of the time this is not a concern, as software that handles the
remapping also handles DMA setup by intercepting accesses to the DMA
controller registers and trying to keep things straight for DMA I/O.
This can become a concern if the DMA transfer spans a page boundary that
in virtual memory is to an adjacent page, but in real memory is not.
Most of the 386-type mappers either automatically or through parameters
try to avoid this situation by causing the area to be mapped ( as much
as possible ) into contiguous memory.
     UMB_DRVR, on the other hand, uses hardware external to the cpu that
maps in the upper memory area contiguously such that DMA access to the
upper memory area is no different than to the base 640K. The DMA mapping
requirememts that the device drivers are aware of for a 'standard AT'
system do not change when UMB_DRVR provides the upper memory area. Note
that some drivers still cannot load high because they are 'confused' by
being at a higher address in memory than the program that is using them,
but this is becoming much less common as drivers are rewritten to be
able to take advantage of the DOS 5 high memory capabilities.
     One consideration remains, however: a *VERY* few chip sets that are
supported by UMB_DRVR are designed such that the ram that is mapped into
the upper memory area can only be accessed by the cpu. UMB_DRVR performs
a test for proper DMA function at initialization and issues a warning
message if DMA is not possible to the upper memory area. If ( and *ONLY*
if ) this is the case, any DMA accesses attempted to an area above 640K
and below 1M will not work, and the following restrictions will apply:
     (1) If you boot from a floppy disk or try to load any driver or
         TSR high reading it from a floppy, do not load UMB_DRVR.SYS -
         if you do, your system will probably hang up immediately upon
         trying to load anything into upper memory.
     (2) Almost no hard disk controllers use DMA, but if you have one
         that does, you will probably have problems with loading any
         driver or TSR into upper memory, and you may not be able to
         use UMB_DRVR at all.
     (3) Device drivers that use DMA for access to buffers within the
         driver itself, or allocated immediately after the driver when
         it initializes, cannot be loaded high on your system.
     (4) No DOS base memory expansion from unused video memory should
         be used ( all DOS base ram should be capable of DMA access ).
     Note that these restrictions apply *ONLY* if DMA access to upper
memory is *NOT* available, i.e. if UMB_DRVR issues the warning message.
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 10


MISCELLANEOUS NOTES continued


MICROSOFT WINDOWS

     Windows 3.0 and 3.0A have been tested as follows:

386 Enhanced mode:
     Windows will run in 386 enhanced mode with UMB_DRVR if the line
          EMMExclude=A000-FFFF
is added to the SYSTEM.INI file, [386Enh] section. Note that a practical
minimum of 4MB of ram on your system is suggested to run in this mode.
Also note that SETVER.EXE must be loaded LOW, and ANSI.SYS ( if used )
must be loaded LOW. There may be other drivers like this... experiment.
Refer to UMB_EMS4.DOC for considerations regarding UMB_EMS4 and Windows.

Standard mode:
     Windows in standard mode works with UMB_DRVR and HIMEM.SYS, with or
without an EMS driver ( hardware or software ) loaded high or low. Note
you must have a minimum of something like 512K or more extended memory
to run in standard mode - i.e. do not have a software EMS driver remap
ALL of your extended memory to expanded.


PROGRAM ACCESS TO UPPER MEMORY WITH DOS 5 MANAGING UMBS

1. Record current status of memory system so you can restore it.
int 21H/ax=5800h - returns al=strategy ( see below )
int 21h/ax=5802h - returns al=UMB link state ( see below )

2. Set up for memory allocation / deallocation.
int 21h/ax=5801h/bh=0/bl=strategy    int 21h/ax=5803h/bh=0/bl=UMB status
  00h - first fit, low memory          00h = remove UMBs from mem chain
  01h - best   "    "    "             01h = add UMBs to mem chain
  02h - last   "    "    "           ( UMBs must be chained for access )
  40h - first fit, high memory
  41h - best   "    "     "
  42h - last   "    "     "
  80h - first fit, try high then low memory
  81h - best   "    "   "    "    "    "
  82h - last   "    "   "    "    "    "

3. Do normal int 21h/ah=48h, int 21h/ah=49h, int 21h/ah=4Ah as desired.

4. Restore values saved in step 1 above.

     The system defaults to first-fit-low with UMBs not chained. If you
chain the UMBs, strategies 00/01/02 affect the entire chain. For example
with the UMBs chained and strategy 00, you will get memory from the UMB
area if the request cannot be satisfied from low memory.
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 11


DETERMINING YOUR CHIP SET

     If your system documentation or CMOS setup screen does not tell you
what chip set you have, the best way to find out is to open the cover on
your system and look at the motherboard. *MAKE SURE THE SYSTEM IS OFF
AND UNPLUGGED* when you do this. The chip you will be looking for may
not be one of the larger in size, but it will have many ( usually 80+,
sometimes up to 200 or more ) pins. The number that identifies the key
chip in the set is listed in CHIP-SET-SPECIFIC NOTES for each chip set
supported. If you find a matching number on one of the chips on your
motherboard, use the /C= value shown for that set. If you don't see a
match, refer to the sections BAD NEWS, MAYBE?, and COMING ATTRACTIONS.
     Note that some chips only contain peripheral support and *DO NOT*
indicate what chip set you have. These include, but are not limited to:
          82C206 ( many brands )
          82C601, 82C710, 82C711 ( Chips and Technologies )
          VL82C100, VL82C106, VL82C107, VL86C050, VL16C45x, VL16C55x
               ( VLSI Technology )
          82C452, 85C206 ( Silicon Integrated Systems )
          TACT82206 ( Texas Instruments )
Again, these chip numbers *DO NOT* indicate what chip set you have. If
you find one of these on your motherboard, you should keep looking!


CHIP-SET-SPECIFIC NOTES


****************************************
* User-Specified Available Memory mode *
****************************************
/C=00 - Chip ID(s): None ( 286, 386SX, 386DX, 486 )

     This selection causes UMB_DRVR to map the areas specified in the
/M= parameter, using the '+' ( plus ) character, as upper memory. Please
note the following points when using this mode:
     (1) This mode *CANNOT BE USED* unless you have a way to actually
           map read-write ram into the area between 640K ( A0000 ) and
           1M ( 100000 ) through your CMOS setup or some other program
           provided by your system or chip-set manufacturer, or a memory
           expansion card that maps ram into that area on the AT bus.
         NOTE: The system BIOS brand 'MRBIOS' from Microid Research will
           include the capability to set up your memory this way if your
           chip set supports it.
     (2) No verification or manipulation of any chip set is done.
     (3) Rom shadowing is totally controlled by your system BIOS and
           CMOS setup parameters.
     (4) No checking is performed other than the memory read-write and
           DMA tests.
     (5) Warm boots are *NOT* forced to be cold boots.
     (6) It is *YOUR RESPONSIBILITY* to properly determine and specify
           which areas can be used.
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 12


CHIP-SET-SPECIFIC NOTES continued


*******************************************************
* Chips & Technologies CS8221 NEAT, CS8281 NEATsx,    *
*                   CS8223 LeAPset, CS8283 LeAPset-sx *
* Texas Instruments TACT82S411 Single Chip AT         *
* United Microelectronics (UMC) UM82C210 286/386SX AT *
*******************************************************
/C=01 - Chip ID(s): ( C & T ) 82C212, 82C241 ( 286 )
                              82C812, 82C841 ( 386SX );
                    ( TI ) TACT82S411 ( 286, 386SX );
                    ( UMC ) UM82C212 ( 286, 386SX )

     These chip sets allow the 384k of motherboard ram at A0000-FFFFF to
relocate to extended memory at 100000-15FFFF on systems with only 1mb of
ram. If this remapping is enabled when UMB_DRVR.SYS enables this area,
the remapping is removed and the size of your extended memory is reduced
by 384k, i.e. it disappears. Note that this applies only to systems with
*EXACTLY* 1MB of memory.
     These chip sets map in 16k segments, but write protection for the
area C0000-FFFFF is in 64k segments. To allow maximum memory utilization
the driver marks any segment containing UMBs as read/write. If the 64k
segment also contains a rom shadow, it is not protected.
     Although it should not be necessary, if you wish to have a rom be
shadowed and protected, exclude any non-rom areas within the 64k segment
( e.g. for a VGA rom at C0000-C7FFF, exclude C8000-CFFFF ).
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).
     UMB_DRVR.SYS will recognize the EMS setup for these chip sets and
will exclude the EMS base segment if the EMS hardware is enabled when
UMB_DRVR initializes. Use of the /M= parm is not required in this case.


****************************
* VLSI Technology VL82C200 *
****************************
/C=02 - Chip ID(s): VL82C201,VL82C202,VL82C203,VL82C204 ( 286, 386SX )
                    ( all 4 chips required )

     This chip set uses a jumper or switch to enable shadow ram ability.
This does not actually cause shadowing, but must be in proper position
for UMB_DRVR.SYS to work. Check your system documentation.
     This chip set maps and protects in 64k segments. To allow maximum
memory utilization, 64k segments containing UMBs are set to read/write.
If the 64k segment also contains a rom shadow, it is not protected.
     Although it should not be necessary, if you wish to have a rom be
shadowed and protected, exclude any non-rom areas within the 64k segment
( e.g. for a VGA rom at C0000-C7FFF, exclude C8000-CFFFF ).
     If you must force a rom to be unshadowed, exclude the entire 64k
segment on a 64k boundary ( e.g. for a disk rom at C8000-CBFFF, exclude
C0000-CFFFF ).
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 13



CHIP-SET-SPECIFIC NOTES continued



*******************
* FOREX FRX36C300 *
*******************
/C=03 - Chip ID(s): FRX36C300 ( 386DX )

     This chip set maps in 32k segments from C0000 to EFFFF, and one 64k
segment for the system BIOS ( F0000-FFFFF ).  Ram at A0000-BFFFF is
always remapped to the highest area and cannot be used by the driver.
Protection is set globally, meaning that all used ram ( shadow or UMBs )
is marked read/write.
     The chip set also remaps D0000-EFFFF to the highest area if there
is nothing shadowed in that area. When UMB_DRVR.SYS enables this area,
the remapping is removed and the size of your extended memory is reduced
by 128k.
     If you must force a rom to be unshadowed, exclude the entire 32k
segment on a 32k boundary ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CFFFF ).



*******************************************************************
* Chips & Technologies CS8230 386/AT, CS8231 Turbo Cache 386/AT,  *
*                      CS8233 PEAKset/386, CS82310 PEAKset DM/386 *
*******************************************************************
/C=04 - Chip ID(s): 82C302, 82C307, 82C311, 82C351 ( 386DX )

     These chip sets maps in 16k segments, but write protection for the
area C0000-FFFFF is in 64k segments. To allow maximum memory utilization
the driver marks any segment containing UMBs as read/write. If the 64k
segment also contains a rom shadow, it is not protected.
     Although it should not be necessary, if you wish to have a rom be
shadowed and protected, exclude any non-rom areas within the 64k segment
( e.g. for a VGA rom at C0000-C7FFF, exclude C8000-CFFFF ).
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 14


CHIP-SET-SPECIFIC NOTES continued


******************************************************************
* Chips & Technologies 82C235 SCAT, 82C836 SCATsx, CB8291 ELEAT, *
*                      CB8295 ELEATsx, CS8285 PEAKset-sx,        *
*                      CS8227 CHIPSlite, CS8288 CHIPSlite-sx     *
******************************************************************
/C=05 - Chip ID(s): 82C235 ( 286 ), 82C836 ( 386SX )

     These chip sets allow the 384k of motherboard ram at A0000-FFFFF to
relocate to extended memory at 100000-15FFFF on systems with only 1mb of
ram. If this remapping is enabled when UMB_DRVR.SYS enables this area,
the remapping is removed and the size of your extended memory is reduced
by 384k, i.e. it disappears. Note that this applies only to systems with
*EXACTLY* 1MB of memory.
     These chip sets map in 16k segments, but write protection for the
area C0000-FFFFF is in 32k segments. To allow maximum memory utilization
the driver marks any segment containing UMBs as read/write. If the 32k
segment also contains a rom shadow, it is not protected.
     Although it should not be necessary, if you wish to have a rom be
shadowed and protected, exclude any non-rom areas within the 32k segment
( e.g. for a rom at C8000-CBFFF, exclude CC000-CFFFF ).
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).


************************
* ETEQ Micro COUGAR II *
************************
/C=06 - Chip ID(s): 82C491 ( 386DX, 486 )

     This chip set maps in 16k segments from C0000 to EFFFF, and one 64k
segment for the system BIOS ( F0000-FFFFF ). Memory protection is done
in 64k segments from C0000 to EFFFF. The hardware does not allow read /
write access to the area F0000-FFFFF - i.e. the rom can be shadowed and
protected, but the driver cannot use the boot page. The driver also
cannot use the ram at A0000-BFFFF.
     The chip set can remap A0000-BFFFF and D0000-EFFFF to the highest
area if no shadowing is done in that area. If this remapping is enabled
and UMB_DRVR.SYS enables the area D0000-EFFFF, the remapping is removed
and the size of your extended memory is reduced by 256k.
     Although it should not be necessary, if you wish to have a rom be
shadowed and protected, exclude non-rom areas within the 64k segment:
 e.g. for a rom at C8000-CBFFF, exclude C0000-C7FFF and CC000-CFFFF. If
you have a VGA rom at C0000-C7FFF, you only need exclude CC000-CFFFF.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 15


CHIP-SET-SPECIFIC NOTES continued


***************************
* OPTi Sx/AT, Sx/AT Cache *
***************************
/C=07 - Chip ID(s): 82C281, 82C282, 82C283 ( 386SX )

     These chip sets maps in 16k segments from C0000 to EFFFF, and one
64k segment for the system BIOS ( F0000-FFFFF ). Memory protection is
in 64k segments from C0000 to EFFFF. The hardware does not allow read /
write access to the area F0000-FFFFF - i.e. the rom can be shadowed and
protected, but the driver cannot use the boot page. The driver also
cannot use the ram at A0000-BFFFF.
     These chip sets can remap A0000-BFFFF and D0000-EFFFF to the high
end of extended memory if no shadowing is done in either area. If this
remapping is enabled and UMB_DRVR.SYS enables the area D0000-EFFFF, the
remapping is removed and the size of your extended memory is reduced by
256k.
     Although it should not be necessary, if you wish to have a rom be
shadowed and protected, exclude non-rom areas within the 64k segment:
 e.g. for a rom at C8000-CBFFF, exclude C0000-C7FFF and CC000-CFFFF. If
you have a VGA rom at C0000-C7FFF, you only need exclude CC000-CFFFF.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).


********************
* OPTi DX/BB PC/AT *
********************
/C=08 - Chip ID(s): 82C496 ( 386DX, 486 )

     This chip set maps in 16k segments from C0000 to EFFFF, and one 64k
segment for the system BIOS ( F0000-FFFFF ). Memory protection is done
in 64k segments from C0000 to EFFFF. The hardware does not allow read /
write access to the area F0000-FFFFF - i.e. the rom can be shadowed and
protected, but the driver cannot use the boot page. The driver also
cannot use the ram at A0000-BFFFF.
     The chip set can remap A0000-BFFFF and D0000-EFFFF to the highest
area if no shadowing is done in that area. If this remapping is enabled
and UMB_DRVR.SYS enables the area D0000-EFFFF, the remapping is removed
and the size of your extended memory is reduced by 256k.
     Although it should not be necessary, if you wish to have a rom be
shadowed and protected, exclude non-rom areas within the 64k segment:
 e.g. for a rom at C8000-CBFFF, exclude C0000-C7FFF and CC000-CFFFF. If
you have a VGA rom at C0000-C7FFF, you only need exclude CC000-CFFFF.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 16


CHIP-SET-SPECIFIC NOTES continued


***********************************
* OPTi 386WB PC/AT, 486SXWB PC/AT *
***********************************
/C=09 - Chip ID(s): 82C391 ( 386DX ), 82C493 ( 486 )

     These chip sets maps in 16k segments from C0000 to EFFFF, and one
64k segment for the system BIOS ( F0000-FFFFF ). Memory protection is
done in 64k segments from C0000 to EFFFF. The hardware does not allow
read / write access to ram at F0000-FFFFF - i.e. the rom can be shadowed
and protected, but the driver cannot use the boot page. The driver also
cannot use the ram at A0000-BFFFF.
     Although it should not be necessary, if you wish to have a rom be
shadowed and protected, exclude non-rom areas within the 64k segment:
 e.g. for a rom at C8000-CBFFF, exclude C0000-C7FFF and CC000-CFFFF. If
you have a VGA rom at C0000-C7FFF, you only need exclude CC000-CFFFF.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).


***********************
* OPTi 386/486WB EISA *
***********************
/C=10 - Chip ID(s): 82C682 ( 386DX, 486 )

     This chip set maps and protects in 16k segments at C0000-DFFFF, one
64k segment at E0000 and one 64k segment for the system BIOS at F0000.
The the driver cannot use the ram at A0000-BFFFF.
     If one of the 64k segments contains both shadowed rom and UMB area,
it is marked read/write. All roms in the C0000-DFFFF area are protected.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ) unless it is in the E0000 block or you wish to force the
BIOS ( F0000-FFFFF) to be unshadowed. Then you must exclude the entire
64k block ( E0000-EFFFF and/or F0000-FFFFF ).


****************************************
* Elite Microelectronics Eagle, Falcon *
****************************************
/C=11 - Chip ID(s): e88C311 ( 386DX ), e88C411 ( 486 )

     These chip sets map and protect in 16k segments for the entire area
C0000-FFFFF. All shadowed roms are write-protected. UMB_DRVR cannot use
the ram at A0000-BFFFF.
     These sets always remap A0000-BFFFF to the highest memory area, and
can selectively remap C0000-FFFFF in 64k blocks if no shadowing is done
within the 64k block. If this remapping is active and UMB_DRVR enables
shadow memory within one of the remapped 64k blocks, the remapping is
removed and the size of your extended memory is reduced.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 17


CHIP-SET-SPECIFIC NOTES continued


*************************
* VLSI Technology SCAMP *
*************************
/C=12 - Chip ID(s): VL82C310, VL82C311 ( 286, 386SX ), VL82C311L ( 286 )

     These chip sets map and protect in 32k segments for A0000-BFFFF,
16k segments for C0000-DFFFF, and 32k segments for E0000-FFFFF. If a
rom shadow shares a 32k segment from E0000 to FFFFF with a UMB area, it
is marked read/write. Any shadowed rom from C0000-DFFFF is protected, as
is any 32k segment from E0000 to FFFFF that is all shadowed rom.
     These sets can remap A0000-FFFFF to the highest memory area if no
shadowing is done and system memory is 1MB, 2MB, 3MB or 4MB. If remap
is active and UMB_DRVR enables any shadow memory, the remapping is
removed and the size of your extended memory is reduced. Note that this
applies only to systems with *EXACTLY* 1MB, 2MB, 3MB or 4MB installed.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies if it is between C0000 and DFFFF ( e.g. for a
disk rom at C8000-CBFFF, exclude C8000-CBFFF ). If it is between E0000
and FFFFF, exclude all areas in the 32k segment ( e.g. for a disk rom at
E0000-E3FFF, exclude E0000-E7FFF ).


*********************************************
* VLSI Technology VL82C286, VL82C386 TOPCAT * ( These sets are all made
* Intel 82340SX, 82340DX                    *     by VLSI Technology )
*********************************************
/C=13 - Chip ID(s): ( VLSI ) VL82C320 ( 286, 386SX ), VL82C330 ( 386DX )
                             VL82C320A ( 286, 386SX, 486 )
                    ( Intel ) 82343, 82346 ( 286, 386SX )
                              82343A ( 286, 386SX, 486 )

     These chip sets map in 16k segments for the entire area from A0000
to FFFFF and protect in 16k segments from C0000 to FFFFF. All shadowed
rom areas are protected. The video area ( A0000-BFFFF ) and the 'boot
page' ( F0000-F7FFF ) can only be utilized on the VL82C320 / 82343 'A'
revisions ( this implementation was chosen to avoid the DMA limitation;
see MISCELLANEOUS NOTES - DMA ACCESS TO UPPER MEMORY ). UMB_DRVR will
recognize the various chips and enforce these restrictions accordingly.
     These sets can remap A0000-FFFFF to the high end of extended memory
if no shadowing is done and system memory is exactly 1MB or 2MB. If this
remapping is active and UMB_DRVR enables shadow memory, the remapping is
removed and the size of your extended memory is reduced. Note that this
applies only if the system memory size is *EXACTLY* 1MB or 2MB.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 18


CHIP-SET-SPECIFIC NOTES continued


*******************************
* OPTi HiD/386 AT, HiB/486 AT *
*******************************
/C=14 - Chip ID(s): 82C382 ( 386DX ), 82C482 ( 486 )

     These chip sets map in 16k segments from C0000 to EFFFF and one 64k
segment for the system BIOS ( F0000-FFFFF ). Memory protection is done
in 64k segments from C0000 to EFFFF. The hardware does not allow read /
write access to the area F0000-FFFFF - i.e. the rom can be shadowed and
protected, but the driver cannot use the boot page. The driver also
cannot use the ram at A0000-BFFFF.
     The chip sets can remap A0000-BFFFF and D0000-EFFFF to the highest
area if no shadowing is done in that area. If this remapping is enabled
and UMB_DRVR.SYS enables the area D0000-EFFFF, the remapping is removed
and the size of your extended memory is reduced by 256k.
     Although it should not be necessary, if you wish to have a rom be
shadowed and protected, exclude non-rom areas within the 64k segment:
 e.g. for a rom at C8000-CBFFF, exclude C0000-C7FFF and CC000-CFFFF. If
you have a VGA rom at C0000-C7FFF, you only need exclude CC000-CFFFF.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).


*********************************************
* Sun Electronics SUNTAC ST62CS24, ST62CS25 *
*********************************************
/C=15 - Chip ID(s): ST62C241 ( 286 ), ST62C251 ( 286, 386SX )

     These chip sets have two memory-mapping modes: one for extended
memory and one for expanded ( EMS ) memory. You must have your system
configured for extended memory only for UMB_DRVR to recognize the chip
set. Also, some BIOSs ( e.g. newer AMI ) relocate the video rom before
shadowing it. This can cause fragmentation of your upper memory. If this
is the case, turn off video shadowing in your CMOS / extended setup. The
driver will shadow your video rom when it sets up the upper memory area.
See your CMOS setup or system documentation.
     These chip sets map and protect in 16k segments from C0000 to DFFFF
and in 32k segments from E0000 to FFFFF.  The driver cannot use the ram
at A0000-BFFFF. All shadowed roms from C0000 to DFFFF and the system
BIOS are protected.
     The chip sets always remap A0000-DFFFF to the highest area, and
remap E0000-FFFFF there if no shadowing is done. UMB_DRVR must remove
the remapping for E0000-FFFFF if active, and must use some extended
memory to supply the upper memory area. Your extended memory size will
be adjusted accordingly.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 19


CHIP-SET-SPECIFIC NOTES continued


*******************************
* Texas Instruments TACT83000 *
*******************************
/C=16 - Chip ID(s): TACT83442 ( 386SX, 386DX, 486 )

     This chip set maps in 16k segments from A0000 to FFFFF, and memory
protection is done in 16k segments from C0000 to FFFFF. All shadowed
roms are protected.
     The chip set can remap any 64k segment from A0000 to FFFFF not used
for shadowing to the upper end of extended memory. If this remapping is
active and UMB_DRVR.SYS uses any of the remapped area, the remapping is
removed and the size of your extended memory is reduced.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).


*****************************************************
* Silicon Integrated Systems High Performance 80386 *
*****************************************************
/C=17 - Chip ID(s): 85C310 ( 386DX )

     This chip set maps in 16k segments from C0000 to DFFFF, and two 64k
segments for E0000 and F0000. Memory protection is global, so no shadow
areas are protected. The driver cannot use the area from A0000 to BFFFF.
     The chip set, depending on memory configuration, can remap either
256K or 384K of unused shadow area to the upper end of extended memory.
If this remapping is active and UMB_DRVR uses any of the remapped area,
the remapping is removed and your extended memory size is reduced.
     If you must force a rom to be unshadowed, you need only exclude the
16k segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CBFFF ).


******************************************************
* Silicon Integrated Systems High Performance ISA486 *
******************************************************
/C=18 - Chip ID(s): 85C401 ( 486 )

     This chip set maps in 32k segments from C0000 to EFFFF, and one 64k
segment for F0000. Memory protection is global, so no shadowed areas are
protected. The driver cannot use the area from A0000 to BFFFF.
     If you must force a rom to be unshadowed, you must exclude the 32k
segment(s) it occupies ( e.g. for a disk rom at C8000-CBFFF, exclude
C8000-CFFFF ).
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 20


INSTALLATION

     *PLEASE BE SURE YOU HAVE REVIEWED THE MISCELLANEOUS AND CHIP-SET-
SPECIFIC NOTES* prior to installing. Also, make sure you have backed-up
your system and that you have a diskette you can boot from in case you
have problems with your CONFIG.SYS settings.
     Installation ( preferably as the first driver ) is via the lines:

         DEVICE=UMB_DRVR.SYS /C=nn [/M=ssssssssssssssssssssssss]
         DOS=[HIGH|LOW],UMB  ( *REQUIRED* - turn on DOS 5 UMB support )

in your CONFIG.SYS file. The /C= parameter is required - nn is the chip
set from 'CHIP-SET-SPECIFIC NOTES'. The /M= parameter is optional and is
used to override defaults. It contains characters corresponding to 16K
memory blocks at the following addresses:

          /M=ssssssssssssssssssssssss
        A0000'||||||||||||||||||||||`FC000---| Only '..' and '--' may be
         A4000'||||||||||||||||||||`F8000----| used for the system BIOS.
  Video   A8000'||||||||||||||||||`F4000--|
   RAM     AC000'||||||||||||||||`F0000---| '..', '--', '++', and '##'
    area    B0000'||||||||||||||`EC000    | may be used for boot page.
             B4000'||||||||||||`E8000     | Use '##' to force area to be
              B8000'||||||||||`E4000      | shadowed as part of BIOS.
               BC000'||||||||`E0000
                     |||||||`DC000
                     ||||||`D8000     Upper
                     |||||`D4000       Memory
                     ||||`D0000         area
                     |||`CC000
                     ||`C8000
                     |`C4000
                     `C0000

           s = '.' Allow default use of block
               '-' Force block to be unused and unshadowed
               '+' Force block usage for UMBs or DOS base ram expansion

The /M= parameter must always be supplied as all 24 characters, using
the '.' character to fill any positions not forced on or off. For
example, on a VGA system using video memory from A0000 to BFFFF, if
it is in CGA 80 x 25 mode, the only video memory in use is B8000-BFFFF.
In this case, the memory from A0000-AFFFF may be used to expand DOS
base memory beyond 640K ( with some VGA cards ) by using the parameter:
         /M=++++....................
Of course, with the system configured like this, if you change the video
mode, undefined ( read as disaster city! ) results will occur.
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 21


ERROR MESSAGES


DMA NOT SUPPORTED ( WARNING )

     See MISCELLANEOUS NOTES - DMA ACCESS TO UPPER MEMORY.


SHADOW RAM TEST FAILURE

     This message is issued when the shadow ram read/write test fails.
It is usually an indication that you are trying to use memory that is
not available, or ( possibly ) you do not have the chip set you have
specified. Check your CMOS setup and any jumpers or switches per your
hardware documentation. Also review CHIP-SET-SPECIFIC NOTES earlier in
this document for any requirements.
     This can also occur if you are trying the example listed in the
INSTALLATION section using a portion of the video ram area on a VGA
system in CGA mode and your VGA hardware will not allow it.


CHIP SET NOT RECOGNIZED

     As much as possible, UMB_DRVR.SYS tries to verify that you have the
chip set you indicated in the /C= parameter. If you are sure you have
the chip set and have correctly specified it, contact me ( see TECHNICAL
SUPPORT ) and I will try to straighten things out.
     This message can also occur if a program ( e.g CMOS setup from DOS,
disk defragger ) reboots the system in a certain way. In this case, it
can be cleared with the reset button or by power down / power up.


XMS ALREADY INSTALLED

     You have not installed UMB_DRVR.SYS before HIMEM.SYS ( UMB_DRVR.SYS
issues message ), or you have omitted or incorrectly specified the line
'DOS=xxxx,UMB' in your CONFIG.SYS ( HIMEM.SYS issues message ). Correct
your CONFIG.SYS file and and reboot.


INCORRECT DOS VERSION

     UMB_DRVR.SYS requires MS/DOS 5.0 for proper operation.


INVALID PARAMETER(S)

     On the DEVICE= statement for UMB_DRVR.SYS you have: 1) omitted or
incorrectly specified the /C= parameter, 2) incorrectly specified the
/M= parameter, or 3) included extra parameter(s).
     Check that you have entered the proper 2-digit number for your chip
set, that ( if specified ) the /M= parameter contains 24 characters from
the set '.' (period), '-' (minus), '+' (plus) and '#' (pound sign), and
that nothing else is specified. Correct your CONFIG.SYS file and reboot.
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 22


BAD NEWS ( CHIPS THAT WILL NOT BE SUPPORTED )

     Chips & Technologies: CS8220(82C201/82C202) [1]
     Intel: 82335/82335SX [2]
     Sun Electronics ( SUNTAC ): ST62CS02(ST62BC002) [1]
     United Microelectronics ( UMC ): UM82C230(UM82C231) [1]
     Western Digital: ( Faraday ) FE3021/FE3021A [2]

     Notes:
          [1] - No shadow ram support
          [2] - Lock feature prohibits access


MAYBE? ( NEED TECHNICAL DATA TO SUPPORT )

     ACER
     American Megatrends (AMI) - Megatrends custom chips, *NOT* BIOS
     COMPAQ
     IBM PS/2
     Micronics - custom chips
     PC-Chips brand chip set(s)
     Toshiba

     I have been unable to get any documentation for these systems. If
     you can have your system vendor or the chip set manufacturer
     contact me, I will try to include support for them.


COMING ATTRACTIONS ( SUPPORT PLANNED OR UNDER DEVELOPMENT )

     ACC Microelectronics: 2036 [2], 2046
     Headland Technology: HT12/HT15 [1], HT18/HT21/HT22 [2], HT322
     Intel: 82350 EISA(82359), 80386SL(Intel386SL)
     OPTi: L1/L2 Notebook
     Symphony Laboratories: SL82C360(SL82C361), SL82C460(SL82C461)
     Texas Instruments: TACT84500 EISA(TACT84542)
     United Microelectronics ( UMC ): UM82C380(UM82C384) [1]
     VLSI Technology: VL82C486
     Western Digital: WD6000/WD75C10/WD76C10/WD7710/WD7910 [1]
     ZyMos Corporation: POACH(82C230/82C231)

     Notes:
          [1] - Support minimal ( maximum 64K UMB area ).
          [2] - Support limited ( maximum 128K UMB area ).

     If your chip set is not listed, have your system vendor or the chip
     set manufacturer contact me and I will try to support it.
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 23



COMING ATTRACTIONS ( SUPPORT PLANNED OR UNDER DEVELOPMENT ) continued



     A newer, more flexible ( read as less Neanderthal, approaching the
Bronze Age ) user interface is coming as soon as I get the time.

     Also in the works are features to save even more precious memory
below 640K by:
     - loading the primary shell ( COMMAND.COM ) into upper memory
     - relocating all DOS areas possible to upper memory, including
         FCBS=, FILES=, BUFFERS=, STACKS=, and LASTDRIVE=
     - allowing the lower portion of the video ram area to be switched
         in and out to expand DOS base ram beyond 640K but not inhibit
         graphics modes ( only for chip sets with video area support )

     I have ( I think ) found a way to *reliably* test for and list the
chip set in a machine. I will be including a separate program to do this
in the package soon. Of course, it will only recognize the chip sets it
supports, so a negative result will not necessarily mean you have a chip
set that will not be supported later.

     If there is enough interest, I will also write device-specific EMS
drivers for the hardware facilities in the EMS-capable chip sets. Please
Email or surface mail your thoughts ( no phone calls on this, please -
save those for support questions ).
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 24



REVISION HISTORY



     5.22 [02/20/92] - 'Unbroke' cache systems broken in 5.17;
                       ( Hopefully ) improved handling of false parity
                         errors during processing;
                       Added code to handle boot page for MR BIOS;
                       Fixed handling of certain embedded video roms;
                       Released UMB_EMS4 EMS simulator.

     5.21 [02/03/92] - Added 'User-Specified Available Memory' mode;
                       Revised doc for Windows 386 Enhanced mode.
     5.20 [01/15/92] - Important restriction noted for SUNTAC chip sets;
                       Fix for warm boot intercept on all chip sets
                         ( by George, I think he's got it! ).
     5.19 [01/14/92] - Added Silicon Integrated Systems 80386, ISA486;
                       Fix for warm boot intercept on all chip sets
                         ( this is getting really frustrating! ).
     5.18 [01/09/92] - Fix for warm boot intercept on all chip sets to
                         allow any disk cache to flush its buffers;
                       32K more upper memory with VGA on some chip sets.
     5.17 [01/06/92] - Added Texas Instruments TACT83000;
                       Fix for detection of expansion roms ( all sets ),
                         warm boot failures on certain BIOSs;
                       Found 16K to 32K more upper memory on some BIOSs.
     5.16 [12/30/91] - Fix for warm boot failure with another BIOS type;
                       Internal code restucturing in preparation for
                         future enhancements;
                       Introduction amplified to include tutorial on
                         different types of extended / expanded / upper
                         memory management.
     5.15 [12/24/91] - Added Sun Electronics SUNTAC ST62CS24, ST62CS25;
                       Fixes for parity errors during DMA test and warm
                         boot failures with some BIOS implementations.
     5.14 [11/27/91] - Relaxed all chip-set-verification checks to avoid
                         problems accepting some BIOS setups as valid.
     5.13 [11/23/91] - Added Texas Instruments TACT82S411, UMC UM82C210;
                       Added DMA verification code and warning message;
                       Documentation expanded and reorganized (again!).
     5.12 [11/19/91] - Fix for OPTi HiD/386, HiB/486 memory remapping.
     5.11 [11/17/91] - Fixes for OPTi Sx/AT, Sx/AT Cache, DX/BB PC/AT;
                       Relaxed validation check for Chips & Technologies
                         CS8230, CS8231, CS8233, and CS82310;
                       Documentation updated for various chip set IDs
                         from Chips and Technologies.
UMB_DRVR.DOC       Version 5.22             02/20/92            Page 25



REVISION HISTORY continued



     5.10 [11/12/91] - Added Chips & Technologies PEAK/DM,
                         OPTi Sx/AT Cache, HiD/386 AT, HiB/486 AT;
                       Fixes for VLSI Technology TOPCAT / Intel 82340,
                         special conditions remapping extended memory
                         on Chips & Technologies NEAT, LeAPset and SCAT,
                         miscellaneous logic improvements;
                       Documentation updated and reorganized.
     5.09 [10/25/91] - Fix for VLSI Technology TOPCAT / Intel 82340.
     5.08 [10/14/91] - Fix for boot page special condition.
     5.07 [10/13/91] - Added VLSI Technology SCAMP,TOPCAT / Intel 82340.
     5.06 [10/12/91] - Added Elite Microelectronics Eagle, Falcon.
     5.05 [10/09/91] - Added OPTi Sx/AT, DX/BB PC/AT, 386WB PC/AT,
                         486SXWB PC/AT, 386/486WB EISA.
     5.04 [10/02/91] - Added ETEQ Micro COUGAR II.
     5.03 [09/21/91] - Added Chips & Technologies 386/AT,
                         386/AT Cache, PEAK, SCAT, ELEAT;
                       Removed setup requirements.
     5.02 [09/12/91] - Added FOREX FRX32C300;
                       Added support for use of 'boot page' area;
                       Fix for VLSI Technology VL82C200;
                       Default all roms shadowed.
     5.01 [09/04/91] - Added VLSI Technology VL82C200.
     5.00 [09/01/91] - Support for Chips & Technologies NEAT, LeAPset;
                       Original release version.

                   ***** END OF DOCUMENTATION *****
       UMB_DRVR.SYS, Version 5.22 [ 02/20/92 ] Registration Form
                ***** Please Type or Print Clearly *****


        Name:____________________________________________________

        Address:_________________________________________________

                _________________________________________________

        City/State_______________________________________________

        Zip/Postal Code__________________________________________



  ***** Telephone number_________________________________________
  *   *
  *   * Email system / routing / ID______________________________
  *   *
  *   *      ____________________________________________________
  *   *
  * O * Computer description, configuration, chip set, etc.
  *   *
  * P *      ____________________________________________________
  *   *
  * T *      ____________________________________________________
  *   *
  * I *      ____________________________________________________
  *   *
  * O * Comments_________________________________________________
  *   *
  * N *      ____________________________________________________
  *   *
  * A *      ____________________________________________________
  *   *
  * L *      ____________________________________________________
  *   *
  *   *      ____________________________________________________
  *   *
  *   *      ____________________________________________________
  *   *
  *****      ____________________________________________________



        Cost ( U.S.Funds ): $25 ( no credit cards )

        Mail to: Christopher Blum
                 1022 East Wayne Avenue
                 Wooster, Ohio 44691
