ag@elgar.UUCP (Keith Gabryelski) (08/11/88)
I am using the SCO CGI package on a 386 Zenith machine. When I want
to close the workstation and exit I use the v_clswrk() library
routine. This routine seems to close up shop, but leaves the
workstation in a bizarre state.
It looks like the terminal is out of graphics mode, but (possibly) the
character sets are screwed up. That is, there is random garbage all
over the workstation, but I can definitely distinguish texual
patterns. I am obviously back at my shell prompt, but it is
impossible to tell exactly what text is on the screen.
This happens when exiting the sample `cgitest' program also.
VDIPATH=/usr/lib/cgi
DISPLAY=cgaco
This is the same garbage that happens when I switch over from one VPIX
window to a non-VPIX window.
Can someone clue me in on this lossage.
Pax, Keith
--
"If green is all there is to be, then green is good enough for me" - ktf
[ Keith ] UUCP: {ucsd, cbosgd!crash, sdcsvax!crash, nosc!crash}!elgar!ag
[Gabryelski] INET: ag@elgar.cts.com ARPA: elgar!ag@ucsd.edurichard@neabbs.UUCP (RICHARD RONTELTAP) (08/12/88)
[ Garbage on screen with VP/ix and CGI ] I think I've seen this problem too: It's a 'feature' of the ANSI console drivers, and is invoked by <ESC>[12m. It causes the high bit of every character to be flipped before display. That's why you can admire IBM's grahic characters and recognize textual patterns. You can switch back by typing: <ESC>[11m Why on earth this is built in? I would't know! Richard
ag@elgar.UUCP (Keith Gabryelski) (08/14/88)
In article <18182@neabbs.UUCP> richard@neabbs.UUCP (RICHARD RONTELTAP) writes: >[ Garbage on screen with VP/ix and CGI ] > >I think I've seen this problem too: >It's a 'feature' of the ANSI console drivers, and is invoked by ><ESC>[12m. It causes the high bit of every character to be flipped >before display. That's why you can admire IBM's grahic characters and >recognize textual patterns. > >You can switch back by typing: <ESC>[11m Actually, I think you meant <ESC>[10m as the fix, right? Nope, I don't see a recognizable character on the screen. It `looks' like the actual character maps are screwed. That is, instead of a 0x20 (space) being mapped as: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 It is mapped like: 11111110 01111011 11011101 11110111 10101011 11011010 10111101 01000011 And other similiar nonsense for other characters. I see NO characters that are in the IBM graphics set. Pax, Keith -- "If green is all there is to be, then green is good enough for me" - ktf [ Keith ] UUCP: {ucsd, cbosgd!crash, sdcsvax!crash, nosc!crash}!elgar!ag [Gabryelski] INET: ag@elgar.cts.com ARPA: elgar!ag@ucsd.edu
richard@neabbs.UUCP (RICHARD RONTELTAP) (08/15/88)
[ XENIX screen garbage ] You're right. I meant <ESC>10m. Sorry it didn't work. Richard
chapman@sco.COM (Brian Chapman) (08/16/88)
< ag@elgar.UUCP (Keith Gabryelski) writes: < [ __Garbage on screen with VP/ix and CGI__ ] < [ It looks like the terminal is out of graphics mode, but (possibly) the ] < [ character sets are screwed up. That is, there is random garbage all ] < [ over the workstation, but I can definitely distinguish texual ] < [ patterns. I am obviously back at my shell prompt, but it is ] < [ impossible to tell exactly what text is on the screen. ] I have seen this problem. Your soft font is plane 2 is trash. There is no documented way for software other than the Video BIOS (like Xenix) to load the font back into the video card after graphics mode. Version 2.2 of SCO loaded the fonts from an offset of where INT 0x41 points. This has turned out to not be the best solution for all people. We corrected this in 2.3. BTW: Some small vendors still ask us: "Why don't you just call the BIOS to load the font?". In article <18182@neabbs.UUCP> richard@neabbs.UUCP (RICHARD RONTELTAP) writes: < I think I've seen this problem too: < It's a 'feature' of the ANSI console drivers, and is invoked by < <ESC>[12m. It causes the high bit of every character to be flipped < before display. That's why you can admire IBM's grahic characters and < recognize textual patterns. < < You can switch back by typing: <ESC>[11m The correct sequence is <ESC>[10m. The sequence <ESC>[11m will display the control characters less than ' '. (ie: happyfaces clubs, hearts, diamonds, spades, ...) < Why on earth this is built in? I would't know! ANSI defines "<ESC> [ 1 <num> m" to be switch to alternate font <num>. These first (num='1', '2') are #1) easy to do, #2) doesn't take up a lot of memory like a _real_ font would, #3) Implements the termcap GS functionality (can't remember the terminfo name) and #4) leaves room for 7 possible _real_ alternate fonts in the future. -- Brian Chapman uunet!sco!chapman Xenix Kernel Development
ag@elgar.UUCP (Keith Gabryelski) (08/17/88)
I recieved mail from a dionj at SCO with the solution. Here is the
mail I received.
-----------------------------------------------------------------------
From: ucsd!ucscc.UCSC.EDU!sco!dionj
Keith, call SCO support and ask for this fix!
[Short and sweet ... but there is more. Dion
included a forwarded message from rosso
that explains which fixes. --Ed.]
From rosso Mon Aug 15 11:32:05 1988
He is describing the EGA font problem. The Zenith EGA is one
of the EGA cards that exhibited this problem. He should contact
Support and ask for Support Level Fix xnx086 (for 386 only).
If someone has this problem on a 286 machine, they need xnx084.
rosso
-----------------------------------------------------------------------
Along with Brian's description of the problem, that pretty much sums
it up. Thanks SCO!
Pax, Keith
--
"If green is all there is to be, then green is good enough for me" - ktf
[ Keith ] UUCP: {ucsd, cbosgd!crash, sdcsvax!crash, nosc!crash}!elgar!ag
[Gabryelski] INET: ag@elgar.cts.com ARPA: elgar!ag@ucsd.edu