Date: Sun, 29 Dec 1996 20:14:08 +0200 (IST) From: Eli Zaretskii To: "Tony O'Bryan" cc: djgpp AT delorie DOT com Subject: Re: Calling real mode far procedures In-Reply-To: <32c67f4b.1170160@ursa.smsu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.