Columbia Kermit/kermit.zip/intelmdsb/mdsmit.bwr

Text File | 2020-01-01 | 6KB | 152 lines

            Notes and Warnings for Intel ISIS Kermit


Program Size:

    This version of ISIS Kermit requires more than 32K of main
storage.  If this is a serious problem for you, please make that
fact known.


Escape character:

    The escape character protocol in Intel ISIS Kermit now
matches that of other versions of Kermit, but the default escape
character itself is still control-D.  This is primarily due to the
fact that control-] is not active on all Intel workstation keyboards.
If all of your workstations can generate a alternate key which you
prefer, you can implement the alternate key in one of two ways:
(1) alter the initial value of the escape character in KERMIT.P80
and regenerate Kermit, or (2) use the SET ESCAPE command, either
from the keyboard or in an .INI file.


Loss of incoming characters during CONNECT:

    Supported baud rates range from 110 through 19200, depending
on workstation model.  However, at higher baud rates there is a
possibility that characters will be lost, particularly in CONNECT
mode when data is being transfered in both directions at once.  This
problem seems most evident with a Series IV, which is especially
likely to lose characters when scrolling the screen, i.e. immediately
after receiving a carriage return character.  Evidently the Series IV
NDX screen-mapping routines add extra overhead to the screen display
functions.

    The screen data loss problem does not seem to affect file
transfer operations at any speed up to at least 4800 baud.  The only
ill effect is the lost of one or two characters at the beginning of
each line of displayed text.  However, this can be a problem if you are
connected to a system which uses short prompt strings, as it is possible
that the prompts will be lost.  If a future version of ISIS Kermit
implements session logging, this will be a more serious problem.

    It is possible that this data loss problem could be solved by
using interrupts to capture incoming data.  I tried to use interrupts
for time out detection and data capture, but didn't have any success
in the time that I had available to work on it.


Multi-file SEND Requests:

    This version of ISIS Kermit does not support the specifying
of multiple file names on a SEND command.  This option was removed so
that an option remote system file name could be specified on the
command.  The new TAKE command allows the user to transfer a number
of files (at the expense of a certain amount of initial effort).


Future Development Suggestions:

    - Interrupt-driven comm port data capture.  See the remarks
above regarding data loss.

    - Wild card transfers.

    - Restructuring the program to segregate the state machine
logic into one routine, such as is the case with C Kermit.


Miscellaneous:

    If you have further questions or comments, I may be able to
give them some attention, depending on exactly what I am involved with
at the moment.

        William H. Boyd, Jr.
        Hughes Aircraft Company
        Bldg. 635, M/S KA266
        1901 W. Malvern Ave.
        Fullerton, CA 92634

        [phone]

        CompuServe ID: 74666,1533 (occasionally)

------------------------------

Date: 17 Apr 87 17:48:00 EDT
From: John R. Williams <[e-mail]>
Subject: ISIS Kermit - fixes and frustrations
Keywords: ISIS    Kermit, MDS Kermit, iPDS

For those of you who have implemented Bill Boyd's latest version of ISIS
Kermit (see the Digest, Volume 6, Number 9) I have an interim fix for the
problem of losing characters in Connect mode and a plea for help concerning
the program's performance.  I have not been able to contact Mr. Boyd.

First, the fix.  This will allow at least some of you to operate in Connect
mode at 4800 and 9600 baud.  It will still occasionally miss characters at
4800 baud and consistently miss 1 or 2 characters per line at 9600 baud,
but in my case, at least, 9600 baud Connect mode operation is now usable, if
not perfect.

In the Connect Module, find the statement that looks something like this:

    if ready(port) > 0 then call putc(getc(port, 0);

Declare a temporary variable, such as "i", and then enclose the above
statement in a DO loop, like this:

    declare i byte;
        .
        .
        .


    do i = 1 to 200;
      if ready(port) > 0 then call putc(getc(port), 0);
    end;

This causes the program to read the input port 200 times for every time it
checks for keyboard input.  The loop termination value 200 was determined
empirically.  You may find that another value works better for you.  I also
replaced "putc" with "co", which bypasses the status checking provided by
"putc".  That may not provide any real benefit.

Next, performance considerations.  You may be interested to know that in my
system file transfer at 19200 baud occurs with no errors.  The only problem is
that screen output at 19200 is pure gibberish - it misses 50 to 70 per cent of
the characters, even with the fix noted above.

The performance problem that concerns me with the new version, however, is
that for some reason when receiving files the time between packets is
excessively long, averaging about six seconds!  The old version is at least 10
times faster under the same circumstances, and I cannot find any code
differences to account for it.  The delay is apparently in procedure RPACK
where it waits to receive the SOH.  If anyone has an explanation and a fix for
this condition, I am most anxious to hear from you!

All my experience with ISIS Kermit has been using a Series III MDS, with a
Winchester disk, connected directly to a VAX 11/782 terminal port (no modem).
The VAX is running VMS Kermit-32 version 3.2.77 under VMS 4.4.

Also, if anyone has had any success using ISIS Kermit on an iPDS, I'd like to
share experiences with you.  In my version, the iPDS receives VAX files OK but
fails miserably when sending.

John

------------------------------