From: "John S. Fine" Newsgroups: comp.os.msdos.djgpp Subject: Re: HELP! Assembly language dual mode interrupt handler for djgpp program Date: Mon, 01 Mar 1999 21:07:57 -0500 Lines: 61 Message-ID: <36DB47FD.16E@erols.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 1A9US/OeFJtyjoXoUesss/HJi8/QMa3cEl3LT2QA4DY= X-Complaints-To: abuse AT rcn DOT com NNTP-Posting-Date: 2 Mar 1999 02:09:16 GMT X-Mailer: Mozilla 3.01 (Win95; U) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii wrote: > > The interrupts rate is so high (up to 20 kHZ), that I have to > > install both real mode and protected mode handlers. > > Are you sure? Did you try to get away with a protected-mode handler > alone? (See section 18.11 of the FAQ for some hints.) The dual RM/PM > setup is a lot of work (see below), so you want to be sure you actually > need it before you embark on that journey... I haven't tried doing any of this myself yet, but I have read a few things about it and gotten very confused by the statement that it is more efficient to have both rather than pmode only. Eli seems to be saying that pmode only might be efficient enough. (Which I think still implies that both might be more effitient). I can't understand why that would be true. When you are running "real mode" code in a DPMI program, you are not every actually running in real mode (are you?). You are running in V86 mode. When a hardware interrupt occurs in V86 mode, the interrupt gate always takes you to pmode (I'm assuming task gates aren't used for IRQ's). So regardless of whether you were interrupted from V86 mode or pmode, you get to the same pmode code before any software choices occur. That pmode code is deap inside the kernel of Windows or some stand-alone DPMI provider (or similar), so it is certainly possible that the code looks at what was interrupted and decides whether to try a V86 mode hook or a pmode hook first depending on what was interrupted, but that design doesn't sound useful or likely. Without a bizare design like that, I would expect it would try the pmode hook first and there would be no benefit to having a "real mode" hook as well. Since authoritative sources have come to a different conclusion than I did, I expect there is something about the way Windows or CWSDPMI or whatever is handling hooked interrupts, that I don't know. I am curious enough about this area, I really would appreciate it if someone would enlighten me. As to the original question of this thread, I assume you aren't trying to service those 20Khz interrupts in a DPMI program under Windows. You are in some lower overhead environment such as CWSDPMI. I think CWSDPMI is unprotected enough that it shouldn't be too hard to hook directly into the IDT for the desired IRQ. (If not, then there is a ring zero version of CWSDPMI, which lets you do whatever you want). If you hooked the IDT directly, then your pmode only service routine has to be faster than a V86 mode one under all conditions. I also expect that figuring out how to hook the IDT directly should be easier than writing a whole second version of your service routine (not to mention the code for allocating and accessing conventional memory). -- http://www.erols.com/johnfine/ http://www.geocities.com/SiliconValley/Peaks/8600/