readdm@walt.cc.utexas.edu (David M. Read) (08/17/90)
In article <> julian@uhccux.uhcc.Hawaii.Edu (Julian Cowley) writes: > >So my question boils down to this: what is the cleanest way of >accessing an absolute address such as 0xa0000 in Quick C? > I don't know about QuickC for sure, but I have done the following successfully in full-blown Microsoft C (5.1): unsigned char far *mem; mem = 0xA000:0000; *(mem + offset) = val; where offset & val are self-explanatory. I did this in order to do some direct screen writes to CGA ram, and everything worked just fine, in all four memory models. Good luck with it... -- Dave Read | read@lampf.lanl.gov UT-Austin Nuclear Physics | readdm@walt.cc.utexas.edu
mlf@manatee.cis.ufl.edu (Mike Fisher) (08/17/90)
In article <9042@uhccux.uhcc.Hawaii.Edu> julian@uhccux.uhcc.Hawaii.Edu (Julian Cowley) writes: So my question boils down to this: what is the cleanest way of accessing an absolute address such as 0xa0000 in Quick C? I don't use Quick C, but I can tell you what works for me in Turbo C. PutPixel (int x, int y, unsigned char c) { unsigned char huge *w; /* huge seems to work better here */ w = (unsigned char huge *)(0xA0000000L + (long)y * 320L + (long)x); *w = c; } Good luck... -- ------------------------------------------------------------------------------- | Real life: There is no such thing... Mike Fisher | | | | University of Florida CIS Dept. mlf@cis.ufl.edu | -------------------------------------------------------------------------------
bmarsh@cod.NOSC.MIL (William C. Marsh) (08/17/90)
Lots of people post code that looks like: > unsigned char far *mem; > > mem = 0xA000:0000; > *(mem + offset) = val; Could we please stop using code that looks like this? This is very unportable to other 80x86 C compilers! If you use the provided services in the compiler (either MSC style or TurboC style) then there is a good chance it will work elseware (Plus, it's easier to understand). Examples (Using the above): MSC: FP_SEG(mem) = 0xA000; FP_OFF(mem) = 0x0000; TurboC: MK_FP(mem, 0xA000, 0x0000); Bill -- Bill Marsh, Naval Ocean Systems Center, San Diego, CA {arpa,mil}net: bmarsh@cod.nosc.mil uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh "If everything seems to be coming your way, you're probably in the wrong lane."
julian@uhccux.uhcc.Hawaii.Edu (Julian Cowley) (08/18/90)
I've just come over from comp.lang.c where this request drew a
blank expression from the members of the newsgroup. What I'm
trying to do is access the MCGA screen at A000:0000. Here was
my first attempt:
PutPixel (int x, int y, unsigned char c)
{
unsigned char far *mem;
FP_SEG (mem) = 0xa000;
FP_OFF (mem) = 320 * y + x;
*mem = c; /* <-- this line gives a run-time error */
}
The commented line caused run-time error R6013: illegal far
pointer use. (Unfortunately, I do not have the manuals to look
up the cause, even though this is a legitimate copy of Quick
C.) The help page for the FP_* macros says that the macros
won't work under certain conditions in small and medium models,
but this happens in large model also.
So my question boils down to this: what is the cleanest way of
accessing an absolute address such as 0xa0000 in Quick C?
julian cowley
university of hawaii at manoa
julian@uhccux.uhcc.hawaii.edu
julian@uhccux.bitnetkeck@sea.com (Jon Keck) (08/21/90)
In article <2060@cod.NOSC.MIL> bmarsh@cod.nosc.mil.UUCP (William C. Marsh) writes: >Lots of people post code that looks like: >> unsigned char far *mem; >> >> mem = 0xA000:0000; >> *(mem + offset) = val; > >Could we please stop using code that looks like this? This is very unportable >to other 80x86 C compilers! If you use the provided services in the compiler >(either MSC style or TurboC style) then there is a good chance it will work >elseware (Plus, it's easier to understand). > >Examples (Using the above): > >MSC: > > FP_SEG(mem) = 0xA000; > FP_OFF(mem) = 0x0000; > >TurboC: > > MK_FP(mem, 0xA000, 0x0000); From the Turbo C 2.0 Reference Guide, p. 251, the syntax of the MK_FP macro is void far *MK_FP(unsigned seg, unsigned ofs); -- John Keck INTERNET:keck@sea.com UUCP:...!ucsd!soledad!keck VOICE:619/581-6181 Systems Engineering Associates, 2204 Garnet Ave Suite 203, San Diego CA 92109 ----------------------------------------------------------------------------- "Much speech leads inevitably to silence. Better to hold fast to the void."
jian@prodix.liu.se (Jian Hu) (08/23/90)
julian@uhccux.uhcc.Hawaii.Edu (Julian Cowley) writes: >I've just come over from comp.lang.c where this request drew a >blank expression from the members of the newsgroup. What I'm >trying to do is access the MCGA screen at A000:0000. Here was >my first attempt: >PutPixel (int x, int y, unsigned char c) >{ > unsigned char far *mem; > FP_SEG (mem) = 0xa000; > FP_OFF (mem) = 320 * y + x; > *mem = c; /* <-- this line gives a run-time error */ >} >The commented line caused run-time error R6013: illegal far >pointer use. (Unfortunately, I do not have the manuals to look >up the cause, even though this is a legitimate copy of Quick >C.) The help page for the FP_* macros says that the macros >won't work under certain conditions in small and medium models, >but this happens in large model also. I`ve just tried the above code segment on QC2.0 and got the same result, which surprised me because one of my applications used the same technique to adress high memory. After some comparison to my old code, I found the ridiculous answer (or one of them): Change the commented line to: (*mem++) = c; Of couse you`ll have to decrease mem to keep the value. Studying the machine code shows that this line straightly assigns c to the location mem points to. When the original line is used, the machine code checks the segment value of mem (A000) against two global variables __asegh and __aseglo. If __aseglo<=FP_SEG(mem)<__asegh, an error is generated. This doesn`t seem to me like a compiler error, does it? And I would also like to know why.