Xref: utzoo comp.unix.msdos:210 comp.unix.sysv386:2502 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!van-bc!twg!bill From: bill@twg.bc.ca (Bill Irwin) Newsgroups: comp.unix.msdos,comp.unix.sysv386 Subject: Re: SUMMARY: How to configure vt100/wyse50 in VP/ix for line graphics Message-ID: <334@twg.bc.ca> Date: 25 Nov 90 07:29:48 GMT References: <303@twg.bc.ca> <330@twg.bc.ca> Organization: The Westrheim Group, Vancouver, B.C., Canada Lines: 102 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