Mail Archives: djgpp/1996/12/29/13:24:54
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 -