home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1996 September / Simtel-MSDOS-Sep1996-CD1.iso / disc1 / commprog / pctrmcap.iqf / PCTRMCAP.INF
Text File  |  1985-12-07  |  7KB  |  124 lines
  1. Date: Saturday 21 September 1985
  2. From: Dan Kary
  3. Re:   IBM-PC-XT Termcap
  4.  
  5. I have seen requests for an ibm pc termcap several times.  This seems
  6. to be a point of confusion among some pc users.  Termcap is the
  7. terminal capability data base, it contains descriptions of terminals
  8. in terms of what capabilities they have, the sizes of things like how
  9. many lines the screen displays and what sequence of characters must
  10. be sent to make the terminal perform some act, such as moving the
  11. cursor or clearing the screen.
  12.  
  13. The ibm pc is not a terminal, and for that reason there is not and
  14. can not be a termcap entry that applies to the ibm pc.  Frequently
  15. ibm pc's are used as terminals.  This is accomplished by running a
  16. program that reads the keyboard and transmits the ascii value of the
  17. character that was typed over the rs-232 port while simultaneously
  18. reading the input of the rs-232 port and sending those characters to
  19. the screen.  This program is frequently called a 'terminal emulator',
  20. because it makes an ibm pc (which is not a terminal) behave as if it
  21. were a terminal.
  22.  
  23. In most video terminals the input data stream is interpreted; not all
  24. characters that are received are sent to the screen.  Some sequences
  25. of characters cause actions to occur (move the cursor, clear the
  26. screen, etc.).  The way the data stream is interpreted on the ibm pc
  27. (and thus, the termcap entry you need) is determined entirely by the
  28. terminal emulation software you are using.  In the simplest case the
  29. terminal emulation software can do no data stream interpretation and
  30. send all characters to the display.  A program of this low a level of
  31. sophistication would probably be available for free.  Commercial
  32. emulation software (and most freeware) will interpret the input data
  33. stream in the same manner that some popular terminal does.  The most
  34. popular emulations (in my limited experience) are vt52 and vt100.  It
  35. is also my experience that software emulators implement a subset of
  36. the emulated terminals capabilities.  A correct termcap entry can be
  37. constructed by looking at your terminal emulator manual to see which
  38. terminal the software emulates.  Find that entry in /etc/termcap,
  39. make a copy of that entry (with another name) and remove all the
  40. capabilities that terminal has that your emulator does not support
  41. (the technical section of your manual will optimistically list the
  42. capabilities it does support while ignoring the ones it does not
  43. support, so this may involve some effort).
  44.  
  45. Lets consider the case where the emulation software does no data
  46. stream interpretation.  Now the question is how is the data stream
  47. interpreted by the ibm pc?  We send a data stream to a terminal over
  48. a communication line, how do we send a data stream to a pc?  Well, we
  49. can get data from the keyboard or the disk or some other I/O device,
  50. but when does it get interpreted?  If it gets interpreted at all,
  51. will depend both on the device it gets sent to and how it gets sent
  52. to that device.  The device of interest is the screen, so now the
  53. question is how does data get sent to the screen?  Ultimately, there
  54. is one way to put a character on the ibm pc screen, and that is to
  55. write the ascii value of the character into the display RAM of the
  56. display adapter.  Programs usually do not do this directly, since
  57. they would have to know about the differences between the monochrome
  58. and color/graphics adapters.  Usually the BIOS is used to put
  59. characters on the screen.  BIOS means Basic Input and Output System;
  60. it is software contained within the ibm pc's ROM.  The BIOS knows how
  61. to put characters into the display RAM of both types of adapters so
  62. other programs don't have to worry about that particular detail.
  63. Simply tell BIOS which character to display and it does the job.
  64.  
  65. The BIOS does not do any data stream interpretation (unless you
  66. consider translating 'carriage return' or 'line feed' into what
  67. amounts to be a cursor move to be 'interpretation').  If you send a
  68. sequence of characters to the BIOS that would cause the cursor to
  69. move if that same sequence were sent to a vt100, you will see some
  70. graphic characters and perhaps some alphanumeric characters
  71. displayed.  
  72.  
  73. Moving back one level, we can also send characters to the screen by
  74. using MS-DOS.  Simply tell MS-DOS which character(s) to display and
  75. it will translate this request into one or more BIOS requests to
  76. display the characters.  This description also gives some indication
  77. of the issues involved in 'ibm pc compatibility'.  If a program makes
  78. only MS-DOS requests only thru MS-DOS defined entry points, it will
  79. run on any machine that runs MS-DOS.  Likewise, any program that uses
  80. BIOS facilities will run on machines that have an ibm compatible
  81. BIOS.  Programs which write directly to the ibm hardware will work
  82. only with hardware that is functionally identical to ibm's.
  83.  
  84. MS-DOS 2.1 as distributed by IBM (and most compatibles) includes a
  85. device driver called ANSI.SYS, which is a data stream interpreter
  86. which makes an ibm pc (in an *extremely* limited sense) behave as a
  87. vt100 (ANSI X3.64) terminal.  ANSI.SYS is installed by creating a
  88. file named CONFIG.SYS which includes the line:
  89.  
  90. DEVICE=ANSI.SYS
  91.  
  92. This line causes the file named ANSI.SYS to be installed as a device
  93. driver.  This device driver causes some MS-DOS requests (int 21h and
  94. int 40h(or there abouts)) to be rerouted to this driver.  ANSI.SYS
  95. then looks to see if the data is intended for the screen, if it is
  96. intended for the screen, then ANSI.SYS looks to see if one of the
  97. pre-defined 'Escape sequences' is being sent.  ANSI.SYS translates
  98. the data stream into BIOS requests for cursor movement, print
  99. character or whatever.  I hasten to add that ANSI.SYS works ONLY with
  100. screen requests that use the MS-DOS mechanisms for writing to the
  101. screen.  Programs that use BIOS calls or write directly to the
  102. display adapter will be unaffected by this device driver.  
  103.  
  104. Finally, at long loving last, I can say that I have a termcap entry
  105. that is in some extended sense 'for the ibm-pc-xt' (it is in fact
  106. specific to ANSI.SYS).  This could be used with a terminal emulator
  107. that did no data stream interpretation *if* that emulator uses the
  108. MS-DOS entry points.
  109.  
  110. ansi.sys|IBM PC with ANSI.SYS installed as a device driver:\
  111.     :co#80:li#25:cl=\E[2J:\
  112.     :bs:am:cm=\E[%i%d;%dH:do=\E[B:nd=\E[C:up=\E[A:\
  113.     :so=\E[7m:se=\E[0m:kb=^H:\
  114.     :ce=\E[K:ho=\E[H:pt:
  115.  
  116.  
  117.  
  118.     Dan Kary
  119.     North Dakota State University
  120.     Computer Science Department
  121.     300 Minard Hall
  122.     Fargo, ND   58102
  123.     ihnp4!dicomed!nckary
  124.