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" 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 Precedence: bulk > Date: Sat, 17 Jun 2000 11:13:08 -0500 > From: Sartaj Singh > > 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.