ploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx13c.zip, EMM386 mostly executable package, and emms13c.zip, EMM386 mostly source package. Now then, no more name and directory changes. This version of EMM386 supports the option MEMCHECK (completely reprogrammed) to allow EMM386 to work with USB flash drives. It has been successfully tested transferring files to and from my Lexar 256M JumpDrive in FreeDOS, then to Windows XP. The new version also fixes a small bug in VDS function 8103h that will affect few. Other reported cosmetic bugs remain. If you wish to have EMM386 loaded and access a USB flash drive, you must specify MEMCHECK on the EMM386 command line in CONFIG.SYS, along with any other desired options. You should also have the USB flash drivers loaded, typically USBASPI.SYS and DI1000D.SYS. Those are the only two USB driver files tested in conjunction with this version. Tedious details follow.... MEMCHECK was rewritten so that when specified it allocates space for four scratch page tables, using an additional 16K of extended memory. If a memory block move in INT 15h function 87h is outside normal extended memory address ranges, MEMCHECK dynamically maps that range of memory to the scratch page tables -- two for source outside of range, two for destination outside of range -- and sets the proper page directory entry(ies) to point to the scratch page tables. This makes the memory accesses valid. Two page tables are used in case a block move spans a page table. USB flash drives use high memory values to map information in, address E8000000h is used on my system. Can't give much more information, the gory details of USB memory-mapping are unbeknownst to me. Tom Ehlert clued me in on this fact and that knowledge allowed me to rewrite MEMCHECK to work with (at least my) USB flash drives. The greatest drawback so far is that CuteMouse locks up the machine when USBASPI.SYS is loaded. However, this is true even when only HIMEM.SYS is loaded, or when the Microsoft version of HIMEM and EMM386 are loaded. Why CuteMouse doesn't work with USBASPI.SYS is difficult to say since USBASPI.SYS is closed source. I can say that here it locks up on the C205h INT 15h function to initialize the mouse. Appears that somewhere in BIOS accessing the ports 60-64h and EBh (delay) it winds up in an infinite loop looking for a port value. How the heck USBASPI.SYS goofs those up, no idea. Tragically, CuteMouse appears to be the only notable free DOS driver still out there, forcing a choice between mouse and flash drive. Sob. Aside from the above, I may see what can be done to make a FreeDOS-bootable USB flash drive, just because it seems like a pretty cool idea. There are references to having done this with Linux, so FreeDOS should be doable.