C-Kermit Vers. 5A OS-9 portation:
---------------------------------

1)  Setting the speed of the communications line:
    With OS-9 there are two different ways of setting the speed line which
    need a little discussion.
    a) Assumption: you have a properly implemented driver for your teminal
       lines.
       This means that with any SS_Open and SS_Opt call to the driver
       the driver will check whether the speed has changed and will
       re-program the hardware accordingly. In this case everything is fine
       and kermit will only have to do an _ss_opt call and the speed will be
       changed. This is what tmode does.
    b) Assumption (more likely): your driver does not check the speed change.
       You could try to change the speed with the xmode command, close the
       path currently open on it and reopen it again (xmode only modifies the
       device descriptor in memory; NOT any currently existing path
       descriptors). But this won't help you much if your line was iniz'ed
       before, because the driver's init routine will NOT be called again
       and since the poorly implemented driver does not check the speed with
       an SS_Open call the actual speed will not be changed. The only way is
       to have the device not iniz'ed. But this again might cause some
       problems: again, a poorly implemented driver does not wait till
       output buffer (the drivers!, not to be mixed up with the buffer
       e.g. setbuf() works on) is empty, before the termination routine runs.
       So, when the device was not iniz'ed and therefore the termination
       routine is called everytime the last existing open path closes,
       characters might get lost (e.g. a list file.name >/t7 on a previously
       not iniz'ed device often will not show all characters on /t3 if the
       drivers termination routine does not wait). The best solution is to
       deiniz the device till there are no interrupts running anymore
       (with OS-9 V 2.3 and later use irqs) then use xmode and iniz the
       device again.
    How to find out: let kermit change the speed (using _ss_opt) and see
    wether the change worked. Otherwise you the method mentioned above.
    I included the xmode version in kermit (which only works on non-iniz'ed
    line, but I really discourage you of using it. You can include the
    -dXMODE option in the makefile to have this method been used.
    Another problem could arise on a system with an installed memory
    protection unit: if the device desriptor does not have public write
    access, xmode cannot change the device descriptor unless you are
    priviledged. In that case changing the speed with xmode from within
    kermit will not work. The _ss_opt (tmode) method works also with an
    installed memory protection unit, because it acts only on the path
    descriptor (not on the device descriptor) which is owned by the current
    user.
    The best solution is: already have or get or write a decent driver.
2)  Setting raw mode on line:
    Again a remark: If you change XON/XOFF to 0 with _ss_opt, the driver
    should wait till the output buffer is empty, because if there is pending
    output the driver might receive an XOFF which will result in an output
    halt. Next you change the mode with XON set to 0, and the driver will
    never start output again, because there is no XON character anymore.
    This might happen when you type the connect command. In this case kermit
    says something like: Connection thru blabla
    and the puts the terminal line in raw mode. But your terminal might have
    sent an XOFF (and shortly later an XON again), but the XON might be lost.
    The only way to circumvent this (unfortunately OS-9 currently offers
    no way to find out whether the drivers output buffer is empty or not;
    there are many situations when one would like to know that) is to wait.
    If this happens to you edit ck9con.c and wait after the message.
3)  Kermit now does an open with initial file size. This prevents long
    transmission to break down only at the end because either the file has
    become too fragmented or no space on the disk anymore.
4)  You can make the module (and its data requirements) a lot smaller by
    adding many compiler switches to the makefile like -dNODEBUG.
    For the possible switches see the makefile.
5)  Sending a break on a line is again a matter of the driver. There is a
    setstat call SS_Break, but again many carelessly implemented driver do
    not support the call. If there is no support, kermit will try to switch
    to a lower speed then, but again this may not work (see above).
    Things would be much easier, if drivers were written more carefully.