This EMM386 version 1.14 update contains a number of revisions and is generally recommended for everyone. It corrects errors when using the NOEMS option with the EMM=#### option; it adds support for EMS function 53h for the Master of Orion game; it fixes a bug in INT 15h, function 87h; it supports emulation of the INVD instruction; and has a number of internal changes.
Since there are a large number of code revisions, there exists a nontrivial probability of introduced error and incompatibility. Please report any new, or old, problems.
Details of changes follows. They are very long and quite optional to read. Those interested may read until their eyes glaze over and they achieve the level of coma desired. Maybe I can spice it up.
Of most general interest, the NOEMS option was broken if EMM= option was present. NOEMS would ignore the EMM=#### setting and blithely use its own threshold values. This could cause an inordinate number of problems for people trying to set proper values for their VCPI-using applications without having an EMS presence. Very annoying, sufficiently so that I am slightly surprised users did not create a web-board simply to post gibes about my looks, intelligence, and sexual abilities. Although, based on the amount of spam I get concerning the last point, perhaps they did exactly that.
Matching the previous WBINVD support, the INVD instruction is emulated in EMM386 because it is illegal in V86 mode. INVD is present in at least one DOS program and hopefully not many more. Personally, every machine I've tried locks up on a INVD instruction, probably due to the fact it is an unsophisticated cache flush which can lose data, but hey, I'm not your mother. Use INVD at your own risk.
INT 15h, function 87h, copy extended memory had its boundary check off by one byte, so that valid memory moves would be discarded if the byte count to transfer was at the segment limit, instead of only beyond the limit. This error, as well as the need for INVD emulation, was discovered by Eric Auer. Accordingly, I unilaterally declare him the FreeDOS Developer/User Of The Month for service above and beyond. Huzzah! Huzzah! I suggest tangible thanks be sent via donation at http://sourceforge.net/users/mceric/ to help reach his dream of owning a Lipizzaner Stallion. Now, stop sending me so much e-mail.
The game Masters of Orion -- and potentially other programs -- required that EMM386 support EMS 4.0 function 53h, subfunction 0 and 1, get/set handle name, to operate. The function, fairly obscure and unused, was stubbed out in previous EMM386 releases, but handle name space and management was added to this release. With this enhancement the Masters of Orion game works on my machine. Related support was not added for function 54h, subfunction 1, search handle name, because it wasn't needed and because I'm a lazy bum.
Moving to internal matters, dark and dreary...
The slop factor when allocating EMS/VCPI memory was reduced from 64-96K down to 32-64K due to better precision in specifying required memory. Slop is present to allow for rounding to hard boundaries during initialization and future growth of EMM386 code. I decided that 64K+ extended memory was too much to give up for low memory machines which might notice the difference. If the slop is cut too far, errors might surface, so let me know if weird things happen.
A few internal alignments, such as with DMA buffer, were made to theoretically improve performance.
The VCPI server routine now switches to the EMM386 linear address space -- i.e. changes CR3 -- when directly called from the protected mode entry point. It may not be necessary since no application demonstrated a need for it to date, but I couldn't shake the feeling that using the CR3 set by the client prior to the VCPI protected mode call could lead to high memory VCPI block allocations that pointed to the wrong address. Conceivably, clients always set the proper CR3 before calling the entry point, but nothing in the VCPI spec says this is necessary. The entry stack, however, remains unchanged because a) I couldn't get stack changes to work (see below) and b) the most common use of the protected mode entry point does require the stack to be in shared low memory and this may propagate to the other functions.
The undocumented function ENDALLOC was added and any critical 24-bit loads were changed to 32-bit so that EMM386 non-VCPI routines can function within the full 4G address space, rather than the first 16M. ENDALLOC forces EMM386 to load and allocate memory at the end of XMS rather than at the beginning, for dumb programs which might need lower address XMS blocks. HOWEVER, use of VCPI requires that the EMM386 VCPI server routines be mapped into the first 4M of memory for VCPI client sharing (EMM386 itself only maps the required 1M low memory+optional 1M ). Due to this VCPI requirement, the ENDALLOC option causes any program which uses VCPI to crash horribly under EMM386, because the server routines are loaded too high in memory for VCPI interaction. Which leads me to my final point/rant.
I tried. I really did. I wanted to make EMM386 work as a VCPI server and still be loadable anywhere within the full 4G extended memory address space. This would allow people to place drivers between HIMEM and EMM386 in CONFIG.SYS, moving EMM386's load address above its normal location, and still have EMM386 work as a VCPI server. After three false starts, I figured that if I stuck a VCPI server entry point routine in low memory code aliased by the pre-existing low memory data used by EMM386, then I could reload the descriptor tables with EMM386's high memory address, rejigger selectors, jump to main server routines, and everybody would be happy.
Doesn't work. The client entry condition refuses to allow me to switch back to my own stack originally passed to the client as one of the three GDT entries available to the server. No matter where, no matter how valid, not matter if verified, stack changes puke blood and die. And then it crashes on my jump to high memory attempt. Blew a lot of free time on it, no luck. So screw it, I'm done. Any hotshot young hacker wants to make it work, be my guest. It's not like there is a pack of VCPI groupies out there waiting to reward success. And if they are, they're twenty years and one marriage too late. In the meantime, don't load drivers which use XMS between HIMEM and EMM386 if you want VCPI to work.
Consequently, ENDALLOC will remain an undocumented test option of limited usefulness outside the EMM386 development sphere.
On a final note, all this work has made the chance of EMS/XMS pool sharing feature appearing by the end of February far less likely. I hereby exercise the option to change my mind and say it probably will arrive before March 31, 2005.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
