Mail Archives: djgpp/1995/03/21/05:09:38
According to a manual that came with my PC:-
Addresses 0xb0000000 etseq are the screen when in black & white text modes.
Addresses 0xb8000000 etseq are the screen when in color text modes,
or in graphical modes 4,5,6.
Addresses 0xa0000000 etseq are the screen when in graphical modes >= 0xd.
(But otherwise when in Gnu C).
Is this still all always correct?
I wrote a program (a text editor called AAEMACS) that needs the PC's screen
to be in a text mode. It tests for mode type thus:-
#define uns unsigned
uns char*graphicalscreen=(uns char*)0xd0000000; /**** this addr only in Gnu C */
and I set the byte graphicalscreen[44] = 16. If thereupon the byte
graphicalscreen[44] == 16, then the graphical screen address range exists and
I am in a graphical mode, not a text mode, so I complain and exit. This has
always worked OK so far with me, lots and lots of times. But a few days ago I
put AAEMACS on Simtel, and I got today an email from someone saying this:-
> I just downloaded Aaemacs from SimTel. I set the environment variable
> AAEMACS, but when I tried
> aaemacs readme
> I was told that aaemacs could not go into my screen mode-- 3 as reported
> by FINDMODE. It is the standard 80x25 with brightwhite text on a blue
> background. Any help would be appreciated.
(1) Are there any PC's or PC screen chips where the graphical screen range
0xa0000000 etseq always exists even in text mode?
(2) He said that his mode 3 displays bright white on blue, not ordinary
white on black, as if something has reset it. Are there any packages or
programs etc that when loaded or set by CONFIG.SYS or AUTOEXEC.BAT, will set
up a condition whereby the graphical screen address range always exists even
when the screen is in text mode? I compiled the corrent version of AAEMACS
with my current version of djgpp, which is go32 1.12, binutils 2.4, bison
1.22, diffutils 2.6, flex 2.4.7, gas 2.3, gcc 2.6.0, gdb 4.12, gzip 1.2.4,
libg++-2.6.0, make-3.71, patch-2.1, sed-1.18, texinfo-3.10 .
- Raw text -