From:	sandmann AT clio DOT rice DOT edu (Charles W. Sandmann)
Subject:	DPMI support (fwd)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu (djgpp)
Date:	Wed, 2 Jun 1993 22:12:03 -0600 (CDT)

Forwarded message:
> From: Animesh Karna <karna AT pobox DOT upenn DOT edu>
> Subject: DPMI support
> Date: Wed, 2 Jun 93 14:58:15 EDT
> 
> I have some questions about the DPMI support in the latest DJGPP package:
> 
> -- Is there any way to get at the <1meg memory while in DPMI?  I
> understand that the 0xE0000000 remapping doesn't work.  Is it
> completely unavailable, or is it mapped to some other location?  (I guess
> it might be possible to call DPMI and set up a selector that includes the
> <1meg memory area, but I don't see any way to access memory in that
> selector in C/C++: it would have to be done in assembly language)

Yes, there is.  Blame me for inadequate documentation, I only sent DJ the
library routines at the very last minute.  I added three new routines:
  dosmemget( int low_mem_offset, int size, void *buffer)
  dosmemput( void *buffer, int size, int low_mem_offset)
  ScreenUpdate(void *buffer)
(declared in PC.H) and an assembly only setup routine (declared nowhere):
  dosmemsetup - given %eax returns %gs:(%eax) suitable address

WARNING - check PC.H to be sure, this is from MEMORY and prone to errors...
So, to get the clock ticks longword, you could use:
  dosmemget( 0x46c, 4, &tic_cnt)
And to write directly to the ENTIRE PRIMARY SCREEN (replacing all 2 byte cells)
  ScreenUpdate(myvirtualscreen)
You can also write smaller areas of the screen using dosmemput() and the
variables ScreenPrimary, ScreenSecondary plus offsets.  All of the 
Screen functions also work under DPMI.  Graphics - we will wait and see -
*MAYBE* in GRX1.03 :-) ... no promises

All of the above routines strip the 0xe0... from addresses and access the
memory via a selector which points to the low 1 Meg.  Get the DJLSR110.zip
and look at clock.s, screen.s, dosmem.s for some assembly examples.  There
is no direct way (without inline assembler) to access the low 1 Meg 
directly with pointers.  This is a price you pay with DPMI 0.9.
Unless someone wants to teach GCC about the concept FAR ...

> -- Does floating point emulation work?

Nope, sorry.  The emulator will have to be modified, plus the extender,
and there are currently some bugs in exceptions in DPMI.  Somewhat of a
major hack.  DEBUG32 and graphics support for DPMI are first on my list once 
I recover a bit from work related stress.  I would be willing to give advice to
anyone really desparate, however.  It would probably be easiest to write
an emulator that you link into your program.

> -- If I understand correctly, GO32 works the way it always did (complete
> with mem being remapped to 0xE0000000) unless a DPMI host is detected (or
> would it be more accurate to say "unless nothing else seems to work and a
> DPMI host is detected"?).  Is there a way at runtime to detect whether the
> DPMI host is sitting there?  The idea is that I would have one set of
> routines that access <1meg memory via 0xE0000000 and another set that use
> a special DPMI-obtained selector to access <1meg memory (if that is the
> only way to get at the mem).  At runtime, if GO32 is in "DPMI mode", it
> uses one set of routines, and otherwise uses the other.

Well, it checks for a DPMI host first (thats the rules...).  If it finds a
suitable 32 bit DPMI host it uses it, and does not attempt any of the
other types.  So, for example, if you have QEMM running (VCPI) and QDPMI loaded
it will use the QDPMI.  I need to write a library routine to return environment
information so you can tell if you are in DPMI...   If you use the dosmemget
and dosmemput routines described above, they will work in either environment.
(And for that matter, even under earlier versions of GO32 such as 1.08, 1.09...)
Temporarily at least, the extern long __transfer_buffer will be equal to zero
in DPMI environments and nonzero elsewhere (this may change however ;-) so
you could revert to direct pointers for faster access if a few microseconds
means that much to you.

If anyone ever writes a DPMI 1.0 we could map the low memory directly to
0xe0... but I am not holding my breath.

- Raw text -