Message-ID: From: "Da Silva, Joe" To: "'opendos AT delorie DOT com'" Subject: RE: EMS (was: BASIC & EMS, nee Optimizing CONFIG.SYS...) Date: Tue, 28 Nov 2000 10:13:31 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Reply-To: opendos AT delorie DOT com Hmmm ... Perhaps I have my terminology "mixed up"? When I referred to "cloaking", I was referring to an EMS-specific feature of QEMM (IIRC), whereby the EMS page frame was "on top of" the VGA BIOS address range. The "cloaking" feature then intercepted the EMS and VGA's API, switching-in whichever memory (page frame or VGA BIOS) was required ... at least this is the way I remember this feature being described, in a book called (IIRC), "DOS beyond 640K". I have also made a comment about DPMS (licensing), in response to another message ... so I won't repeat it here ... W.r.t., EMS overlapping F000-F7FF, I presume your comment about this (below), indicates that this is more "stable" than using this address range for general UMB stuff ... (?) Regards, Joe. > -----Original Message----- > From: Matthias Paul [SMTP:PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de] > Sent: Tuesday, 28 November 2000 3:41 > To: opendos AT delorie DOT com > Subject: RE: BASIC & EMS (was: Optimizing CONFIG.SYS...) > > On Mon, 27 Nov 2000 Joe Da Silva wrote: > > > The only real problem with EMS, is the 64K hole it makes in > > the UMB region (sometimes 32K, as noted by M.P.). > > Perhaps (I don't know how much work is involved), Matthias could > > add "cloaking" to EMM386 - that would help GREATLY (bug fixes > > are more urgent, of course)! > > In fact, there exist issues of EMM386 (available in the SDK) which > come with an embedded DPMS server. > > But CLOAKING was developed by Helix (for their Netroom memory > manager). Helix is now part of Network Associates (or was it > Computer Associates???), and Netroom no longer exists as far as > I can tell. CLOAKING and DPMS are very similar in concept and since > CLOAKING also support the DPMS API (introducing a few peculiarities > with their implementation), I would call CLOAKING a superset of DPMS. > However, I have no info, if they licenced DPMS from Novell, or did it > themselfs. > > Helix had a number of drivers which utilized CLOAKING, including > a disk cache and a MSCDEX derivative, but the only 3rd party program > I am aware of that uses CLOAKING is the Logitech LMOUSE driver > since ca. 6.50+. Current DOS issues of that mouse driver still support > the CLOAKING API, but do not provide the CLOAKING.EXE driver any > more, but you can use that of an older issue. > Is anyone here aware of other drivers using CLOAKING? > > Well, I think it would make more sense to change LMOUSE to use > DPMS instead of CLOAKING, since alot more 3rd party programs are > using DPMS. It might also be a good idea to add DPMS support > to CTMOUSE to have > > 1. a freely available example source how to "DPMS" an existing driver > (so others can use that to adapt the techniques to their own > drivers) > > 2. to still have a tiny mouse driver when Logitech decides to > abandon support of their DOS driver (they might have done > already by now, at least this was appeared to me due to > their neclectance to fix a few minor issues, I reported > a while back...) > > > Also, I wonder if, on machines which can use F000-F7FF for > > EMS, this address space can simply be added to the UMB > > "pool" instead? > > Try EMM386 /USE=F000-F7FF /RAM=F000-F7FF > > But if you also have an EMS frame somewhere, I suggest to move > that to E800h instead of using the F000h-F7FFh range as > permanent upper RAM. I have made better experiences this way. > > Matthias > > > ------------------------------------------------------------------- > Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany > eMail: > Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html > -------------------------------------------------------------------