New EMM386 with 511M EMS support

Michael Devore writes:

Offered for anonymous FTP download at ftp.devoresoftware.com/downloads is the file EMMMOD.ZIP. This file contains proposed modifications plus one or two bugfixes to EMM386 and related files to enable it to support large amounts of EMS memory in conjunction with HIMEM64. It is based on the timely and useful English translation of comments in EMM386.ASM by Imre Leber, as approved by Tom Ehlert. The new file is called EMM386EN.ASM. Both source and uncompressed EMM386.EXE is present in the ZIP file. Here is the obligatory paste from header comments, followed by general remarks and detail:

Michael Devore's changes are not copyrighted and are released to the public domain. This does not affect copyright on the rest of the code.

Two bugs uncovered in other projects, at least in my version of FreeDOS, should be noted early. First, MEM, like EMMTEST, detects an EMS driver incorrectly and fails to report the EMS driver but does report the EMS memory. The problem is that MEM/EMMTEST grabs the full INT 67H vector address and adds 10 to it to find the EMMXXXX0 signature. That is not per spec, and can fail if the vector offset is nonzero, as was the case on my machine. Per EMS spec, only the segment value of INT 67H should be used, with a fixed offset of 10. I've corrected the code to work properly in EMMTEST.C.

Second, I noticed that DIR /OD reports midnight-based times as later than other hourly times. If not already fixed, someone might want to look into fixing the minor bug -- I must decline any command shell work myself.

Back to EMM386, I modified the MAKEFILE and provided an alternate library for TCPP 1.0 compiles, but my ASM and C source changes should be backwardly compatible to the maintained TC 2.0 -- I think. The changes were more extensive than with HIMEM, but should remain portable within the TCC family. Any problems there, please let me know. For ease of my testing, I also set EMM386 to always use all memory and turned off the default NOKILLABOVE64M switch since it will be a temporary condition that goes away once EMM386 is stabilized. Of necessity, quite a bit of source code was changed in the EMM386 files along with a few text tweaks for better comprehension and feedback, but I tried to minimize the overall violence.

Miscellaneous detail:

The new EMM386 reports as an EMS 4.0, but the only new API added was 5Ah (allocate pages and handle, zero pages allowed). The rest of the EMS 4 API calls return an unsupported error code, but will be added as needed or requested.

Some versions of Tlink are broken and can take segments out of their extremely important declared order. To fix this the EMM386EN.ASM DATA segment was renamed MONDATA, for Monitor DATA. Apparently Tlink confuses the bare DATA name probably due to either DGROUP or the later _DATA, and places it in the wrong place.

It was necessary to modify USEFUL.C so that GetValue() returned a long to enable greater than 64M value requests. Since this file is frequently used elsewhere, perhaps a GetLongValue() or somesuch should be added instead.

The EMM386 iterated halving approach when there is insufficient memory to fulfill the EMM= request is a bit drastic, particularly at higher amounts. If you request 80M of EMS and 70M of extended memory is available, you will only be given 40M. Perhaps the iteration could be changed to -20% or -25% or use a simple graduated scale on fulfillment attempts?

On my own machine, I am running 70M of EMS (EMM=70000). Included in the EMMMOD.ZIP file is a 10-minute hack program I wrote called TEST, source and EXE, which simply allocates 65M of EMS pages, maps each of them in starting at the topmost going down and writes a unique running signature to the first and last word of each page. It then remaps in each page starting topmost again and checks if the signature is still there. The test passed on my machine. Borland's EMSTEST also worked properly, although it does overflow the megabytes reported available from 64M.

Please remember these changes were only tested on one machine. There could easily be problems with other configurations. If so, please let me know.

I think that covers the main items. When and if the latest EMM386 modifications are accepted by maintainer and are stabilized I'll look into adding VCPI support to EMM386.