Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!rutgers!bellcore!faline!thumper!tr From: tr@thumper.bellcore.com (tom reingold) Newsgroups: comp.sys.ibm.pc Subject: Enclosed is MS-Kermit document (part 7 of 7) Message-ID: <899@thumper.bellcore.com> Date: 31 Dec 87 13:15:55 GMT Organization: Bellcore, Morristown, Noo Joizy Lines: 465 @@@@@@@@@@@@@@@@@@@@ Cut and concatenate here. @@@@@@@@@@@@@@@@@@@@ ESC [ > Ps h SM Same as ESC x Ps ESC [ > Ps l RM Same as ESC y Ps Plus most of the ANSI escape sequences listed for the VT102. 1.16. More Technical Summaries Under normal circumstances, MS-Kermit takes advantage of the computer's hardware, and often bypasses DOS (sometimes even BIOS) to achieve high perfor- mance, to exercise special machine features, or to produce an attractive screen display. Thus, it is not in all respects a "well behaved" DOS program. MS-Kermit redirects interrupts 0BH (COM2/4) or 0CH (COM1/3), 14H, 23H, 24H and returns them when done. It uses the BIOS for keyboard, video display, and sys- tem information interrupts. It examines segment 40H for EGA operating modes and it does direct screen reads and writes. Memory for the screen roll back buffer is negotiated with DOS to leave room for a second copy of COMMAND.COM to run tasks within Kermit; about 80KB to 120KB is needed for the entire program. Video page zero is normally used, but page one is employed to save screens with non-standard dimensions. Hercules and graphics mode displays are not sup- ported. Kermit's timing delays are dynamically adjusted each time the serial port is started to accomodate machines of different speeds; duration of the normal software timing loop is measured with the hardware timer chip and loop- ing is adjusted to produce uniform delays on 8088 through 80386 machines. 1.16.1. Use of MS-Kermit in Windowing Environments Kermit-MS can operate with various environments, such as TopView, DESqview, and MS Windows. It runs in an active window under MS Windows, accepts cut and paste material, talks with mice, and shrinks to an icon (a boxed Ker). Con- struction of .PIF files can proceed by stating that Kermit-MS is unusually well behaved (not really true of course but it's an effective strategy), does not use the serial ports (sic! MS Windows), needs from 80KB to 120KB; some ex- perimenting may be needed for your system. Two items, however: manual screen roll back does not work well under MS Windows and Windows may object when the terminal mode screen size is commanded to change. 1.16.2. Use of MS-Kermit with External Device Drivers 1.16.3. Use of Kermit-MS with External Device Drivers It is often desirable to supplement or modify the behavior of a DOS program by loading it with special external device drivers. These drivers may operate at either the DOS or BIOS level. When Kermit-MS accesses the BIOS directly, DOS-level drivers are ineffective. When Kermit accesses the hardware directly, both the DOS and the BIOS level drivers are locked out. Kermit-MS provides several mechanisms to allow these external drivers to operate as intended. Here are a few examples: - IBM's ANSI.SYS console driver operates at the DOS level. It allows the major IBM PC keys to be redefined, and also interprets selected ANSI-format escape sequences for screen control. It works fine at Kermit-MS command level, except SHOW KEY does not recognize strings assigned to keys via ANSI.SYS, and fine at CONNECT level. To use ANSI.SYS at CONNECT level, issue the Kermit-MS commands SET KEY OFF (to read keys via DOS) and SET TERMINAL NONE (to display characters through DOS). - Blind people often have speaking or Braille machines attached to their PCs. DOS-level device drivers are generally used to redirect screen output to these devices, which works OK at DOS or MS-Kermit command level. SET TERMINAL NONE will allow this redirection to take place during CONNECT. But these devices also need to have the computer's output appear as a coherent stream of text, so users should also take care to inform the remote host to format its output for a "dumb" or hardcopy terminal. In addition, Kermit-MS' normal file transfer display does not mesh well with these devices, but that can be remedied using SET DISPLAY SERIAL. - People with motor impairments may be using special keyboard replace- ments supported by DOS-level device drivers. As with ANSI.SYS, Kermit-MS may be directed to use such keyboard drivers with the com- mand SET KEY OFF. - Other keyboard drivers are available that work, like Kermit-MS, at BIOS level. Examples include ProKey and SuperKey. These may be used at DOS or Kermit-MS command level as well as during CONNECT. - Conceivably, drivers exist that allow DOS communication programs to emulate terminals other than ANSI. You should be able to use them, if they exist, in conjunction with Kermit-MS by telling Kermit to SET TERMINAL NONE, but the speed may not be high because of the interven- ing DOS call. 1.16.4. Treatment of Inbound Characters During Terminal Emulation Many things can happen to a character that arrives at the communication port before you see it, depending on all the factors mentioned above. The actual sequence of events is: 1. Obtain character from serial port 2. Remove high bit if parity is other than none 3. Detect and remove xon/xoff if FLOW is XON/XOFF 4. If DEBUG is active (ON or SESSION) then put character to debug style display, otherwise: 5. If transparent printing is active (for VT102 emulators) then print the character but do not show it on the display, otherwise: 6. Remove high-order bit if DISPLAY is 7-bit 7. Translate if TRANSLATE INPUT is ON, but skip this step if an escape sequence is in progress 8. If LOG SESSION is active then copy character to the log file 9. Pass the character to the terminal emulator for interpretation or display. 1.16.5. Kermit-MS/IBM Serial Port Information, a Technical Description Kermit-MS for IBM PC's and compatibles does testing of serial ports before use. This section describes those tests so users may understand what Kermit does. When a serial port is selected by the SET PORT COMx command Kermit looks at low memory addresses in segment 40H assigned to hold the base address of each COMx port; COM1 is in word 40:0H, COM2 is in word 40:2H, and so on. If the value in the appropriate word is binary zero then Kermit declares the port to be un- available. Otherwise, Kermit runs read-only (i.e., safe) tests at the base ad- dress to validate the presence of an official 8250 UART chip. If the tests fail Kermit indicates it will do i/o through the slow Bios pathway; some PC clones need to work this way even though the Bios has speed problems even at 1200 baud. Otherwise, interrupt driven i/o will be done through the 8250 UART (that is very fast). The IBM PCjr has a special case when the internal modem is present but a normal COM1 serial port is not. Kermit detects this situation and makes a copy of the modem's base address into the COM2 address word at 40:0H so that the modem can be used as a COM2 device. If both items are present Kermit begins with the modem on COM2. If the modem is absent, then the serial port on COM1 is chosen. In other words, Kermit tries to find the modem wherever it is and then calls it COM2. Many machines now have more than two serial ports, yet there is no standard about addresses for COM3 and COM4. PC DOS 3.30 does not assign them either be- cause it is really a problem of the system ROM Bios boot code run when the power is turned on. However, Kermit will use COM3 and/or COM4 if the base ad- dress of a port is placed in low memory words 40:4H (COM3) or 40:6H (COM4); the tests described above are then carried out. One restriction is that the Inter- rupt ReQuest number (IRQ in the serial port board manual) must be IRQ4 for COM3 (and for COM1) and IRQ3 for COM4 (and for COM2). Check the board and its manual. DOS utility DEBUG can be used to create a short program to insert the board's addresses into the segment 40H memory locations; a sample program is given below. ------------------------------------------------------------------------------- Serial Port Base Address IRQ Conventions COM1 03F8H 4 IBM standard COM2 02F8H 3 IBM standard COM3 ? 4 Board, Kermit wants IRQ4 COM4 ? 3 Board, Kermit wants IRQ3 Table 1-7: IBM PC/XT/AT Serial Port Numbers ------------------------------------------------------------------------------- The addresses shown as query marks are to be found in the board's reference manual; values such as 2E8H and 2E0H would be common. However, there is no standard for anything to do with COM3 and COM4. Assuming that you have selected an address in harmony with the rest of the sys- tem (good luck on that part), set the board's switches or jumpers, and use DEBUG to insert the address(es) in segment 40H memory. The example below creates a small program named SETCOM3.COM to put address 02E8H into the memory word 40:04H for COM3 and writes the program to drive A. (Disregard the xxxx items below): A> DEBUG don't type these comments -n a:setcom3.com sets name of output file -a assemble command xxxx:100 mov ax,40 value 40h xxxx:103 mov es,ax put it into register es xxxx:105 mov ah,02 the 02 part of 02E8H xxxx:107 mov al,e8 the E8 part of same xxxx:109 es: xxxx:10A mov [4],ax store in 40:4 for com3 ([6] for com4)> xxxx:10D int 20 return to DOS xxxx:10F blank line to end assemble mode -r cx show contents of register cx CX 0000 : 0f set register cx to write 0fh bytes -w write material to the disk file -q quit debug A> DEBUG setcom3.com -u unassemble to see if all is well -q quit debug Note, for COM4, use [6] above rather than [4], and of course employ your board's port address in place of 02E8H. Check the manual. Finally, try it: A> setcom3 run the program A> DEBUG now see what's down there -d 40:00 display bytes in seg 40H ( Shows many bytes. See yours? Good. ) -q A A small side effect noted in practice is the first time the extra port is used there may be garbage from it. Just return to the Kermit prompt and try again, if necessary SET PORT to the other COM lines momentarily, all should be well the second time. More technical comments, for those with an interest. When Kermit finishes with a port it disables interrupts for that serial port and the IRQ level since many devices can share the same Interrupt ReQuest line but only one device at a time can be active on an IRQ. If you find that transmissions are good but there is no reception then another device has stolen the IRQ; disable it or find a guru. Kermit will work with non-standard addresses for COM1 and COM2 but the IRQ's must be as in the table above. Accessing a non-existent port produces a mes- sage and all communications are discarded safely in the bit bucket. 1.16.6. Kermit-MS/IBM Printer Control, a Technical Description Kermit-MS accesses the system printer through DOS calls several ways; neither the Bios nor the hardware are used. Files directed to the printer by the SET DESTINATION PRINTER command are written by opening a file with the name PRN (DOS's name for the system printer) and writing to it the same as to a disk file; DOS provides limited buffering. LOGging to device PRN works the same way, as can be noticed by the last line or so not being printed until the log file is CLOSED. DOS is used again while emulating a terminal in CONNECT mode. If the VT102 emulator found in the IBM PC is used for transparent or Controller printing (via arcane escape sequences sent from the host) single characters are written to DOS file handle 4, the DOS standard print device. If the screen is echoed to the printer via the typical Control PrtSc key combination, or equiv- alent, single characters are written by the DOS function 05H Printer Output call. In both cases of terminal emulation the printer's ready status is found by the DOS IOCTL 44H call. Only the Control PrtSc case results in the PRN mes- sage being displayed on the status line. Finally, the classical IBM PC Shift PrtSc command to copy the whole screen to the printer is unknown to Kermit be- cause the system Bios traps the key combination and does not tell Kermit about it. If the Control P command is given to DOS before Kermit starts then again characters are echoed by the system Bios without Kermit's knowledge; this situation can result in lost characters. Print spoolers generally operate by being told an existing filename and then in the background they steal cpu cycles to read from disk and write to the printer. The DOS PRINT command invokes such a spooler. Although an active Kermit does not feed these software programs directly the spooler and Kermit can compete for cpu cycles and characters can be lost. If a non-DOS resident program intercepts characters destined for the printer device and spools them Kermit does not know about it and similar competion can occur. During file transfers printing is carefully sequenced to occur only when the local Kermit is in control of the communications line so that a small pause will not result in missing characters arriving at the serial port. When ter- minal emulation is active then printing competes for cpu time with the serial port routines. Generally, the serial port wins such contests if the port is interrupt driven (Generic Kermit is not interrupt driven, so beware). However, the printing itself can use enough cpu cycles to delay processing of characters to the screen and eventually the receive buffer of the serial port fills to the high water mark and an XOFF flow control character is sent to the host to suspend further transmissions until we send an XON. If FLOW is NONE then ex- pect lost characters at the serial port. Experience with ordinary IBM PC's through 80386 machines at very high baud rates indicates no characters are lost when FLOW is XON/XOFF. However, it is possible on some machines for the printer to have priority over the serial port, and hence to have lost charac- ters, especially if a Terminate Stay Resident program intercepts characters destined for the printer and keeps interrupts turned off too long. 1.16.7. CTTY COMx for IBM Machines The DOS command CTTY COMx redirects the standard input and output from the keyboard and screen, respectively, to the indicated communications channel. If a Kermit Server is operated this way, "through the back port", then both DOS and Kermit can access the port hardware simultaneously; a deadlock develops on IBM machines. The items below refer to only the IBM version of Kermit-MS. Kermit-MS/IBM version 2.30 successfully resolves the deadlock in the following manner. When Kermit requires the serial port it also attaches itself to Inter- rupt 14H, the Bios RS232 serial port routine. Code within Kermit receives the DOS serial port requests via Interrupt 14H and either passes the request to the Bios if the COM line is not that used by Kermit or it handles the request in- ternally for conflicting situations. When the same port is used by both DOS and Kermit, Kermit discards DOS output material (typically a prompt, but could be the dreaded Abort, Retry, Ignore message) and returns a success code to DOS, it returns an ascii Backspace code to DOS read requests (this is a key item to keep DOS complacent while Kermit communicates), and it returns reasonable status for modem status. The interception ceases when Kermit releases the port, such as when the Kermit prompt is displayed, and this lets DOS converse out the serial port. It is worth restating that a large number of programs bypass DOS to achieve higher performance. When such programs are started through the back door they may still require input from the real keyboard and will hang, waiting for it. There is nothing to do about this situation except a) don't let it happen, b) contact the local operator to push some keys, c) wait for better operating sys- tems (OS/2?); some choices! Kermit-MS is not a Bulletin Board Server. 1.16.8. Screen sizes and the EGA board, IBM versions Support has been included for Enhanced Graphics Adapter (EGA) video display boards which can be configured for other than the standard 80 columns by 25 lines, say 132 columns or 43 lines or other. One board, the Tseng Labs EVA board with the 132 column kit installed, can be controlled directly by Kermit for 80/132 column changes. Other boards need to be placed in the desired dis- play mode by the user. Kermit then adapts to the settings if the board obeys standard rules for using the Bios EGA memory areas in segment 40H. The Video-7 Vega Deluxe board has been used successfully in all screen sizes, including 132 columns by 43 lines, with an NEC Multisync monitor. The IBM EGA board has several noteworthy bugs which are now standards. One is the cursor dots are not always on the correct scan lines when the number of screen lines is other than 25. Kermit-MS attempts to compensate for this at- tribute. Screen roll back space is fixed in size so there are fewer pages for more dense screens; standard screens use an internal buffer, non-standard screens use a buffer plus video page 1. ANSI.SYS is hard coded for 25 line dis- plays so all DOS i/o will eventually overwrite itself on line 25; the emulator does not use DOS i/o. Commercial replacements for ANSI.SYS should be able to use all screen lines. Screen dumps work correctly if done with Kermit commands. DOS PrintScreen may or may not, depending on your EGA board. When the VT102 receives escape sequences to change between 80 and 132 column modes the screen is reset and the Tseng Labs EVA board is asked to change modes (but only if that board is present); other display adapters are left in their current state. The right margin is enforced strongly so a board in 132 column mode will not display material to the right of column 80 if the emulator is in 80 column mode. Similarly, material to the right of column 80 is not preserved in the emulator if the display adapter is operating in 80 column mode; real VT102s keep that invisible material in hardware memory whereas the emulator does not. Reference is made to line 25 in the emulator; this is normally the status/mode line in Kermit. Real VT102's have only 24 line displays. If the display adapter is set for a different number of lines per screen then the 25th line is interpreted to mean the bottom display adapter line, such as line 43. Should the host access the status/mode line then the line is declared to be disabled (same as SET MODE OFF) so that Kermit's own status information does not over- write the host's when the screen is restored. Toggling a disabled mode line has no effect; only SET MODE ON will enable it again. The Heath-19 terminal has the unusual feature that disabling the mode line (ESC y 1) also clears it. 1.16.9. Kermit-MS/IBM on Local Area Networks, a Technical Description The IBM version of Kermit-MS has support for the IBM Local Area Network NetBios (and emulators) interface, Interrupt 5CH, with additional support for selected vendor specific features (presently just AT&T STARLAN), activated by the SET PORT NET command, described above. Communications across a LAN occur through the NetBios interface using virtual circuits (Sessions), named nodes, and con- ventional NetBios packets. Kermit-MS does not use LAN terminal interface packages nor the Redirector or similar functions. Kermit LAN operations are harmonious with normal network activity and many pairs of Kermits can communicate simultaneously. Kermit does not use conven- tional LAN File Server functions. Kermit uses the standard NetBios interrupt 5CH interface, for those who need to know such things, which means it will run on most LANS including IBM PC Net, IBM Token Ring, AT&T STARLAN, and many others, and will run with Novell NetWare software. Presently, Kermit knows some details of STARLAN and is able to send a BREAK across the net and can use ISN node names with long path parts. If STARLAN is not operating these features are not available. As more detailed information becomes available special features of other networks can be built-in. The sequence of operations is similar for a client or server Kermit. The SET PORT NET command is issued by both. This command causes Kermit to validate the presence of the Interrupt 5CH interface, test for vendor additions, test for a session already underway, establish and display a unique Kermit node name, but not make a network session. If an earlier LAN session is still active then the current remote node name field of the command is examined for presence of a name. If a name is given then Kermit asks the user whether to RESUME the session or start a NEW one. Starting a new one results in Kermit hanging up the old session before proceed- ing; resuming an old one requires no further work at this point. When Kermit attaches to the network for the first time it needs to select a unique node name so that two systems can form a Session by using these names as addresses. Kermit uses a simple algorithm to make the name. Kermit probes the network adapter board/software for the name of the local system. If the name is present Kermit makes its own name by appending a dot K (.K) to the local name. If the local name is absent then Kermit first tries a standard name of "mskermit.K"; should the network report that the name is not unique (another node is using the name) then the user is asked to choose a name. This process continues until a unique name is obtained or the user decides to quit. The final Kermit node name is reported on the screen; client Kermits will need to know the name of the server Kermit. Communication across the LAN begins differently for client and server Kermits. The server must be started first, by simply placing a Kermit in server mode. This results in a network Listen request being posted so that arriving packets with the correct node name can be delivered to the server Kermit. Next, a client Kermit tries to connect to the server by issuing a Kermit server command to the proper node name (as given in the client's SET PORT NET node command); REMOTE WHO is a satisfactory choice. The client machine actually issues a net- work Call to the server's node name to make a connection and then follows it with data packets holding the Kermit server request. The initial exchange of packets establishes a particular virtual circuit between the two nodes. If the connection cannot be started then the client Kermit reports this fact to the user. The most common causes of a failure at this point are: 1. The client Kermit did not specify the correct server Kermit node name (spelling errors, wrong case for letters, missing dot K), 2. One or both machines are using a network adapter board which is not the first in the machine; Kermit uses only the first board, 3. The LAN NetBios emulator does not fully support IBM standard virtual circuits, 4. The server machine was not started on the network before the client. A virtual circuit will be broken if a sender or receiver gets no response to a request within a short time interval set by the LAN hardware/software. However, the LAN procedures within Kermit automatically reestablish the circuit transparently to the user when new information is communicated; the last used remote node name is remembered internally for this purpose. This also means the server Kermit will respond to a connection from a new client Kermit if the first client is idle for say a minute or so. A session can be terminated by the user by issuing the HANGUP command or by exiting Kermit. A session will not be broken this way if the user on the client Kermit changes to a regular serial port. Finally, when Kermit returns control to DOS, but not via the Push command, its unique Kermit node name is removed from the network adapter board. During network communications Kermit uses network packets holding 256 bytes of data. If both Kermits are given the command SET RECEIVE PACKET 1000 then the network and Kermit will be used to best efficiency. Experience has shown that the client Kermit should have its TIMER OFF because the server may be asked to do an operation via DOS which does not complete before the client side would timeout. An observation of some token passing networks indicates that Kermit packets slightly longer than 256, 512, etc bytes result in marked slowing down because the remaining small piece is not sent until a net timer expires. Carrier sense (Ethernet, STARLAN) boards seem to be more agressive and export small packets immediately. Kermit can access files on the LAN file server via DOS even while using the LAN as a communications medium. Network administrators should note this point be- cause a user operating Kermit in Server mode can allow his or her file server directories to be available to other network users also running Kermit, without additional security checking of the other users. The network drives visible to the Server Kermit can become devices available for Kermit-to-Kermit file trans- fers, etc, unless the DISABLE command is used to confine access to the current disk and directory. A corollary is when files are accessible to DOS commands they can become public. @@@@@@@@@@@@@@@@@@@@ Cut and concatenate here. @@@@@@@@@@@@@@@@@@@@ -- Tom Reingold INTERNET: tr@bellcore.bellcore.com Bell Communications Research UUCP: rutgers!bellcore!tr 435 South St room 2L350 SOUNDNET: (201) 829-4622 [work] Morristown, NJ 07960 (201) 287-2345 [home]