home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
cieregulus
/
cie680hlp.txt
< prev
Wrap
Text File
|
2020-01-01
|
10KB
|
189 lines
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 <Ret> 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 <ret> 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: <lf> stty sane <lf> 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 <setup> 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.