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: References: <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 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