delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/01/26/10:00:37

X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
From: kala AT sankya DOT com (Babu Kalakrishnan)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DPMI Interrupt latency ?
Date: Sat, 26 Jan 2002 20:19:02 +0530
Lines: 58
Message-ID: <slrna55geu.4sn.kala@ganga.sankya.com>
References: <slrna5524i DOT 43o DOT kala AT ganga DOT sankya DOT com> <4098-Sat26Jan2002151201+0200-eliz AT is DOT elta DOT co DOT il>
NNTP-Posting-Host: ppp-177-140.bng.vsnl.net.in (203.197.177.140)
X-Trace: fu-berlin.de 1012056554 37434224 203.197.177.140 (16 [76750])
X-Orig-Path: kala
User-Agent: slrn/0.9.6.2 (Linux)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On Sat, 26 Jan 2002 15:12:01 +0200, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:

>> Could anyone tell me what is the order of delay (in clocks) required for
>> the CWSDPMI server to reflect a hardware interrupt from Real mode to the
>> protected mode handler ?
>
>You can find some information about this in the DJGPP FAQ, sections
>18.9 and 18.11.
>
>> Any suggestion regarding which DPMI server would provide me
>> the best latency figures would also be welcome.
>
>Section 18.11 in the FAQ has some suggestions or minimizing the mode
>switches.

Thanks for the quick response Eli. I've followed most of the pointers
provided in the FAQ. I'm experimenting with PMODE/DJ as well. I was
basically looking for some ball-park numbers. (Even Intel documentation
doesn't specify the overhead for mode-switches in terms of clock
cycles). 

Another option I was considering was installing a memory manager 
(operating in V86 mode instead of Real mode) - but since the FAQ
specifically mentioned EMM386 increasing latency than reducing it, I was
a bit wary about this.


>> Would it be possible
>> to hack the DPMI server source code so that real mode handler can access
>> memory above 1MB using 32 bit pointers ?

>I don't think so: in real mode, only 20 bits of the address are put
>on the bus.  While you could do what you want in V86 mode, I doubt
>that you'd want to, since V86 mode increases the latency that you
>want to minimize.

Though the Intel docs seem to suggest otherwise, all processors since
the 386 are physically capable of addressing memory upto 4GB
irrespective of the operating mode. And the undocumented Flat Real mode
(or "Unreal" or VOODOO mode as it is called) allows you to access it.
(See http://nondot.org/sabre/os/articles/ for various articles on this -
I've used it in the early days of 386 and it does work). 

But in a DPMI environment, the DPMI server sets up the segment limits to
0xFFFF when switching to Real mode. And to switch them back to 4GB
limit, you'd have to enter protected mode once again which defeats the
whole purpose :-) That's the reason why I was looking at patching the
DPMI server itself to setup the Real mode switch in such a way that
segment limits are 4GB. But unfortunately I don't have enough time
available at my disposal to study the full source code - and since I
noticed that several extender authors are frequent contributors on this
list, they might be willing to give a helping hand :-)

Regards,

BK


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019