www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/12/07/19:09:51

From: broeker AT acp3bf DOT knirsch DOT de (Hans-Bernhard Broeker)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Memory Mapping and Libcurses support in DJGPP? (newbie question)
Date: 8 Dec 1999 00:57:27 +0100
Organization: RWTH Aachen, III. physikalisches Institut B
Lines: 49
Message-ID: <82k6t7$fiu@acp3bf.knirsch.de>
References: <7ua34.761$He DOT 5295 AT newsfeed DOT slurp DOT net>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 944611053 2143 137.226.32.75 (7 Dec 1999 23:57:33 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 7 Dec 1999 23:57:33 GMT
X-Newsreader: TIN [version 1.2 PL2]
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Chris Fought (cfought AT systran DOT com) wrote:
>     I am a software engineer at a company that produces high performance
> shared memory devices and I am considering porting some of our existing DOS
> software to use DJGPP, 

A good choice you're considering, there. Stick to it :-)

> but I have a few key features that I must have in
> order to do so. I really have to be able to directly map memory from our
> shared memory cards directly into host memory so that it appears as system
> memory. 

For a PC under DOS there's essentially two types of 'shared memory'
approach: 

1) direct, hardware memory addressing in the 1st megabyte, where
realmode DOS can see it. No mapping needed by software at all: the
hardware will look just like another VGA card, just at a different
address...

2) PCI/AGP provided bus mastering, where a device takes over a
physical address range outside the first meg. Stuff like the linear
frame buffer used by modern graphics adapters.

> malloc, creating buffers etc.). Once we have this step completed our
> software simply creates a pointer to the location in the host's memory where
> our card's 'memory' exists. 

Look up FAQ paragraphs 18.4 and 18.7. You can *not* simply set up a
pointer to your device memory, in protected mode. The 'protected' in
that term is against it. From your requirement, I suspect you'll want
to use the rather dangerous 'nearptr' method, but I'd advise against
it.  You loose all the protection, that way, i.e. you're back to the
state of raw DOS programming, where a single ill-written program could
easily confuse DOS to horrible death. Literally.

In principle, you could use dpmi_map_physical_memory(), but that call
seems to be unsupported by practically *all* existing DPMI servers....

> Also our
> software where possible, always needs libcurses support for some diagnostic

There's PDCurses for DJGPP: pdc*.zip on the DJGPP ftp servers should
be it.


-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019