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