Message-ID:	<003701c0e555$31fcb600$1400a8c0@alex2000>
From:	"Alex Oleynikov" <alex AT compuweigh DOT com>
To:	<djgpp AT delorie DOT com>
Subject:	Re: SRAM chip access problem
Date:	Fri, 25 May 2001 15:59:23 -0400
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To:	djgpp AT delorie DOT com

Thanks for the reply, Eli

>You don't check the return values of these three function calls.

Actually, I do, but for the simplicity of the code snippet I just stripped
all extra stuff.

>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.

This area is also used for the on-board BIOS (0x40000 bytes) and the memory
chip itself (which can be up to 256K in size).

>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).

I am a little bit confused here. DJGPP help says, that bit #3 of a
descriptor has to be set for code segments and cleared for data segments.
(BTW, how do you know whether it is code or data segment just by looking at
the selector's value? Isn't this information available only from the
descriptor to which this selector points in the LDT?). Anyway, I tried to
set this bit in the descriptor:

...
access_rights = __dpmi_get_descriptor_access_rights(selector);      // this
call returns 0x40F2
__dpmi_set_descriptor_access_rights(selector, access_rights | 0x08);
...

but it still crashes.
What _is_ amazing, when I upgraded to CWSDPMI r5 after your suggestion and
used "near" pointer access to the SRAM memory:

if( __djgpp_nearptr_enable() )

Window_Base=(char *)(mapping.address + __djgpp_conventional_base);

everything began to work fine! Before the upgrade this code was also
breaking down with SIGSEGV exception.



Alex

- Raw text -