Uploaded to ftp://ftp.devoresoftware.com/downloads are the files
emmx13b.zip, EMM386 mostly executable package, and emms13b.zip, EMM386
mostly source package.

These versions follow the latest EMM386 fileset template directory and
naming conventions.  EMM386 supports [in|ex]clusion ranges to FFFF
without rejection.  Excluding all UMB's no longer turns off the VDS
option. The unimplemented VDS function feedback was corrected for
function values >9.  /MAX was re-added to HIMEM command line
feedback.  A minor one-byte too far check for DMA buffering was
corrected.  An undocumented and likely temporary MEMCHECK option was
added to EMM386.

MEMCHECK was added after discovering that USBASPI.SYS could provide
out of range values to INT 15h function 87h block move, causing a
reboot.  The cause of this out-of-range value is not known, as it's
buried deep in the application, ultimately accessed through an indexed
lookup table.  MEMCHECK simply checks block moves and rejects any to
or from addresses beyond current extended memory limits.  This stops
USBASPI.SYS from rebooting systems, but unfortunately apparently
doesn't fix it enough to make it work properly.  Maybe I'll be able to
figure out what's happening with it and what is at fault when I get my
Lexar JumpDrive from Amazon.

EMM386 VDS operation for its supported API subset was checked against
MS EMM386 behavior and found to have no errors, other than MS EMM386
mapping the 1M+64K HMA area to 0:0 since it turns A20 off and on
dynamically.

Everyone who uses UMBs with disk, network, and other DMA-based drivers
should repeat this mantra:  "Failure to operate to expectations does
not imply a bug."  EMM386 can catch only certain types of DMA access
to remapped memory.  DMA writes to physical machine addresses;
programs write to linear addresses.  By trapping standard DMA ports,
EMM386 tries to resolve conflicts by changing addresses on the fly and
using buffering when it sees a read or write to remapped memory.
However, if a piece of hardware uses other ports it will bypass this
check.  Also, I've uncovered at least a couple ways of using the
standard DMA ports that EMM386 does not compensate for -- which may or
may not be correctable but requires a testable suspect situation
on-site to modify.  Different uses of UMBs, with our without VDS, may
always fail with certain hardware setups.

To help determine what and when to report an error with EMM386, please
use the following guidelines:

If EMM386 fails at startup with all potential UMB's excluded
(X=A000-FFFF) on your machine, with or without VDS, there is a major
problem and you should let me know.

If EMM386 reports an "unimplemented VDS function" when VDS is
specified, let me know and I'll try to add support for that function.

If EMM386 fails with only certain UMB's included and works with them
excluded, I probably can't help you.  Something doesn't like that
upper memory block usage and it's likely specific to your machine.

If EMM386 fails with certain applications loaded high which work
loaded low, I also probably can't help you.  Some applications are
destined not to live in remapped memory.  However, if you send me the
application and I can duplicate the problem here, I may be able to
determine what's failing and why.

If you have strong suspicions of a bug or incompatibility outside of
the above guidelines, let me know and I will see what can be done
about it.