Date:	Sun, 29 Dec 1996 20:14:08 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Tony O'Bryan" <aho450s AT nic DOT smsu DOT edu>
cc:	djgpp AT delorie DOT com
Subject:	Re: Calling real mode far procedures
In-Reply-To:	<32c67f4b.1170160@ursa.smsu.edu>
Message-ID:	<Pine.SUN.3.91.961229200603.11609A-100000@is>
MIME-Version:	1.0

On Sun, 29 Dec 1996, Tony O'Bryan wrote:

> 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'm not sure you are right here.  AFAIK, the DPMI function which enables 
you to call a real-mode far function (the DJGPP libc has a wrapper around 
it called `__dpmi_simulate_real_mode_procedure_retf') does almost 
everything that `__dpmi_int' does, give or take a few cycles used to push 
some extra words on the stack (since calling a real-mode function also 
requires a mode switch).  So I'd suggest that you profile your code 
before you decide to work around `__dpmi_int'.

> 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.

I'm not sure this is as easy as you make it sound.  How would you 
accomplish the ``convert the real mode code to PM instructions'' thing?

> 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?

You should have no problems accessing I/O ports from a protected-mode 
program, except on some platforms (like Windows/NT and DOSEmu) which take 
protection seriously and don't let you access the hardware directly.

- Raw text -