Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
emmx220.zip, EMM386 version 2.20 memory manager, mostly executable files;
and emms220.zip, source code files.
This release of EMM386 and HIMEM has several changes and fixes, two of a
low-level nature, but at a guess, relatively few current users will be
affected. Two bugfixes in the advanced EMS 4.0 handle name function 54h
were made. EMM386 added support for A20 control, allowing old EXEPACKed
programs to work without LOADFIX. A minor XMS free block fragmentation
issue with EMS and VCPI was corrected. A fix to XMS API function 88h
reporting highest memory address off by a teeny. Due to changes in INT
processing, QEMU should now work with EMM386 and CTMOUSE (this is untested).
Four of these five issues were found by Japheth. In keeping with my past
unilateral and officially unsanctioned declarations, I hereby proclaim
Japheth to be FreeDOS Contributor Of The Month. All hail Japheth.
A glutton for further information? Read on.
EMS 4.0 function 54h subfunction 0, get all handle names, didn't place
correct information in the returned buffer. Subfunction 1, search for
handle name, was naughty and failed to search the right string. However,
almost nothing uses the advanced EMS handle name management -- besides the
test program used, I think I've seen exactly one EMS-based program which
would use the functions, but not critically depend on them -- so the
bugfixes are mostly for forms sake.
EMM386 now supports the global and local A20 control functions. Previously
it would inhibit A20 disable so as not to map itself out during its
operation, turning the computer into an inefficient bread toaster. Rather
than actually turn off A20, EMM386 simply maps the first 64K address space
into the HMA area on an A20 disable call. This approach allows EMM386 to
keep working while allowing it to support programs which were compressed
with the annoying EXEPACK, since EXEPACK counted on wrapping from high
addresses to low addresses and the FreeDOS kernel adjusts for that by
turning on and off A20. Eric Auer provided most of this idea, so he is
declared runner-up FreeDOS Contributor. I think the prize for that is a
pack of stale chewing gum, but I haven't checked the rules recently.
Note that A20 control functions do give one an interesting new way to crash
the computer should one fool with them indiscriminately, since mapping out
the HMA memory when DOS Is loaded leaves a nice 64K hole filled with
garbage where most of DOS used to live. Also note that to do this, an
unused EMS function (3fh) was co-opted for FreeDOS use. That's the way
QEMM does it, and I figured if QEMM can do it, so can we.
The EMS/VCPI allocator in EMM386 will now walk XMS blocks after freeing a
shared XMS block and trying to merge any adjacent free blocks it
finds. Previously, fairly minor fragmentation of the free block area could
occur. While this would not cause failure of applications, it could prove
annoying to advanced programmers or programs.
XMS function 88, highest memory address was still not quite right. It
usually reported one byte too high of an address. Actually, the whole
lower word was being zeroed, but since most memory comes in 64M increments,
that part of the problem was never noticed and only the highest+1 byte bug
would be seen. I don't think many, if any, programs use this value, but it
was sloppy coding that broke spec and needed fixing. I blame my
garbageman. Not that my garbageman wrote or had anything to do with the
code whatsoever, but I haven't blamed him for anything yet, and he'll never
EMM386 properly turns off the real mode INT flag inside it's protected mode
processing routines before transferring to the interrupt. Hopefully Qemu
now works with CTMOUSE. Feedback on that point is appreciated. That's the
only thing reported which is affected by the change, although theoretically
other situations may exist. Probably do. Like the song says, it's a big
old goofy world.
Oh yes, I changed two comments in EMM386C.C from /* to #if 0. Not because
I think it really needed to be done, or because I think it's of much
use. No, I did it because I am broken and feeble old man who ran out of
jokes for why not to do it long before its cheerleader(s) ran out of pixels.
Since low-level changes were made to this version of EMM386, please keep an
eye out for any problems and report them as soon as you can. While I don't
anticipate new problems, I certainly recognize the perversity of the
universe to make them happen. It's possible that the expanded A20 function
support, the IF status modification, or coding changes will wreak havoc in
one fashion or another. I'll post a quickfix release if anything
immediately crashes in a semi-spectacular way.
Will this version of EMM386+HIMEM be in the initial FreeDO 1.0 release? I
dunno, but judging by the announcement, I'd guess not. Probably not a big
deal, the EXEPACK issue is the most likely to bite new users. And the
mouse stuff for Qemu users.
Finally, this message is sent with the fervent wish that SourceForge won't
delay it by 24 hours like it did two of my last e-mails.
Time to work on documentation.