USING OLD-KERMIT ON CIE 680/20 MICROCOMPUTER: (with Regulus operating system) David S. Lawyer 406 Verano Pl Irvine, CA 92715 January 1988 This is a description of an old and obsolete Kermit program for communication between computers. The new C-Kermit has made this obsolete for most CIE systems. However, it may still be of use if you have a CIE computer with only 256K of RAM memory since the C-Kermit's connect function executes extremely slowly unless you have more than 256K of RAM. Even if you have 512K of RAM, the connect mode using this old program is faster than that for the C-Kermit and you might want to use this only for connecting. If you want to revise the C-Kermit source code you may want to modify its connect function based on the connect part of this old source code. Kermit is a protocall used to communicate between computers. The program named kerm (source code kerm.c in the C language) is a "Unix Kermit" program modified at UCI for use on the CIE computer. The connect mode of Kermit will make the CIE behave as if it were only a terminal, permitting you to connect to a remote computer through one of the connectors on the rear of the CIE (provided that you have connected an appropriate cable leading to another computer). Once you are connected you may use the remote computer to do your work. While you are connected you may also utilize both the CIE Kermit and the Kermit on the remote computer to transmit files between the remote and the CIE. Of course, you may also use Kermit to connect to a modem or some kind of a switch which will give you a choice of computers with which to connect to. Provided that you have set up the proper aliases the the Regulus shell you may: I. To connect to the remote unit type: "con" (without the quotes). Then do whatever is required to log in to the remote unit (or dial in case of a modem). When finished, type "^\c" to exit back to your shell. Unless you desire to stay logged on to a remote computer, log off it first before hitting "^\c". If you are planning to make a file transfer with the remote computer, you should of course remain logged on. Ia. If you try to connect again, you may get no response from the remote unit because you may have previously logged out or the remote unit has otherwise given up on you. The usual way to try to resolve this problem is to turn off your terminal and start over. However, the CIE takes time to boot so you may simulate turning off this terminal by typing "drop" to the CIE "%" prompt to drop the line. (The voltage on the DTR pin 20 of the RS232 connector on the back of the CIE goes negative.) II. To send files to the CIE first log on as per I. above. Then start the remote Kermit by typing "KERMIT". Then type "SEND" followed by the name (or list of names if allowed) of a file(s) to send. Be sure they are spelled correctly and in the right case (no understandable error message will be received if they're not correct). Then hit to give the send command to the remote computer. Then hit "^\c" to get back to CIE and type "rec" to command your CIE to received what is being sent. The remote computer will only wait about a minute for you to type "rec", so don't hesitate too long. III. To send files to the remote computer do about the same as for send in II. above but give a "REC" command to the remote computer and finally a "send" command to the CIE followed by a list of files to send. The use of wildcards (globbing) such as "*" in file names is allowed. Note that after sending or receiving your'e still logged in to the remote computer so you might want to connect again using "con" and then logout from the remote computer. You may have to hit the key a few times to get the remote computer to respond. If you want to make the remote computer (or remote unit) think that you've turned off the power to your computer, type "drop" to drop the voltage on the wire which connects to pin 20 of the RS-232 plug on the back of the CIE. This should drop your connection to the remote unit and allow you to login anew (possibly to another computer). How Kermit does it: Data is transmitted in packets of 94 characters each. Both the CIE and the remote computer run their own Kermit programs. At first a handshake message is passed. Next the file names are sent and finally the packets of data. The program which you run on the CIE is one which was written in C for Unix systems. It had to be modified to get it to work on the CIE (and it has not been thoroughly tested for bugs). The C source code is in file kerm.c and the compiled binary is named "kerm". To compile the source code, you may simply type cc -v -o kerm.c. The source code tersely explains a little on how to use it. For a full explanation of Kermit see the book "Kermit ..." by Frank da Cruz. When debugging, use option flags d (or dd for the highest level of debugging). The commands described above are nothing more than aliases for calls to kerm. To see them type "alias" at the prompt %. In order to use these commands you must put aliases into your .login or .nshrc file. Here are some examples: alias con kerm clb /dev/tty1 4800 alias rec kerm rflb /dev/tty1 4800 alias send kerm sflb /dev/tty1 4800 alias drop stty 0 < /dev/tty1 The above assumes that you have connected your CIE to the remote computer via serial port 1 (tty1) using a RS232-C plug. In order to use port 1 it must be disabled in the etc/ttys file so that no login process is running on it (in a futile attempt to get the remote computer to login to your CIE). Do this by either editing etc/ttys to change the line starting with "11" to "01", or give the command "setport 1 -d". These settings will be in effect permanently (until you change them again). Since the Kermit program has disabled the break key, there is no way to interrupt Kermit when its running. If you don't want to have Kermit disable the break key, edit the kerm.c source code in the function "setraw()" per the tty(dev) help file (use the c_iflag). If you suspect that you have abnormally lost the connection with the remote computer, type "^\h" to see if Kermits is still running. If it's not and characters do not seem to be echoing correctly (if at all) to your CRT then type: stty sane to try and restore your terminal interface to its non-Kermit configuration. Tabs can be a problem. The Kermit program faithfully transmits tabs but the meaning of a tab character may depend on the computer you are using and how you have told it to interpret tab characters. The default tabset on the CIE is 4 which means that tabs are translated to spaces based on tabstops every fourth character. Many other computer use tabstops every eight characters. Thus a document created on the CIE may look quite different when displayed on another computer unless its tabstops are reset to a spacing of every-four. The remote computer needs to know the terminal type you are using. The CIE 680/20 seems to have a console similar to a CIT-80 terminal. Your host computer may have a satisfactory /etc/termcap entry for the CIT80. Here is on which I wrote as the existing one was unsatisfactory: # Cit80 is Nonstandard ANSI. Some differences are shown in Appendix C # of the CIT-80 manual. Clearing screen doesn't home cursor but cs needs to # home cursor for vi. # Initialization: set ANSI, exit Keypad Application mode, set cursor key # application mode, set auto wraparound, reset reverse video, set ASCII chars, # set normal video attributes, reset new line mode, scrolling region is lines # 1 thru 24, goto start of last line (otherwise cursor may not be on a blank # line). CT|cit80|cit 80|Citoh 80:\ :bl=^G:co#80:li#24:am:mi:ms:bs:pt:cr=^M:nl=^J:ta=^I:\ :up=\E[A:do=^J:nd=\E[C:le=^H:ho=\E[H:sc=\E7:rc=\E8:\ :cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:\ :cl=\E[;H\E[2J:ce=\E[K:cd=\E[J:\ :so=\E[7m:se=\E[0m:us=\E[4m:ue=\E[m:\ :md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:\ :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:l1=PF1:l2=PF2:l3=PF3:l4=PF4:\ :sr=\EM:sf=\ED:\ :im=\E[>4h:ei=\E[>4l:al=\E[1L:dl=\E[1M:dc=\E[1P:\ :ve\E[2v\E[0v:vi=\E[1v:vs=\E[3v:\ :is=\E<\E>\E[?1h\E[?7h\E[?5l^O\E(B\E[0m\E[20l\E[1;24r\E[24;1H\ :rs=\E>\E[?5l\E[?7l: Sometimes vt100 will work OK but it may be inefficient. Another logical choice would seem to be that of putting the CIE in vt52 mode and then declaring it to be a vt52, but this has resulted in incorrect performance of the vi editor on the host computer, and vt52 does not always seem to work correctly on the CIE even when Kermit is not being used. BUGS: In connect, a character is often lost for every few lines received by the CIE from the remote computer. On the remote computer, you may make a test file with 80 characters per line. Displaying this using cat will illustrate this problem. One fix is to set tty0 (your CRT) to 4800 baud. You may do this by typing "stty 4800" and then change the terminal to 4800 baud using the key. When using vi on a remote computer (in Kermit connect mode), sending ^L and other scrolling commands to vi will result in vi sending out the requested data immediately even if the output queue at the remote terminal buffer was waiting on a ^S (Xoff). If the CIE'e terminal buffers are nearly full at this time, overflow will occur and data will be lost. The above may be the cause of missing lines which are sometimes observed when using vi at 9600 baud. The situation is quite complicated as data from a remote computer to the CIE flows thru 3 terminal buffers (the remote's, tty1, and tty0). The data may be processed at each buffer and the CIE's processing will eat any ^S or ^Q byte if Xon/Xoff protocall is in effect.