Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the
files emmx206.zip, EMM386/HIMEM mostly executable package, and
emms206.zip, EMM386/HIMEM mostly source package.

This release of EMM386 has modifications attempting to reduce
conflicts with SCSI and VDS, along with minor internal tweaks.
Version 2.06 fixes a problem with the NOVDS option; corrects a problem
with applications, specifically PKUNZIP, that query EMS when the NOEMS
option is not present; and allows an expanded range with the I= option
for gaining more upper memory.  If you don't have problems with 2.05
and don't want the new stuff, you don't need to update to 2.06.

Going down the list...

The NOVDS option was broken, as previously announced.   Fixed.

The post-initialization patching out of the device driver entry point
for EMM386 was broken and caused crashing problems with PKUNZIP and
other EMS-querying applications via IOCTL functions unless the NOEMS
option was specified, also as previously announced.  Fixed.

In an attempt to clear up some problems with VDS, the VDS function
dispatcher is more forgiving.  If a VDS function is specified which is
reserved, but unused, the VDS dispatcher will pass the call along to
the original interrupt handler unchanged.  Will this make computers
with VDS conflicts work better?  No idea, it's just an attempt to
allow SCSI commands which do not directly intersect with VDS commands
go their way unhindered.  There may be -- and likely are -- conflicts
that cannot be resolved in this manner, but hopefully it helps out
some people.  And for all I know, there may remain a bug in a VDS
function that only certain computers encounter.   Untested do to lack
of a problem machine, hope it works.

The allowed I= ranges for EMM386 have been expanded to F000-F7FF.  You
may re-use this area at your own risk.  Some BIOS's are tolerant of
it.  I myself re-used F000-F1FF here to load a mouse driver with no
immediate ill effect (it looks like the computer stored the BIOS setup
screens and code there).  However, your computer may well crash, act
weird, or otherwise deviate from expectations when including anything
in the new ROM BIOS range, depending on what lives there.

The default MAX setting of EMM386 was lowered, yet again, to 120M.
Seems that TDUMP is unhappy with VCPI free amounts greater than 127M.
TASM works, TD works, TLINK works, not TDUMP.  It coughs up a rolling
error message about ignoring and losing VCPI pages.  Bogus, near as I
can tell, as VCPI allocations and free were stress tested for failures
up to 156M here, besides the other Borland utilities working fine.
But I give up.  It wants less VCPI, it gets less VCPI.  You can always
manually increase it to a larger value if you want.

Finally, the VCPI shared client/server GDT mapping in the first 4M was
reduced from 2M to 1.75M.  Because I can, because somebody wanted it
smaller, and because nobody else really cares.  Apparently some
drivers, like the well-documented (here) as stupid SoundBlaster, fight
over the lower 4M address space and this change gives them a larger
ring to fight in.  That's about as low as it's going to go though, so
device drivers, go nuts with that extra 256K.  Win one for the FreeDOS
fish flipper.