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.