samperi@marob.MASA.COM (Dominick Samperi) (06/27/88)
I received several responses to my posted question about accessing
the video memory via shared memory calls. All responses contained the
suggestion that I use ioctl instead, as documented in the SCO Xenix
HW section of the manual set.
I followed the instructions there and
everything worked fine, except for one small bug: If blinking colored
text is displayed by writing directly to video memory (with the
blink attribute turned on), from the main console, and if you switch
momentarily to another virtual console, and back again to the main
console, you find that text that was blinking is now in reverse video,
and not blinking. Apparently the high bit in the attribute byte for the
blinking text gets lost when you switch to another virtual console and
back again to the main console. Interestingly, this problem does not
occur when the blinking text is initially displayed by running the
program (the one that does the direct video memory writes) from a virtual
console that is not the main console.
After playing with the ioctl stuff for a while, it appears that an
attempt to open /dev/cga will fail if the console is an EGA monitor,
and presumably, an open attempt on /dev/mono will also fail if there
is no monochrome monitor attached. Does this imply that the best way
to determine what kind of monitor(s) is/are attached is to simply
try to open /dev/mono, /dev/cga, and /dev/ega?
On the original question regarding the use of shared memory calls to
access video memory, I suspect that this is possible, for it seems that
SCO's CGI graphics package does it (according to the CGI docs).
--
Dominick Samperi, NYC
samperi@acf8.NYU.EDU samperi@marob.MASA.COM
cmcl2!phri!marob uunet!hombre!samperi
(^ ell)