Mail Archives: djgpp/1995/08/14/14:12:38
In article <302759c6 DOT sandmann AT clio DOT rice DOT edu> sandmann AT clio DOT rice DOT edu writes:
>> # ifdef GO32
>> ! /* dosmemput (ch, COLS * sizeof(unsigned short),
>> (void *)_FAR_POINTER(_cursvar.video_seg,
>> _cursvar.video_ofs + (i * COLS * sizeof(unsigned short))));
>> + */
>> + movedata (_go32_my_ds(), ch, _go32_conventional_mem_selector(),
>> + (_cursvar.video_seg << 4) + _cursvar.video_ofs + (i * COLS * sizeof(unsigned short)),
>> + COLS * sizeof(unsigned short));
>
>> Maybe there is (better | simpler | faster) way to change this code?
>
>What you have done looks fine, but my guess is the original code would work
>fine also if the _FAR_POINTER (macro? function?) was fixed to not use the
>0xe00xxxxx type addressing, since it's not even necessary with dosmemput.
>I think this change would be simplier, but what you coded is
>really equivalent.
>
>One of these changes needs to be sent to the maintainers - since that would
>allow it to work under V1.x and V2.0.
>
>Good work!
To my best knowledge the _FAR_POINTER macro doesn't use the
0xe00xxxxx type addressing, at least not with DJGPP V1.
(From the stack trace supplied it was clear that some call to
dosmemput() was made.)
I've been using PDCurses 2.1 and 2.2 inside Windows DOS boxes
for a long time, where the 0xe00xxxxx was already a big no-no.
(With DJGPP V1 that was, yeah, the old days...)
I suspect the problem is indeed some (re-)definition of
the _FAR_POINTER macro, so changing that should solve the problem.
Pieter.
By the way, the PDCurses maintainer is Mark Hessling (mark AT snark DOT itc DOT gu DOT edu DOT au).
- Raw text -