Message-ID: <003701c0e555$31fcb600$1400a8c0@alex2000> From: "Alex Oleynikov" To: Subject: Re: SRAM chip access problem Date: Fri, 25 May 2001 15:59:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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