Mail Archives: opendos/2000/11/27/18:09:07
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: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
> Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
> -------------------------------------------------------------------
- Raw text -