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:	<Pine DOT SUN DOT 3 DOT 91 DOT 961229092751 DOT 10388P-100000 AT is>
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 <eliz AT is DOT elta DOT co DOT il>
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?

- Raw text -