TEXAS INSTRUMENTS (TM) - 990 MINICOMPUTER - DX10 KERMIT (TM) Author: Paul W. Madaus Johnson Controls, Inc. M-66 507 E. Michigan St. Milwaukee, WI 53201 (414) 274-4528 PLEASE READ THE LAST PAGE OF THIS DOCUMENT BEFORE CONTINUING. This version of KERMIT was written for the TI-990 family of minicomputers running the DX10 operating system. The KERMIT source used for this TI version originated from a version of KERMIT designed to run on the Sperry(UNIVAC) 1100. I chose to convert this version of KERMIT because of its heavy use of standard Pascal. Before continuing further, I wish to credit the base of this TI version of KERMIT(i.e. the Univac Pascal source code) to: Edgar Butt (LAST KNOWN ADDRESS) Computer Science Center University of Maryland College Park, Maryland 20742 Phone (301) 454-2946 The TI version of KERMIT, referenced herein as KERMIT, was written under DX10 O/S Rel. 3.7.0. The program was written using TI Pascal(TIP) Rel. 1.8.0. TIP is a superset of standard Pascal. Some TIP procedures were used within KERMIT, especially SVC$ for low level I/O. The program also consists of one external procedure, written in TI-990 assembly language, called SETPDT. The TI Pascal Configuration processor(program splitter) was not used for portability reasons, however a user may split the program into modules and use XCONFIG if one so desires. KERMIT can be initiated from a VDT931, VDT940 or VDT911 terminal; other devices have not been tested but may also work. The included SCI(DX10 System Command Interpreter) procedure is used to bid or call the KERMIT task, and may have to be modified to fit a particular system's environment. The KERMIT port(i.e. remote port to modem or remote system) is generated into the system using XGEN. The following device configuration was extracted from a .S$SYSGEN..CONFIG file and shows how I generated the KERMIT port into my system. DEVICE TYPE? VDT STxx ACCESS TYPE? RECORD TIMEOUT? 0 CHARACTER QUEUE? 128 VDT TYPE? 931 ASSOCIATED PRINTER? NO SWITCHED LINE? NO SPEED? 1200 INTERFACE TYPE? CI403 TILINE ADDRESS? >F860 CHANNEL NUMBER? 0 INTERRUPT? 11 Page 1 I was able to gain the most functionality by using the 931 DSR and CI403 interface board. The PASSTHRU mode(ref. DX10 O/S Application Programming Guide Vol. 3, Jan. 85, p. 9-38) of the 931 DSR is used to control echo and special character problems by allowing the application to gain direct control of the terminal. A KSRDSR and EIA card were initially tested with KERMIT, but extremely limited the functionality of KERMIT to packet transfer and one-way login. A user may implement other hardware configurations, but will probably have to make some program changes within the procedures INITIO, CONNECT, PRSCMD, and other procedures that use or are PASSTHRU dependent. The above CHARACTER QUEUE, and INTERRUPT LEVEL may be fine tuned as necessary. I have successfully tested KERMIT at 4800 & 9600 bauds with an IBM-PC (TM) to TI-990 direct connection, but recommend 1200 baud to start with. The remote port(CI-403/931DSR) defaults to 7-bit data and odd parity. It is possible to dynamically set these parameters on the CI-403 board from a user task(KERMIT), however I did not have time to put these enhancements into KERMIT. Therefore, users will have difficulty talking to other systems whose ports are not set at 7-bit data and odd parity, with the TI-990 as the initiating system. The cables used for remote connections from the CI-403 port are: TI Part No. 2303070-0003 to modem - straight thru signal connections (i.e. TD-TD, RCV-RCV etc.) TI Part No. 2303077-0001 direct connect - (signals are TD-RCV, RCV- TD, RTS&CTS-DCD etc.) Homemade cables with the minimum RS-232 signals work fine. An ISC type terminal is mentioned both in the KERMIT program and the bidding SCI procedure. This terminal type setting is required if your local console terminal is uppercase only, its DSR does not support PASSTHRU mode, you cannot suppress echo, or some other unusual support is needed. The setting of an ISC terminal type is left as an expert mode prompt in the bidding SCI procedure; of course this may be changed as needed. Opening the TI-990 port locally for connection to a remote system(or modem) fails due to some port initialization problems. This problem forced me to actually set two terminal init bits within the remote port device's PDT, if the SVC(low-level I/O) open fails. See the procedure SETPDT for more information on this. It would be advisable for the system administrator to hardcode the remote port name into the calling SCI procedure as a safeguard against modifying other 931 PDT's. Since software checks do exist(see procedure CHKTRM) to prevent this, my main concern is to avoid the frustration that may exist from a user not knowing the KERMIT remote port name. All commands entered within KERMIT should be uppercase only. The program can be easily modified to handle lowercase commands if needed. It is only necessary to enter the first three characters of a command,although full file pathnames must be used where appropriate. KERMIT does not support the use of synonyms within filenames that are entered in any of the commands at this point in time. Type HELP within KERMIT to view a list and brief syntax of the following supported commands. Page 2 LOG - Set logging within KERMIT. A filename may be entered, or use the default filename .KERLOGxx where xx are the digits of the user's console terminal number. The name of the default filename may be adjusted within the bidding SCI procedure - parameter number 5. Send and receive packets, reads and writes to a file, remote port and console terminal I/O errors, problems in receiving packets, send file sizes, remote port character overflows, framing, and parity errors, setting and resetting of XON and XOFF, and entering server mode are all items that are logged when logging is enabled. CONNECT - Connect to the remote port. This command is only valid in local mode and will connect your console terminal via the local KERMIT port to whatever is connected to your remote port(e.g. modem, PC, direct system connect). Once connected, type two @ (at signs) in quick sequence to return to your local KERMIT command mode. Other special character sequences are allowed for the ISC terminal, since the non-PASSTHRU capability of this terminal inhibits the user from entering important keys such as CMD, BLNK-ORNG, or DC1. If your console is an ISC terminal, then these special key sequences will be displayed to your console upon connect. Once connected to a remote system, a user may logon to that system, bring up and place the remote KERMIT into a server mode, and then escape back to your local system to initiate file transfers. It is the user's responsibility to logoff a remote system, via BYE, FINISH and reconnect, etc. SEND - Send a file from the local TI-990 system to some remote system. The local filename must be a full legal DX10 filename, no synonyms as previously mentioned. The optional remote filename can be entered in any shape or form that is legal to the remote system(where the file is being sent). If a remote filename is NOT entered, then the local filename(without parent directories) is extracted from the local pathname and used as the remote name. It is recommended that only sequential files be sent to another system. Other file types(e.g. relative record, KIF-does anybody use these??) may not produce consistent results. RECEIVE - Receive a file from a remote system and place it into the RECEIVE FILE NAME. RECEIVE is like putting your TI-990 KERMIT into a server mode for only one file. The file to be received must be sent using the send command from a remote system. KERMIT returns to the command mode after a file is received. FINISH - SHUT DOWN the remote KERMIT or at least take it out of the server mode, depending on how the remote system handles this command. I've seen it perform both of the above operations. If issued to another TI-990 system running this version of KERMIT, then the command will both end the server mode AND the KERMIT task. The user can then expect to connect to SCI upon connecting back to a TI-990 remote. BYE - SAME as above, but also log off the remote system. If a TI- 990 KERMIT receives the BYE command while in server mode, it will set a special synonym to be checked by the bidding SCI procedure. The bidding SCI procedure will check the value of this synonym before exiting and either invoke the DX10 Q(quit) command to log the user off the system if BYE was received or return the user to SCI. Page 3 TEST - Place the TI-990 KERMIT into a send only test mode. Packets are sent from KERMIT obeying all state rules, however, NO acknowledging packets from a remote system are received. This mode can be used in conjunction with logging(see LOG) to see exactly how KERMIT is building and sending its packets. Once the TEST command is set, a user must exit and re-enter KERMIT to resume normal transmissions(i.e. you can not reset the TEST comnmand). The TEST command will only test the commands SEND, FINISH and BYE. EXIT - EXIT KERMIT and return to SCI. If used locally, it is the user's responsibility to shut down and/or log off any remote KERMIT that may still be running. SERVER - Place KERMIT in a server mode. Once in the server mode, KERMIT will accept various commands(GET, BYE, FINISH, SEND) from your local machine. If a serving KERMIT is inactive, it will periodically send NAKs to your local machine to keep things from hanging(e.g. PCs). A serving KERMIT must be ended by either receiving a BYE or FINISH command. BINARY - SEND/RECEIVE a binary type file. If receiving a binary file, it is advised that you let KERMIT create the (new)file for you. If sending a binary file, the file must have a logical record length of 80 bytes. Binary data exists on TI most often as compiler object, assembler object, compressed linked object, or backup directory(BD) data. The first three items above are structured by default in 80 byte records. Backup directory files, which can be used to handle most if not all DX10 file types, can be moved from one system to another using KERMIT if blocked at 80 byte records. If you block a BD at 80 bytes, and let BD create a file for you, the BD file will adhere to the 80 record size limitations. KERMIT may blank fill records for you if they are less than 80 byte records. This proved to be of no problem for the types of binary files described above. Obviously, I do not consider moving binary data as critical as moving text data(i.e. source files), and likewise only covered the basics for binary file transfer. TEXT - SEND/RECEIVE TEXT FILE data. This mode of file transfer is the default for KERMIT. However, users may switch while in KERMIT from binary mode to text mode using this command. GET - GET a file(REMOTE FILE NAME) from a remote KERMIT that is in the server mode, and place that file in LOCAL FILE. Unlike most KERMITs, GET does not prompt you for the names of the remote and local filenames. In addition, both filenames(remote & local) must be entered. The remote filename may be any lowercase(e.g. UNIX (TM)) or uppercase filename that is legal to the remote system. The local name must be a full legal DX10 pathname. HELP - Display the list of TI-990 KERMIT supported commands. Page 4 KERMIT may be compiled using the standard TI XTIP command. Some of the options listed below may not be standard as supplied by TI. XTIP (EXECUTE TI PASCAL COMPILER )=2, SOURCE = OBJECT = LISTING = MESSAGES = ME OPTIONS = FGND,FIN,GLOBALS,MAP,GLOBALOPT,NOL/P=255 < or whatever suits you> MEM1 = MEM2 = MEM3 = 10,0 The SETPDT assembly language file must then be assembled using XMA. To link KERMIT use the standard XLE command. XLE (EXECUTE LINKAGE EDITOR) =2, CONTROL ACCESS NAME = LINKED OUTPUT ACCESS NAME = LISTING ACCESS NAME = PRINT WIDTH = PAGE LENGTH = MODE(F,B) = The link edit control file that I used is: FORMAT IMAGE,REPLACE,4 LIBRARY .SCI990.S$OBJECT LIBRARY .TIP.OBJ TASK KERMIT INCLUDE (MAIN) INCLUDE INCLUDE INCLUDE .TIP.MISC.ACCDXO END After successful compilation, assembly and linking, perform a Modify Task Entry(MTE) to make the KERMIT task priviledged. The priority may be moved up here also, if you wish. After installing the KERMIT proc(SCI procedure) onto an appropriate proc library(e.g. .S$PROC), type the proc KERMIT to initiate KERMIT, assumming that the proper hardware connections have been made. Page 5 KNOWN AREAS FOR IMPROVEMENTS 1. The connect procedure is probably the greatest. In trying to avoid any assembly language, the connect procedure became very complex, and is suseptable to losing characters to mention the least. 2. If TI-990 KERMIT is acting as a server, and you type something wrong on a remote machine, you may lose state synchronization. You may have to type the command over about four times to get the server(TI-990) back in sync. 3. Use of synonyms in DX10 filenames. 4. Lowercase as well as uppercase command support. 5. User setting of baud, parity and data word size - a capability of the CI-403. 6. Logging in TI from some other system may require special 931 emulation. If you can put up with the garbage characters until you actually get into TI KERMIT then you'll be OK. 7. Switching back and forth from binary to text or text to binary modes may cause problems. 8. VT-100 emulation. 9. and whatever other bugs that you may find. Page 6 Recompiled and relinked TI-KERMIT on March 16, 1987. Then tested TI- KERMIT with an IBM-PC XT running MS-KERMIT 2.29. On the TI side successfully tested: SEND, GET, FINISH, CONNECT-did a CTTY on PC and ran "limited" MS-DOS (TM) commands on the TI-911VDT and LOG. The following list of TI-KERMIT connections have worked in the past: a. TI-990 and TI-990 b. TI-990 and PC(PC means either IBM-XT, TI-PC, TI-Portable or COMPAQ) c. TI-990 and TI Explorer d. TI-990 and TI-Nu Machine (running UNIX). However, these TI-KERMIT connections have not been tested recently (except for the IBM-PC) and the current working status of these connections is UNKNOWN. Page 7 ONE FINAL NOTE: Unfortunately, yet a reality most of us experience, my other project work, my school work, and most importantly my family life have prevented me from completing, to my expectations, this version of KERMIT. This version has successfully transferred data between TI-990 systems and UNIX machines, PCs or other TI systems - using both direct connect and modem communications, but still contains many bugs. Once a data transfer is initiated, you can expect the process to complete with very good reliability. Bugs mainly exist within the areas of connection and state transition (between commands). The writer and Johnson Controls, Inc. is NOT liable for the use of this software, or for any effects caused by the use of this software. Anyone using this software is using it at their own risk. Any use of this software must comply with all rules, regulations and copyrights that have been established by Columbia University. It is the user's responsibility to obtain, to read and to understand all KERMIT regulations and stipulations set forth by Columbia University. TM - TRADEMARKS TEXAS INSTRUMENTS IS A REGISTERED TRADEMARK OF TEXAS INSTRUMENTS INCORPORATED. KERMIT IS A REGISTERED TRADEMARK OF HENSON ASSOCIATES, INC. (Creators of The Muppet Show) IBM IS A REGISTERED TRADEMARK OF INTERNATIONAL BUSINESS MACHINES CORPORATION. UNIX IS A TRADEMARK OF AT&T. MS-DOS IS A REGISTERED TRADEMARK OF MICROSOFT CORPORATION. Page 8