From:	Charles Sandmann <sandmann AT new-orleans DOT NeoSoft DOT com>
Subject:	Re: V2
To:	A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk (A.Appleyard)
Date:	Fri, 27 Jan 1995 12:07:27 -0600 (CST)
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu

> In my program I have to write to the text screen a LOT. How much longer will
> it take using this `dosmemput()' every time, than direct writing to addresses
> like I do now? I don't always write to screen as neat whole bufferfuls, but
> often one character here, one there. So I declare `unsigned short *screen'
> pointing to the start of the text screen. What are these `farptr' routines and
> where is information about them? I don't want the supermassive rewrite job on
> my program which this change will cause me. Please!!! What <is> the matter
> with having the text screen represented as always the same addresses like now??
> Ditto with knowing the graphics screen's address. This change will put a
> pickaxe handle through a LOT of my and my department's programs that I wrote!!

For your application, it seems that the farptr functions are ideal.  Look
in include/sys/farptr.h for the declarations and some documentation.  A
simple example of what you want to do is:

#include <go32.h>
#include <sys/farptr.h>
   *(screen+(row*80+col)) = value;  /* becomes: */
   _farpokew(_go32_info_block.selector_for_linear_memory, 
       0xb8000+2*(row*80+col), value); 	
If you use this a lot, a define string for wscreen and rscreen will make
more sense.

Why the pain?
1)  The fixed location algorithm is incompatible with GCC's assumptions and
    with DPMI.  Your code won't work with DPMI right now as is.  Multiple
    API's for multiple environments is a bad idea.
2)  Non-DPMI systems are disappearing.  Windows, OS/2, Win 95 are all 
    driving that.

Of course, if the application is going to run on obsolete boxes and there
is no need to upgrade, you can continue to use V1.1x

- Raw text -