Date:	Fri, 25 May 2001 19:57:32 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	"Alex Oleynikov" <alex AT compuweigh DOT com>
Message-Id:	<1659-Fri25May2001195731+0300-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	djgpp AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>
In-reply-to:	<001a01c0e530$e72a3db0$1400a8c0@alex2000>
Subject:	Re: SRAM chip access problem
References:	<001a01c0e530$e72a3db0$1400a8c0 AT alex2000>
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

[Please don't post in HTML.]

> From: "Alex Oleynikov" <alex AT compuweigh DOT com>
> Date: Fri, 25 May 2001 11:39:36 -0400
> 
> Can anyone give me a hint why my simple attempt to access an NVRAM chip =
> (128K Dallas Semiconductor plugged into DiskOnChip socket) from within a =
> DJGPP program crashes instantly (DOS v.7 (taken from Windows 98) + =
> CWSDPMI v.r4 + DJGPP v.2.03)?

Are you really using CWSDPMI r4?  If so, I suggest to upgrade to r5.

> Here's portion of the code trying to peek at the data:
> 
>  mapping.size=0x80000;
>  mapping.address=0xfff80000;

Are these the correct address and size of the on-device memory?  If
128K is the size of the device's memory, you should be setting size to
0x20000, not 0x80000.

>  selector = __dpmi_allocate_ldt_descriptors(1);
>  __dpmi_set_segment_base_address(selector, mapping.address);
>  __dpmi_set_segment_limit(selector, mapping.size-1);

You don't check the return values of these three function calls.
Judging by the crash message, they did work (see the base address and
the limit of the selector loaded into the FS register), but you should
really modify the program to verify that these function calls
succeeded before you use the selector.  (Yes, I know you lifted the
code from the FAQ, but the FAQ only outlines what should be done, it's
not production-quality code.)

>  byte = _farpeekb(selector, 0);
> ...
> 
> Here's the result:
> 
> Exiting due to signal SIGSEGV
> Page fault at eip=0000354a, error=0004
> eax=000000c7 ebx=00001000 ecx=00000007 edx=00000000 esi=0000054 edi=000923c9
> ebp=00092270 esp=00092270 program=C:\CD4000\PROBE.TC\SRAM.EXE
> cs: sel=00a7  base=10000000  limit=0009ffff
> ds: sel=00af  base=10000000  limit=0009ffff
> es: sel=00af  base=10000000  limit=0009ffff
> fs: sel=00c7  base=fff80000  limit=0007ffff
> gs: sel=00bf  base=00000000  limit=0010ffff
> ss: sel=00af  base=10000000  limit=0009ffff
> App stack: [000923f0..000123f0]  Exceptn stack: [00012350..00010410]

This means something is wrong with mapping the device into your
program's address space.  You can see that the FS selector is loaded
with the values you passed when you called
__dpmi_set_segment_base_address and __dpmi_set_segment_limit.
However, Page Fault means that the resulting address is not accessible
by you (error=4 means you tried to read from that address, which is
expected for a call to _farpeekb).  My guess would be that either your
address and/or limit are wrong for the device you want to access, or
maybe there's some bug in CWSDPMI (thus the advice to upgrade).

Wait a minute: something _is_ wrong with the selector you got from
__dpmi_allocate_ldt_descriptors: it seems to be a selector for code,
not for data (bit 3 of the selector is 0 instead of 1).  Can you call
__dpmi_set_descriptor_rights to set the data-segment bit, before the
call to _farpeekb, and see if that solves the problem?

Charles, shouldn't the selector returned by
__dpmi_allocate_ldt_descriptors be set to data by default?  The DPMI
spec seems to say it should.

- Raw text -