Newsgroups:	comp.os.msdos.djgpp
From:	Pieter Kunst <kunst AT natlab DOT research DOT philips DOT com>
Subject:	Re: a problem with CURSES
Sender:	news AT natlab DOT research DOT philips DOT com (USENET News System)
Message-ID:	<3259178F.1D37@natlab.research.philips.com>
Date:	Mon, 7 Oct 1996 14:45:35 GMT
To:	Ronen Friedman <ronenp AT netvision DOT net DOT il>
Reply-To:	kunst AT natlab DOT research DOT philips DOT com
References:	<537v35$7a2 AT news DOT NetVision DOT net DOT il>
Mime-Version:	1.0
Organization:	Philips Research Labs, Eindhoven, The Netherlands
Lines:	44
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Ronen Friedman wrote:
> I'm trying to incorporate PDCURSES into my C program. I'm using PDCURS22
> with gcc from DJGPP 2. The program runs OK in a PC window on my NT PC,
> but (always) fails on the target, which is a PC104 without math co-proc,
> running DR-DOS. Other (non-CURSES) DJGPP compiled programs are
> executing happily there.
> 
> The compilation commands are:
> 
> LIBS= libsv.a libcurso.a
> test_cur:       test_cur.c
>         gcc -g -Wall -DNAMES -DDBG_1 -Id:/gnu/djgpp2/contrib/pdcurs22/include -o
>                 test_cur test_cur.c $(LIBS) -lemu
> 
> The traceback always shows that the problem occured in
>         _dj_movedata+33
>         wnoutrefresh+319
>         wrefresh()+50
>         from line 29 in the attached program
> 
> Can any kind soul tell me what am I doing wrong?
> 

(I cannot tell you what you are doing wrong.
 I can only add a few comments to your posting.)

The problem occurs when calling 'wrefresh()', i.e. when the
transfer from the internal PDCurses screen memory buffer to
the physical screen memory is made. This is done (by PDCurses)
using a call to 'movedata()' which is the standard method to
transfer data from protected mode to real-mode DOS memory
(in this case the text video memory at B800:0000).

I have one suggestion: did you use the PDCurses from the v2tk/pdc22.zip
file, or did you recompile the 'original' PDCurses 2.2 with DJGPP V2 ?
There is a small patch added to the v2tk/pdc22.zip version that has to
do with a spurious 0xE0000000 mask from previous DJGPP V1 incarnations.
If you didn't use v2tk/pdc22.zip, then try that one first.

Otherwise, it could be a problem with the DPMI routine in combination with
DR-DOS, but I can't verify this because I don't use DR-DOS.
Maybe Charles could give you a remark about this one...

Pieter.

- Raw text -