Date:     Sun, 12 Jul 87 15:38 N
From:     <BAGNARA@IBOINFN.BITNET> (Roberto Bagnara)
Subject:  Kermit68K release 1.0, file K6OAAA.BWR

Known bugs/limitations of Kermit68K/OS9.

                    *** WARNING ***   *** WARNING ***

The k6oimg.sre file was built from sources not completely up to date, so
if you use it remember that the address of the Kermit68K main author
(Roberto Bagnara) reported by the command SHOW VERSION is NOT correct.
The correct address is Bagnara@Iboinfn over Bitnet.

                    *** WARNING ***   *** WARNING ***


1.  In the current version of the program, all reads & writes are accomplished
    one character at a time.  Since most I/O in an OS-9 system is interrupt
    driven, this never causes characters to be lost in transferring files,
    but it can be rather slow on a floppy drive system.  One temporary work
    around is to do file transfers to/from a RAM disk.  This should be fixed
    in the next version.

2.  The connect mode is a straight pass-thru of all characters between the
    console and serial port.  Thus, the answer to "What kind of terminal
    emulation does it do?" is whatever your console is.

3.  The remote commands are installed, but as yet they do not work properly.
    This has been a very low priority item, especially since OS-9 systems are
    usually personal computers (or controllers) and local mode is more common.

4.  The capability to send a BREAK is dependent on the implementation of the
    specific device driver.  OS-9/68000 has an I$SetStt call (SS_Break) which
    is undocumented in the current (Version 1.2) Technical reference manual.
    If your serial port driver supports this call, Kermit can send a break.

5.  Although Kermit68K/OS9 has a 'SET BAUD' command, many OS-9 serial drivers do
    not support software selectable baud rates.  Notably, the 6850 ACIA chip
    does not have an on-board bit-rate generator.  What Kermit68K/OS9 does in
    response to the SET BAUD command is to alter the parameter PD_BAU in the
    path descriptor for the serial port.  Whether this does anything at all
    depends on the serial driver.  If there is a more accepted method of
    changing baud rates, please send EMAIL to the author, Steve Williams, at
    '{seismo|gatech|ihnp4}!ut-sally!stevew'

7.  In order to clear out the input buffer, the I$GetStt function is called
    with the SS_Ready request code.  Many drivers do not handle this request
    code properly (including mine) and return either 1 or 0.  This function
    should really return the actual number of characters in the buffer.  I
    have not had any problems, and Kermit will work with these defective
    drivers, at the expense of calling I$GetStt and I$Read too many times.
    Microware needs to add another I$SetStt call to flush the buffer.

(End of K6OAAA.BWR)
15-Jul-87 02:49:42-EDT,2849;000000000001
Return-Path: <BAGNARA%IBOINFN.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 15 Jul 87 02:49:40-EDT
Received: from IBOINFN.BITNET (BAGNARA) by CUVMA.COLUMBIA.EDU (Mailer X1.24)
 with BSMTP id 3258; Wed, 15 Jul 87 02:48:50 EDT
Date:     Wed, 15 Jul 87 08:45 N
From:     <BAGNARA@IBOINFN.BITNET> (Roberto Bagnara)
Subject:  Kermit68K release 1.0, file K6OAAA.BWR
To:       sy.fdc@cu20b.columbia.edu
X-Original-To:  FRANK

Known bugs/limitations of Kermit68K/OS9.


1.  In the current version of the program, all reads & writes are accomplished
    one character at a time.  Since most I/O in an OS-9 system is interrupt
    driven, this never causes characters to be lost in transferring files,
    but it can be rather slow on a floppy drive system.  One temporary work
    around is to do file transfers to/from a RAM disk.  This should be fixed
    in the next version.

2.  The connect mode is a straight pass-thru of all characters between the
    console and serial port.  Thus, the answer to "What kind of terminal
    emulation does it do?" is whatever your console is.

3.  The remote commands are installed, but as yet they do not work properly.
    This has been a very low priority item, especially since OS-9 systems are
    usually personal computers (or controllers) and local mode is more common.

4.  The capability to send a BREAK is dependent on the implementation of the
    specific device driver.  OS-9/68000 has an I$SetStt call (SS_Break) which
    is undocumented in the current (Version 1.2) Technical reference manual.
    If your serial port driver supports this call, Kermit can send a break.

5.  Although Kermit68K/OS9 has a 'SET BAUD' command, many OS-9 serial drivers do
    not support software selectable baud rates.  Notably, the 6850 ACIA chip
    does not have an on-board bit-rate generator.  What Kermit68K/OS9 does in
    response to the SET BAUD command is to alter the parameter PD_BAU in the
    path descriptor for the serial port.  Whether this does anything at all
    depends on the serial driver.  If there is a more accepted method of
    changing baud rates, please send EMAIL to the author, Steve Williams, at
    '{seismo|gatech|ihnp4}!ut-sally!stevew'

7.  In order to clear out the input buffer, the I$GetStt function is called
    with the SS_Ready request code.  Many drivers do not handle this request
    code properly (including mine) and return either 1 or 0.  This function
    should really return the actual number of characters in the buffer.  I
    have not had any problems, and Kermit will work with these defective
    drivers, at the expense of calling I$GetStt and I$Read too many times.
    Microware needs to add another I$SetStt call to flush the buffer.

(End of K6OAAA.BWR)
19-Sep-87 15:45:23-EDT,1292;000000000001
Return-Path: <BLARSON@ECLA.USC.EDU>
Received: from ECLA.USC.EDU by CU20B.COLUMBIA.EDU with TCP; Sat 19 Sep 87 15:45:16-EDT
Date: Sat 19 Sep 87 12:47:34-PDT
From: Bob Larson <BLARSON@ECLA.USC.EDU>
Subject: 68k kermit problems
To: info-kermit@CU20B.COLUMBIA.EDU
cc: stevew@SALLY.UTEXAS.EDU, blarson@ECLA.USC.EDU
Message-ID: <12335926398.53.BLARSON@ECLA.USC.EDU>

To build k6 on my FHL QT+ (osk version 1.2, 2.1 is on the way) it needed
a couple of simple fixes:

	The reference to /d0 in the makefile needs to be changed to /dd .
(/dd should work on any system configured as recomended by microware.)

	The "use defsfile" line in all source modules needs to be changed
to "use /dd/defs/defsfile".  (Again, /dd is the standard place to keep
this.)

Connect has a MAJOR problem: it converts incoming /r to /r/l, and ignores
the following /l.  This does not work with systems that put null padding
between (tops20) or with ANY full-screen program.  (My z29 emulates a
z29 just fine, thankyou.)  My attempt to fix this did not work.

Oh well, I wasn't in to desperate of need for a third kermit implementation
for my system.  I realy should finish the C-kermit port enough to make it
distributable, and update it to the latest verison of c-kermit.

Bob Larson
-------