EMM386 has several enhancements. It adds support for the most-used API subset of VDS with the VDS option, allowing network drivers to be loaded high in UMBs. All moves to and from control and debug registers via standard registers (e.g. MOV DR3,ESI) are now supported in V86 mode, i.e. when EMM386 is present. EMM386 source was updated to support the 'M' and 'G' suffixes made by Aitor Santamarķa Merino for HIMEM, where those suffixes can be used. All command line options are listed in the EMM386 feedback. And, to quell past minor outrage, the ALTBOOT option was renamed NOALTBOOT.
If you previously used the ALTBOOT option -- which probably means you are a BreadBox/GEOS Ensemble user since that's the only currently known application which requires the option -- you should change your CONFIG.SYS EMM386 line to read NOALTBOOT rather than ALTBOOT. Users can specify ALTBOOT, too, but it simply operates as the default EMM386 condition of hooking the INT 9 vector for reboot processing and really does nothing. This solution was the best of those suggested to maintain MS-compatibility with the meaning of ALTBOOT while not changing the way EMM386 has worked for the past many years.
EMM386 now supports all opcodes of the form 0F0h 020h xx - 0f0h 023h xx, which is any move to and from a debug register (DRx) or control register (CRx) via a standard register (EAX, EDI, etc.) EMM386 does this by means of self-modifying code which sticks the actual opcode to be executed in the code segment via our friend the alias selector. Currently EMM386 attempts to reset the cache after the self-modifying code by the old standby of JMPing to the next instruction. I'm hoping this feeble cache flush/update method still works with all the newest CPU pre-fetch doodads. It did work on my Athlon XP 3000+ so maybe it's okay. If not, we'll probably have to implement code to a detect 486+ level chip and stuff in a leading WBINVD instruction if >386 or JMP if not, which is a dorky hack and I don't want to do it if we don't have to.
EMM386, via the VDS option supports the main locking functions 8103h and 8105h and their corresponding unlock options 8104h and 8106h. Actually, 8104h and 8106h do nothing and always report success since memory isn't really locked; it's never changed by EMM386 from its original mapping reported by 8103h and 8105h. Other VDS functions are not supported and will report to that effect. If you see one of those messages, let me know the numbers it reports and I'll add support if feasible.
Users of the VDS option to load network drivers or other DMA-based drivers in UMB's should be aware the VDS is a bit more shaky than things like EMS, XMS, and VCPI and was never as universally embraced and stabilized. Be aware that if EMS with EMM386 is voodoo, VDS is double-voodoo. Lots of complicated things going on with remapping memory, rebuffering of DMA on the fly, blah blah blah. The network drivers may work, they may not.
As always, should you have any problems let me know. Should you have a problem using VDS, unfortunately there is a good chance I may not be able to duplicate the problem since those are typically tied to a particular model network card or environment, and thus not be able to fix it. Que sera, sera.
------------------------------------------------------- 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://productguide.itmanagersjournal.com/ _______________________________________________ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user