Crawly Crypt Collection 1/crawlyvol1.bin/telecomm/neocom/div_prg/turbocts/turbocts.doc

Text File | 1993-10-21 | 9KB | 199 lines

                                   TURBO CTS
                                 Version 1.32
                       Copyright (C) 1989 by Bill Penner


         First  a  statement:   USE  THIS  SOFTWARE AT YOUR OWN RISK!  THIS
    PROGRAM  MAY  BE  FREELY  DISTRIBUTED  AS  LONG  AS THE PROGRAM REMAINS
    UNMODIFIED  AND  THIS  DOC FILE REMAINS WITH THE PROGRAM.  THIS PROGRAM
    MAY  !!NOT!!  BE SOLD, HOWEVER, MAY BE INCLUDED ON CLUB DISKS WHICH ARE
    SOLD  FOR  A  SMALL  FEE.   YOU  USE THIS SOFTWARE AT YOUR OWN RISK.  I
    ASSUME  NO RESPONSIBILITY FOR ANY LOSS, DIRECTLY OR INDIRECTLY FROM USE
    OR POSSESION OF THIS PROGRAM.

         Since  the  ATARI  ST  was  released in 1985 the computer has been
    advertised  as  supporting  RS-232  Clear  to  Send and Request to Send
    (CTS/RTS)   protocol.   The  truth  is  that  the  computer  never  has
    sucessfully  supported this.  Even with the changes taking place in TOS
    1.4,  the  April version of the ROM's still contain several bugs in the
    RS232 routines which have made RTS/CTS flow control inoperative.

         Currently  most  RS-232  interfaces only require three wires to be
    connected  between  the  computer  and a peripheral (such as a modem or
    serial printer).  These lines would be the transmit data, receive data,
    and  ground.   The  transmit data line would carry the information from
    the computer to the peripheral device and receive data would bring data
    into  the  computer  from the peripheral.  Some devices operate slowly,
    such  as  printers,  and the computer can send out data faster than the
    device  can  use  it.   To  be  able  to work best with a computer, the
    external  device  normally uses some form of buffering to store several
    bytes  (characters)  of  data (sometimes up to 256K bytes or more).  If
    the  buffer was always larger than the amount of information no problem
    would occur, but most devices will allow you to send more data out than
    the  buffer  would  be  able  to  hold.   To  handle  this,  a  form of
    "handshaking"  is  required.   For  the  RS-232  interface  one  of two
    protocols  of  handshaking  are  normally  used.   Currently,  the more
    popular  one is the XON/XOFF protocol.  In this protocol, when a buffer
    is  nearly  full, the device will send out a character as would be sent
    out by pressing Control and S (Ctrl-S).  When the buffer has emptied to
    some  point, the device will send out a Ctrl-Q to tell the other device
    to  start sending again.  Communication with most BBS's will also allow
    the  user  to  stop the sending of text from the BBS by pressing Ctrl-S
    from  the  terminal  and  then  Ctrl-Q to continue the text again.  The
    other protocol is an older one in which two more wires are added to the
    RS-232 interface for RTS and CTS signals.  These operate similar to the
    XON/XOFF  protocol  except  that instead of sending some data back down
    the  line  to  tell  the  other  device to stop sending data, a line is
    changed  from  low  to  high.  The line being sent from the computer to
    tell  an  external  device  to  stop  sending is called Request to Send
    (RTS).  The line coming from an external device to the computer to tell
    the computer to start or stop sending is called Clear to Send (CTS).

         With   most   peripheral   devices   being   smart   (based  on  a
    microprocessor  or microcontroller), and the serial speeds being fairly












    slow  (110 to 9600 baud), XON/XOFF was easier to implement and required
    less   hardware.   But,  now  with  modem  speeds  increasing,  several
    companies  are implementing RTS/CTS flow control.  The US Robotics 9600
    and  14400  baud  modems  have  MNP data compression available when the
    modem  to computer RS-232 speed is set at 19200 baud, but to handle the
    19.2K  baud  speed,  the modem uses RTS/CTS flow control.  The ATARI ST
    ROM's  have pretended to support this mode, but bugs in all versions of
    TOS have prevented RTS/CTS from working, including the April version of
    TOS 1.4 ROM's.

         Upon  the  request  of Don P. (STARBASE), I began to work on a fix
    for the problem.  At first glance the problem was a simple one, only to
    trap  the  characters  being  sent to the modem and check for CTS being
    low.   I  wrote  a  couple of accessories and programs which did this.
    They  were  called  CTSFX100,  CTSFX101,  CTSFX102,  and CTSFX103.  The
    result is that they worked for some pieces of software like Flash and a
    couple  of  other  problems.   While  working  on  the  program,  I was
    optimising  routines and making the program faster.  This only resulted
    in  showing  that my method of fixing the problem was greatly in error.
    I  was  simply  grabbing  the characters as they were being sent to the
    output  buffer  and  between the operating system, my software, and the
    terminal or BBS program, the transfer speed was less then 19200 baud so
    the  buffer  would  never get filled up and my filter was working.  But
    after  optimising several portions, the speed increased to the point of
    making  my  program  useless  since the buffer would fill up the output
    buffer  and when CTS changed, my program would stop placing data in the
    buffer,  but  then  the computer would continue to send out the rest of
    the  buffer.  In the documentation I wrote with the program, I included
    my  phone  number.   The  program was distributed on F-Net and within a
    couple  of  days,  I  had  received  many  phone calls about fixing the
    problem.

         I  have  been working on the problem for a couple of weeks now and
    have  come  to  understand  that the problem has been around for a long
    time,  and  little  has  been  done  to  resolve the problem.  The data
    compression  mode of the US robotics was not able to be used and people
    were  relying on ATARI to eventully fix the ROMs.  After generating the
    CTS  Fix  programs,  alot of interest was stirred up to fix the problem
    and it appeared to be time to fix the problem, once and for all.

         The  approach was to take a close look at TOS 1.4 and to determine
    why  it  didn't  work.   I  found  only  three  minor problems with the
    software.   Two problems had to do with the software not being properly
    initialized  and  a bug in the Rsconf() routine which would not let you
    set  CTS/RTS  mode.   I  was  able to get the RTS/CTS to work PERFECTLY
    simply  by properly initializing the MFP CTS active edge register based
    on  current  CTS level, initializing a system variable which is used to
    tell  the  software  if the transmit port was enabled or disabled (also
    based  on  current  CTS level), and then setting the system variable to
    enable  CTS/RTS.  Programs would work just fine until they tried to set
    the  flow control, which would disable CTS/RTS and cause XON/XOFF to be
    enabled or disabled.

         A final program was written to replace the RS-232 routines used by












    the  system.  This was the only way to create some software which would
    work  with  any  version of ROMs.  Since the other modes of handshaking
    worked  just  fine,  I decided to write some RS-232 routines which were
    optimized  for  CTS/RTS  flow  control in hopes of also speeding up the
    RS-232 routines.  The resultant program is called TURBOCTS.PRG.

         TURBOCTS  is  a program which can be either autobooted or run when
    the  RTS/CTS flow control is needed.  Once the program has been loaded,
    the  RTS/CTS  mode is enabled and can not be disabled without rebooting
    the  system.   The Rsconf() command can be used to set the RS-232 speed
    and  play  with the UART registers, but flow control settings will have
    no  effect.  The program will also properly trap the printer operations
    when  the  printer  output  is  sent  to  the RS-232 port as set in the
    control  panel  or  the Setprt() command.  In beta testing, the program
    has  resulted  in  increasing the average Zmodem transfer speed on a US
    Robotics  9600  baud modem communicating with the ST at 19.2 Kbaud from
    approximately  850  characters  per second (CPS) to 1100 CPS for nearly
    30% improvement.

         Note  for  PC Pursuit Users:  You can continue to use the software
    when calling through telenet.  At the @ prompt, type:
                      @set ? 1:0,4:10,5:1,7:8,12:1 <ret>
    During beta testing, a 20 CPS speed increase was noted using TURBOCTS.

         I would like to thank Don P (Seattle) and  Mark A for the support,
    suggestions,  and  information.  I also appologize for distributing the
    real  lousy  version  of  CTSFX10x  which  worked  for  some and caused
    headaches  for  others.   If  you  have  a  copy  of CTSFX10x please do
    everyone  a  favor  and  erase  it  (besides, TURBOCTS works better and
    faster!).

         If  you  have  any  problems  with  the  program, please send me a
    message  on  GEnie  (BPENNER)  or  by mail at: Bill Penner, 3235 Wright
    Avenue, Bremerton, WA  98310.