Far out man!  I just played Master of Orion for about
an hour and it worked great with this version.  Not
good with mi.com, however... weird characters and a
manic counter spinning away at the very bottom of the
screen... BONG HIT! Gotta reboot.

Charlie
 
--- Michael Devore <[EMAIL PROTECTED]>
wrote:

> Uploaded to
> ftp://ftp.devoresoftware.com/downloads/emm386 are
> the files 
> emmx15.zip, EMM386/HIMEM mostly executable package,
> and emms15.zip, 
> EMM386/HIMEM mostly source package.
> 
> As with the previous release, EMM386 version 1.15
> contains a significant 
> number of both fixes and enhancements.  It is
> recommended for anyone having 
> any problems with a previous EMM386 release, or who
> thinks their copy of 
> EMM386 could be operating incorrectly.  User
> feedback on problems is vital 
> to further bugfixes.
> 
> Version 1.15 EMM386 adds support for VDS function 2,
> to allow the Fast 
> Tracker application to execute without failure.  It
> fixes an error in EMS 
> function 53h, so that PCTool's MI program will not
> crash.  It fixes a 
> long-standing error in EMS function 58h, to allow
> Quarterdeck's Manifest 
> program to properly display EMS information.  It
> allows Doom to operate 
> without use of the NOEMS option.  Other problematic
> applications may also 
> be affected by these changes.  Plus, EMM386 version
> 1.15 adds support for 
> several lesser EMS 4.0 functions, and reworks
> sections of VCPI code, 
> including fixing a problem with EMM=#### option
> values greater 
> than  approximately 261000.
> 
> The code for several low-level operations was
> modified.  Tests with DOS 
> extended applications (i.e. using VCPI) to ensure
> compatibility is recommended.
> 
> An optional more in-depth description of the changes
> follows.  Users only, 
> cut here...
> 
> Previous version 1.14's new EMS function 53h support
> broke PCTool's Memory 
> Information program because it wrote the handle
> information to the wrong 
> area of memory, overwriting critical areas of either
> DOS or MI.  Masters of 
> Orion still works.
> 
> The Fast Tracker program -- version 2.09 tested --
> would fail because the 
> EMM386 VDS option did not include support for
> function 2, basic 
> identification and flags.  FT tests okay in EMM386
> 1.15, at least as far as 
> buttons working.  I don't have a clue how to use for
> real work.
> 
> EMS function 58h, subfunction 1, did not properly
> return the number of EMS 
> mappable pages.  The bug caused Manifest to fail to
> display most EMS 
> information properly and crashed the Benchmark
> selection.  This was 
> fixed.  Timings still crash on my machine because
> it's too fast for MFT.
> 
> Support for several lesser EMS 4.0 functions and a
> few cosmetic source code 
> changes were made based on Eric Auer's contribution.
> 
> Specifying EMM=#### amounts greater than around 256M
> (261000), would 
> overflow and limit EMS and VCPI to the overflow
> amount, although the full 
> XMS allocation was made.  This was fixed and VCPI
> allocations were limited 
> to a maximum of 511M.   Intelligent DOS extenders
> can still use XMS beyond 
> that limitation in addition to VCPI allocations for
> their memory needs 
> (though needing more than 511M is pretty scary). 
> Increasing the VCPI 
> maximum is theoretically possible, but would require
> uncoupling the EMS 
> memory available report from the VCPI memory report,
> and probably isn't a 
> good idea.  More on this in the following
> discussion.
> 
> Doom would break if the NOEMS option of EMM386 was
> NOT specified, for 
> fairly complex reasons.  This was a consequence of
> the version 1.14 change 
> wherein I modified the VCPI protected mode entry
> code to use the server CR3 
> linear address space.  This was done so that server
> accesses of extended 
> memory would be relative to server memory addresses
> and not a potentially 
> completely different memory area based on client
> memory mappings.  Right 
> idea, bad choice.  Doom failed because its client
> stack, used by the 
> server, was not in the same memory space as the
> server.  As it turns out, 
> since EMS and VCPI allocations are indirectly
> manipulated through tables in 
> shared memory space, there is no need to change to
> the server CR3 
> address.  The CR3 change was reverted to pre-1.14
> status, which made Doom 
> happy again.  By the way, some bored individual
> might volunteer to update 
> the comp.os.msdos FAQ which says FreeDOS doesn't
> work with Doom.
> 
> Why did Doom work with the NOEMS option?  Because
> NOEMS would throttle the 
> free EMS memory report back down to one page, which
> Doom detected and 
> changed to allocating all its memory through XMS,
> which didn't go through 
> VCPI allocations in protected mode.   In case anyone
> wonders about the type 
> of bugs that make professional programmer debugging
> types get prematurely 
> bald and wrinkly, this is an excellent example.  The
> NOEMS/VCPI topic leads 
> to the final point...
> 
> The NOEMS option no longer throttles the free EMS
> memory report in function 
> 42h to one page.  Why not?  Because Microsoft EMM386
> version 7.x doesn't, 
> and because the VCPI specification recommends using
> the EMS memory function 
> to determine available VCPI memory.  Why did FreeDOS
> EMM386 originally 
> throttle the free EMS?  Because NOEMS option is
> supposed to mean no EMS 
> usage allowed.  Obviously, Microsoft didn't get the
> memo.  One page was 
> originally left to allow VCPI detection by
> successful single page 
> allocate.  Now, even with NOEMS all available
> EMS/VCPI memory is reported 
> in function 42h.  Up to 7fffh 16K-sized pages, or
> 511M.  The high bit is 
> left clear for dumb programs which use signed
> instead of unsigned 
> compares.  Similar to the way Disney's Aladdin
> program does on >32M of XMS, 
> causing Aladdin to fail on higher memory machines
> unless HIMEM's /MAX 
> option is used or external XMS allocations are made.
>  Walt would kick 
> somebody's butt for that.
> 
> Hmm, Zombie Walt Disney kicking butt, now that would
> be a cool game.
> 
> 
> 
> 
>
-------------------------------------------------------
> 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
> [email protected]
>
https://lists.sourceforge.net/lists/listinfo/freedos-user
> 



                
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 


-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to