[comp.unix.sysv386] SUMMARY: How to configure vt100/wyse50 in VP/ix for line graphics

bill@twg.bc.ca (Bill Irwin) (11/18/90)

I originally posted:

>I am trying to configure an Altos III (vt100 compatible, almost) and Wyse
>60  with an ascii keyboard for use with VP/ix.  I have a front-end script
>which  changes  the  TERM variable from vt100 to vt100nam,  but  for  the
>wyse60 it changes to wyse50n.
>
>When  I  invoke  the VP/ix menu (ESC SO or ESC s) I  get  bad  characters
>drawing the box that surrounds the menu.  The vt100 prints "q"s and "x"s,
>while  the wyse50nam prints all "."s.  I have not been able to locate  in
>TFM  where the appropriate graphic characters are specified.  In the file
>"/usr/vpix/term/wyse50n",  the  output  characters mappings  section  has
>every line being mapped to a ".".

I  received one email providing the VT100 codes for start/stop graphics  mode,
but  nothing indicating that I didn't have to hand modify the output scan code
mappings  in the "/usr/vpix/term/[altos3-nam|wyse50n]" files.  I was  prepared
to  do  this for the Altos terminal because I know it is not completely  VT100
compatible,  but  I certainly expected the Wyse 60 (running as a Wyse  50)  to
produce  flawless graphics.  After all, what does a "supported terminal" mean,
if not that "it works properly"?

Anyone familiar with the scan code mapping tables in these files will know the
task  I had before me, especially without a table to provide the scan code for
each  of  the  eleven  line drawing characters used to draw  a  box  which  is
dissected vertically and horizontally.

The solution came some 4 hours later after substituting all the letters of the
alphabet  (a-z|A-Z)  for each of a range of scan codes, then running VP/ix  to
see  how  it  was  drawing  boxes.  Eventually I started  seeing  some  of  my
substitute  characters  in  the box, which then told me  which  character  was
supposed to be there and therefore the scan code that needed changing.

Another  trip into the scan code mapping table to find the character I saw and
to  insert  the  sequence that actually draws the correct  graphic  character.
After  getting one terminal configured correctly this way, it was an easy task
to  note  the scan codes that were actually changed, and only deal with  those
codes for the second terminal.

My  question  remains:  why would SCO put out a mature product like VP/ix  and
have  a  "supported  terminal"  (Wyse  50)   using  periods  for  box  drawing
characters?  That doesn't fit my definition of supported.  8^(

If  anyone else is having this problem and would like to know which scan codes
produce  which position graphic for box drawing, email me and I will give  you
the numbers.  It will save you about 3 or 4 hours of trial and error.
-- 
Bill Irwin    -       The Westrheim Group     -    Vancouver, BC, Canada
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uunet!van-bc!twg!bill     (604) 431-9600 (voice) |     UNIX Systems
bill@twg.bc.ca            (604) 430-4329 (fax)   |     Integration

bill@bilver.UUCP (Bill Vermillion) (11/21/90)

In article <330@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes:
>I originally posted:
 
>>When  I  invoke  the VP/ix menu (ESC SO or ESC s) I  get  bad  characters
>>drawing the box that surrounds the menu.  The vt100 prints "q"s and "x"s,
>>while  the wyse50nam prints all "."s.  I have not been able to locate  in
>>TFM  where the appropriate graphic characters are specified.  In the file
>>"/usr/vpix/term/wyse50n",  the  output  characters mappings  section  has
>>every line being mapped to a ".".
 
>My  question  remains:  why would SCO put out a mature product like VP/ix  and
>have  a  "supported  terminal"  (Wyse  50)   using  periods  for  box  drawing
>characters?  That doesn't fit my definition of supported.  8^(

I have had similar problems with terminal that are "vt" compatible but are
not 100%.  Mapping the '.'s seems to me the best solution when you don't
know what the "vt compatible" terminal's capabilites are.

The q's and x's are something that the users have had to learn to live with
because some emulations don't handle the alternate character set.

I have had that problem using dual protocols (poll-select & ascii in same
terminal) terminals.  Some brands work fine, other don't.  The ones that
work get boxes, the ones that don't get q's and x's.   

It seems to some, compatible means it will run most things. ;=}
Don't blame SCO for something that is/may be the fault of the hardware
manufacturer.  



-- 
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
                      : bill@bilver.UUCP

bill@twg.bc.ca (Bill Irwin) (11/25/90)

By  popular  demand  I am re-summarizing and including  the  scan
codes  for mapping to box drawing graphic characters.  I received
several  mail  requests  for these and, if I  had  been  thinking
straight  when  I  first summarized, I would have  included  them
then.   It doesn't add very much to the length of the article.  I
have  included  the  original  problem  and  description  of  the
solution  for the benefit of those who want to tie the scan codes
into the problem.

I originally summarized:

|I originally posted:
|
|>I am trying to configure an Altos III (vt100 compatible, almost) and Wyse
|>60  with an ascii keyboard for use with VP/ix.  I have a front-end script
|>which  changes  the  TERM variable from vt100 to vt100nam,  but  for  the
|>wyse60 it changes to wyse50n.
|>
|>When  I  invoke  the VP/ix menu (ESC SO or ESC s) I  get  bad  characters
|>drawing the box that surrounds the menu.  The vt100 prints "q"s and "x"s,
|>while  the wyse50nam prints all "."s.  I have not been able to locate  in
|>TFM  where the appropriate graphic characters are specified.  In the file
|>"/usr/vpix/term/wyse50n",  the  output  characters mappings  section  has
|>every line being mapped to a ".".
|
|I  received one email providing the VT100 codes for start/stop graphics  mode,
|but  nothing indicating that I didn't have to hand modify the output scan code
|mappings  in the "/usr/vpix/term/[altos3-nam|wyse50n]" files.  I was  prepared
|to  do  this for the Altos terminal because I know it is not completely  VT100
|compatible,  but  I certainly expected the Wyse 60 (running as a Wyse  50)  to
|produce  flawless graphics.  After all, what does a "supported terminal" mean,
|if not that "it works properly"?
|
|Anyone familiar with the scan code mapping tables in these files will know the
|task  I had before me, especially without a table to provide the scan code for
|each  of  the  eleven  line drawing characters used to draw  a  box  which  is
|dissected vertically and horizontally.
|
|The solution came some 4 hours later after substituting all the letters of the
|alphabet  (a-z|A-Z)  for each of a range of scan codes, then running VP/ix  to
|see  how  it  was  drawing  boxes.  Eventually I started  seeing  some  of  my
|substitute  characters  in  the box, which then told me  which  character  was
|supposed to be there and therefore the scan code that needed changing.
|
|Another  trip into the scan code mapping table to find the character I saw and
|to  insert  the  sequence that actually draws the correct  graphic  character.
|After  getting one terminal configured correctly this way, it was an easy task
|to  note  the scan codes that were actually changed, and only deal with  those
|codes for the second terminal.
|
|My  question  remains:  why would SCO put out a mature product like VP/ix  and
|have  a  "supported  terminal"  (Wyse  50)   using  periods  for  box  drawing
|characters?  That doesn't fit my definition of supported.  8^(
|
|If  anyone else is having this problem and would like to know which scan codes
|produce  which position graphic for box drawing, email me and I will give  you
|the numbers.  It will save you about 3 or 4 hours of trial and error.

So here they are:

*       Wyse in native mode configuration
*       Part II: output character mappings

output:         \263            \033-H-6
output:         \272            \033-H-6    |

output:         \273            \033-H-3    -+
                                             |

                                             |
output:         \274            \033-H-5   --+

output:         \277            \033-H-3
output:         \300            \033-H-1
output:         \304            \033-H-:

                                             |
output:         \310            \033-H-1     +--
                                             +--
output:         \311            \033-H-2     |

output:         \315            \033-H-:     --
output:         \331            \033-H-5
output:         \332            \033-H-2


These  include  the  scan codes for both single  line  boxes  and
double  line boxes.  The codes with ascii representations are the
ones  for single line boxes.  The codes without a  representation
are  the  ones  for double line boxes, but I threw out  the  hand
written  notes  I  had on which characters these  codes  actually
produce.   All  you need to do is put a letter next to each  scan
code  and watch where the letters go when a DOS application tries
to  draw a box.  Or you can look up the codes above in a Wyse  50
manual to determine which characters they produce.

Good luck.  Why didn't SCO do this???  8^(
-- 
Bill Irwin    -       The Westrheim Group     -    Vancouver, BC, Canada
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uunet!van-bc!twg!bill     (604) 431-9600 (voice) |     UNIX Systems
bill@twg.bc.ca            (604) 430-4329 (fax)   |     Integration