From: aho450s AT nic DOT smsu DOT edu (Tony O'Bryan) Newsgroups: comp.os.msdos.djgpp Subject: Re: Calling real mode far procedures Date: Sun, 29 Dec 1996 14:37:04 GMT Organization: Southwest Missouri State University Lines: 25 Message-ID: <32c67f4b.1170160@ursa.smsu.edu> References: NNTP-Posting-Host: forseti.i31.smsu.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp On Sun, 29 Dec 1996 07:29:35 GMT, Eli Zaretskii wrote: >Why would you need to avoid calling `__dpmi_int'? It doesn't add any >significant overhead to the calls. When I used this method in my 16-bit real mode apps, the screen update speed was significantly improved by calling this function directly. Since __dpmi_int() needs to do everything the real mode interrupt call does, plus switch from PM -> RM, I assume that the switch will take slightly longer. My goal is to squeeze all the extra clock cycles possible from the bank switch. I have another idea which may work: Since the bank swap code is generally no more than a dozen bytes of real mode machine code with no segment overrides or such, I might be able to move the real mode code into my PM code-space, convert the real mode code to PM instructions at startup, and call it directly as a C function. This would make the bank swap code 100% portable (since it's taken directly from the BIOS of the card actually being used) and eliminate the two biggest speed drains (RM -> PM switch and interrupt processing) at the same time. Is there any special processing I need to do to allow machine code to directly access I/O ports, or is the hardware I/O bitmap under DPMI already set to allow direct I/O to all ports?