Message-Id:	<200006170721.KAA20397@alpha.netvision.net.il>
Date:	Sat, 17 Jun 2000 10:23:26 +0200
X-Mailer:	Emacs 20.6 (via feedmail 8.1.emacs20_6 I) and Blat ver 1.8.5b
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
To:	sartaj AT cair DOT res DOT in
CC:	djgpp AT delorie DOT com
In-reply-to:	<394BA394.E2C616DE@cair.res.in> (message from Sartaj Singh on
	Sat, 17 Jun 2000 11:13:08 -0500)
Subject:	Re: Memory access on custom ISA card
References:	<394BA394 DOT E2C616DE AT cair DOT res DOT in>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> Date: Sat, 17 Jun 2000 11:13:08 -0500
> From: Sartaj Singh <sartaj AT cair DOT res DOT in>
> 
> We have designed an 8-bit ISA card with 64K of on-board memory. This
> memory is mapped to 0xD0000 base address. In BorlandC 3.1 we are able to
> access the memory by using pokeb and peekb instructions.
> 
> Recently we switched over to DJGPP because we found it far more
> attractive and easy to work with as compared to BorlandC 3.1. However we
> are stuck with trying to access this memory on our board. We have
> already tried the following methods without success :
> 
> 1. Using _farpeekb and _farpokeb with _dos_ds
> 2. Using _dosmemgetb and _dosmemputb
> 3. Using the _my_ds() descriptor
> 
> In order to ensure the proper functioning of DJGPP, we followed the
> examples for accessing the video buffer (at 0xA0000, 0xB8000) which work
> perfectly.

If accessing 0xA0000 works, but 0xD0000 does not, the only conclusion
I can draw from this is that either (1) there's some memory manager or
another piece of software that remaps the D000 segment to a different
physical address; or (2) your board interface somehow is incompatible
with protected mode addressing.

The first possibility can be explored by running your DJGPP programs
on vanilla DOS system, with an empty CONFIG.SYS and AUTOEXEC.BAT that
only sets PATH and the DJGPP environment variable.  If that doesn't
work, the only reason I can think about is the second one.

I'm not really a hardware person, so I don't know what would be
involved with the addressing issue.  Perhaps I simply made it up, and
such a problem cannot happen.

One more thing: how much memory does your system have, physically?  If
it has too few RAM, it's possible that CWSDPMI uses some of the high
addresses to either load itself or run the DJGPP programs out of
there.

- Raw text -