Uploaded to ftp://ftp.devoresoftware.com/downloads are emm386.zip (uncompressed executable) and emm386sr.zip (source) with several changes related to UMBs, EMS, and rebooting. The ZIP files are dated April 26, 2004, actual files dated April 25.
EMM386 performs a warm boot upon a Ctrl-Alt-Del keypress. It changes the EMS driver identifier to EMMQXXX0 when the NOEMS parmeter is specified. It uses a 4K minimum upper memory block size, and it allows two optional parameters, X=TEST and I=TEST to better control UMB's. These changes to EMM386 were all feedback driven, so please note that your problem reports are important and can directly affect EMM386 behavior. Detailed discussion of the changes and associated philosophies follows: The keyboard handling code within EMM386 which detects Ctrl-Alt-Del keypresses now writes the value 1234h to BIOS data area 40:72h, to explicitly enable a warm boot, rather than rebooting based upon whatever value happened to be at that address. The original EMM386's explicit output to port commands to force a boot were removed and reboots are vectored through real mode BIOS address FFFF:0. The NOEMS parameter of EMM386 changes the EMS driver identifier to EMMQXXX0 to match the change to device driver name that was already made by EMM386 with NOEMS. This change allows TDSK and Turbo Debugger to run in a NOEMS condition since they attempt to use EMS after detecting a valid EMS identifier, and then failed because NOEMS did not support EMS functions they used. UMB's are now 4K-based instead of 16K-based, by popular demand. Besides direct request, another reason for the change is that the latest beta UMBPCI utility supports 4K UMB's and we need to keep the maximum number of people using EMM386 for best stability, rather than lose out to a more UMB-efficient free utility. This change means that smaller holes in the upper memory area can be used for UMB's. At /VERBOSE startup, the listing of UMB's is listed by 4K units and consequently you'll see a lot longer listing, but contiguous UMB's continue to be merged into one large UMB at the end. As a side consequence, the FC00 upper memory mapping change for reboots was changed to FF00 mapping. This 4K change probably wasn't all that critical, but the code involved wasn't that difficult to modify and everybody who commented wanted it, so I went ahead and did it. Finally, I added two new options which don't follow Microsoft standard. Why the heck did I do that so close to FreeDOS 1.0 release? And why do it now when there are still EMM386 options unsupported which are Microsoft standard? Simple reason: the options (well one of them) help eliminate known and reported compatibility problems with UMB's that an average user might find difficult to fix on his or her own. As the mantra goes, "any change which reduces problem reports is a good change." I tried to make them logically follow existing option behavior. The first option is X=TEST. This option tests all UMB blocks after X=<range> and I=<range> qualification by examining all bytes of the ROM block memory image. X=TEST will discard a block from being used as a UMB if it detects any byte value other than 0 or 0FFh, since those two values typically are found in unused upper memory. Is X=TEST really necessary? Unfortunately yes, at least for some machines. There exist PC's which place ROM code in the upper memory area, but without the standard ROM signature of 55h AAh. These aren't old moldy machines either. In a small test pool, at least two Pentium 4 class machines placed disk driver code in upper memory areas without using ROM signatures. Overwriting the ROM code obviously could cause serious problems and the standard EMM386 ROM-scanning method has no way to detect that code. X=TEST will detect the code and stop a UMB from being placed there. The paranoid may want to make it a default option. For symmetry, and because Bernd Blaauw really wanted it (plus he promised to slip me ten pre-euro guilders which sounded like a lot of money until I looked up old currency conversion charts), there is also an I=TEST option. This option is almost the opposite of X=TEST. It goes through all ROM images that EMM386 scans and, if there is a 4K image in the ROM which is all 0's or FFh values on a 4K boundary, I=TEST will re-include that area into a UMB. Obviously this can be dangerous if a ROM uses the 4K area of 0 or FFh values for its own purposes, so I=TEST is only recommended for risk-takers trying to squeeze out maximum UMB space. X=TEST and I=TEST can be used together, along with all other parameters including X=<range> and I=<range>. Remember, X is exclusionary, so X=TEST will never give you more UMB's, only the same number or less. I is inclusionary, so I=TEST will never give you fewer UMB's, only the same or more. As auto-tests, they are both overridden by I= and X= options. Therefore, UMB's are computed by this option priority: X=<range> (explicit exclusion of an upper memory area overrides the world) I=<range> (explicit exclusion overrides everything except where it conflicts with an X=<range>) X=TEST I=TEST If you decide to try X=TEST or I=TEST, please let me know if you lose or fail to gain expected UMB's so I can see whether there are additional byte patterns in your machine's upper memory I should test for. Already X=TEST has been modified to not check the last byte of a 4K block because there are ROM's (like mine) which stick a garbage byte value on the end. Also, let me know if the changeover from 16K- to 4K-based UMB's causes any problems. It works okay in limited testing with a few users. There is at least one user out there who continues to have problems with recent versions of EMM386, so if you have problems with EMM386 on any machine please let me know. The more data I have, the more likely a fix or work-around will be forthcoming. And I lied about the guilders. ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
