Amiga Elysian Archive/AmigaElysianArchive.iso/comm/trms20.lha/Q&A

Text File | 1993-07-05 | 16KB | 313 lines

Terminus 2.0 Q&A file
---------------------
This file duplicates the question and answer appendix of the Terminus
user manual for quick reference.


DATA IS CORRUPTED, LIKE IT'S BEING LOST WHEN RECEIVING AT ANY BAUD RATE.
------------------------------------------------------------------------
     The most likely cause of this would be due to a 3rd party serial
     device driver that does not adhere to the prescribed way of operation
     as outlined in Commodore reference material.

     To be specific, the driver is probably not handling the BeginIO()
     function correctly.  Commodore states that this function can complete
     an I/O operation synchronously if the IOF_QUICK bit was set when the
     IO request was submitted to the device.  If the request was handled
     immediately then the device is to return from BeginIO() with the
     IOF_QUICK bit still set.

     Terminus uses this ability to prevent a situation where a temporary
     deadlock can occur if two processes are accessing the same serial
     device simultaneously.  Instead of using DoIO() which is a synchronous
     function call, Terminus uses BeginIO() to read the contents of the
     serial input buffer.  This prevents the deadlock since the function is
     guaranteed to return immediately.

     The data loss problem occurs when the IOF_QUICK bit is reset when it
     shouldn't be.  If this happens Terminus will abort the I/O request,
     which effectively results in tossing away valid data.

     You can determine if this is the case, and use Terminus without fear
     of data loss by employing the use of OwnDevUnit.library which is
     included with the Terminus distribution.

     When OwnDevUnit is in effect Terminus uses the DoIO() function instead
     of BeginIO() since the library prevents more than one program from
     accessing the same device/unit simultaneously.

     Of course, any program that attempts to access the serial device
     driver must do so via OwnDevUnit.library or a deadlock will occur.  To
     free the deadlock you will need to toggle the power switch of your
     modem so that noise data is generated which will satisfy the pending
     read request that's causing the deadlock.  Once free you must exit the
     program and correct your system to prevent this from happening again.


FILE TRANSFERS ARE MUCH SLOWER THAN THOSE WITH OTHER PROGRAMS.
--------------------------------------------------------------
     There are several causes of this happening.  If one or more are
     present, you will get very slow transfer rates as their effects are
     cumulative.  Most of this discussion pertains to ZMODEM downloads,
     which is by and large, the most common type of transfer performed with
     Terminus.

     There are five options that standout above all others in terms of slow
     file transfer performance.  One, {TRANSFER}{ESC CTRL CHAR}{T} effects
     ZMODEM file transfers only, but tremendously.  DO NOT USE THIS OPTION
     UNLESS YOU ABSOLUTELY NEED TO!!!

     The {GENERAL}{FILE SAVER}{V} option effects any type of download.
     What this causes Terminus to do is to close and then reopen the file
     each time a disk write operation is performed.  By doing this, the
     file is guaranteed to contain some data if a system crash occurs
     during a file download.  What this also means is that the file
     transfer is going to be slowed down significantly since there is
     additional overhead needed to reopen and reposition the file pointer
     each time an access occurs.  You have to determine if the throughput
     penalty this option imposes is less of a factor then possibly losing a
     file.

     The {GENERAL}{SLOW DISK I/O}{K} and {GENERAL}{512 BYTE DISK I/O}{5}
     options should only be used if the file transfers gets errors whenever
     a write to disk is performed.  Otherwise they should be OFF or a
     slower transfer will result.

     Although not a severe, having XON/XOFF handshake active when starting
     a ZMODEM file transfer will also slow it down somewhat.  The confusion
     with XON/XOFF arises from the fact that Terminus does not deactivate
     it when a ZMODEM transfer is initiated like most of the other Amiga
     communications programs that are out there.  This is not correct
     though because, unlike XMODEM technology protocols, ZMODEM is a full
     streaming protocol designed for packet switched networks that may
     overflow portions of a busy network without XON/XOFF handshake active
     to regulate data flow.

     The {GENERAL}{DISK SPACE CHECK}{D} option will slow down the beginning
     of a file transfer due to Terminus performing a free space check
     before proceeding with the transfer.

     The {GENERAL}{LOGFILE ACTIVE}{L} option will also slow down batch
     transfers since a write to the logfile performed at the completion of
     each file transferred.


ERRORS OCCUR WHEN DOWNLOADING WITH AN ERROR CORRECTED MODEM.
------------------------------------------------------------
     Since an error correcting modem is supposed to give you an error free
     connection, any errors can only mean one thing; data is being lost
     between the modem and computer.  The cause of this is due to the cpu
     getting locked-out long enough for the most recently received data
     byte to be overwritten by the next incoming byte.  Unfortunately, the
     internal serial port does not buffer these bytes like some of the more
     advanced UARTS (Universal Asynchronous Receive Transmit device)
     available these days.  Thus, the cpu has a fairly critical "window of
     opportunity" in order to successfully fetch data as it is received.

     The first thing to determine is when the error is occurring.
     Basically, there are two things to look for, random error loss or
     errors that occur when a specific event happens in your system.

     If the error occurs only when something else happens there is a
     conflict between that event and Terminus receiving data.  The most
     noted occurrence is when data is written to disk.  If this is the case
     you will want to try both the {GENERAL}{512 BYTE DISK I/O}{5} and
     {GENERAL}{SLOW DISK I/O}{K} options to see if one or both cure the
     problem.

     If the errors are random your system might simply be too loaded down
     with the processing burden of other tasks running or by using an 8 or
     16 color screen and/or severe overscan.

     You will need to inventory the task priorities of all resident
     programs to see if one is running at too high a priority or if one is
     always running, sometimes called a "cpu hog".  The program XOper is
     quite effective in seeing if a task is of this nature.

     If that is not the cause then you will need to trim back the screen
     colors and/or overscan to give the cpu more cycles for accessing the
     chip ram bus.


WHERE'S THE YMODEM-batch PROTOCOL.
----------------------------------
     YMODEM *is* a batch protocol, thus calling it "batch" would be
     redundant.  There are really only two variations of TRUE YMODEM(tm).
     The first is YMODEM and the second is the YMODEM-g protocol for use
     with reliable data connections, such as an error correcting modem.

     The trouble lies in the fact that some telecommunications software
     authors took it upon themselves to implement only some of the features
     of YMODEM and still call it YMODEM.  The most common variant being
     what is now properly called XMODEM-1k.  Later, after realizing the
     errors of their ways, they added YMODEM-batch, but called it that to
     save face with their users.

     If the protocol that calls itself YMODEM does not send filename, size
     and date information (Terminus will tell you this by "stepping down"
     to XMODEM), it is really XMODEM-1k.

     There are some other versions that will send this information, but
     will not support batch operation.  You can still use Terminus' YMODEM
     in these instances too.

     Finally, there are some very old versions of YMODEM that you may run
     into that cannot handle the 1024 byte block that is in widespread use
     today.  This is the reason for the YMODEM and YMODEM-1k options in
     {TRANSFER}{PROTOCOL}{P}.  In almost all cases, leave the 1k version
     selected.  Only use the other for instances where the receiver must
     have 128 byte blocks sent.

     Terminus has enough intelligence built-in to handle almost any of the
     mutant versions of this protocol that you may run into.  If you do run
     into an especially uncommon strain of this protocol, please report it
     to the BBS so that it can be modified to deal with it in a future
     release.


WHY DOES TERMINUS SOMETIMES TAKE SO LONG TO ABORT A FILE TRANSFER?
------------------------------------------------------------------
     Terminus tries very hard to prevent leftover data from an aborted file
     transfer from splattering all over your display.  If the wait is
     extraordinarily long you can click on {STATS}{ABORT}{A} a few times to
     cause a hard abort to occur regardless of what data is left in the
     pipe.

     Although ZMODEM transfers will generally abort faster, the XMODEM
     technology protocols can take a good deal of time to abort.  The main
     reason for this is that the receiver can only detect an abort sequence
     at the start of a block.  It cannot determine this while receiving the
     data portion of the block.  So, you may have to wait for as many as
     1,028 bytes to be sent or received before it will begin the abort
     sequence.


ALL FILE TRANSFERS IMMEDIATELY ABORT WITH "Carrier not detected..."
-------------------------------------------------------------------
     Terminus will act this way if it does not see a carrier detect signal
     (DCD) when it should be.  The two most likely causes for this
     occurring would be a defective serial cable or modem.  Check the modem
     manual to verify that your modem does have a functioning DCD signal
     and that the serial cable passes this signal.  You will need to
     activate {MODEM}{IGNORE CARRIER DETECT}{R} if you cannot get the modem
     to control DCD.


WHY DO DOWNLOADS SOMETIMES TAKE LONGER THAN UPLOADS TO THE SAME SYSTEM?
-----------------------------------------------------------------------
     This is not a problem.  It is simply that any download, regardless of
     the protocol being used, is entirely dependent on the speed of the
     sending system.  You can only receive a file as fast as it is being
     sent to you.


TERMINUS WILL NOT ENABLE CTS HANDSHAKE.
---------------------------------------
     In order to use CTS/RTS handshake, your modem must have the DSR and
     CTS signals active.  Check your manual so that you can set the modem
     to always have DSR active and have CTS remain active (but not set high
     permanently) when offline.


THE ONLINE TIMER IS ALWAYS COUNTING, EVEN WHEN OFFLINE.

                         -and-

THE DIALER REFUSES TO DIAL, REPORTS: "Exiting, carrier present."
----------------------------------------------------------------
     These two problems are due to the carrier detect signal (DCD) always
     being active.  Check the manual to the modem for the proper command
     and/or hardware switch in order to set the modem so that this signal
     is only active when a carrier signal is present.

     If the modem (or cable) doesn't allow you to correct this problem, you
     will have to disable the carrier detect logic in Terminus by setting
     {MODEM}{IGNORE CARRIER DETECT}{R}.


THE DIALER ALWAYS REMOVES AN ENTRY AFTER THREE DIAL ATTEMPTS.
-------------------------------------------------------------
     You modem must be able to RELIABLY detect a busy signal or it will
     return a NO CARRIER response.  If three of these responses are
     received for a selected entry the dialer will deselect it.

     If your modem does not detect busy signals, also known as "blind
     dialing", or it is not reliably detecting them, you must activate
     {MODEM}{IGNORE NO CARRIER}{G} to deactivate this feature of the
     dialer.


THE DIALER DOES NOT SET THE BAUD RATE TO THE RIGHT RATE.
--------------------------------------------------------
     If your modem is capable of dialing at one baud rate, but changing it
     after sending the CONNECT response to the connected rate you will need
     to activate {MODEM}{DIALER AUTOBAUD}{B}.  Most error correcting modems
     need to operate at a fixed baud rate between the computer and modem,
     so the modem should not allow a baud rate change to occur and the
     {MODEM}{DIALER AUTOBAUD}{B} option should be disabled as well.

     Another possibility is that your modem is not returning a recognizable
     or correct extended CONNECT response so that Terminus can determine
     which baud rate to use when auto-bauding. active while your modem is
     not set (or capable) of returning extended result codes for the
     "CONNECT" message.


THE MODEM SOMETIMES "MISSES" THE DIAL COMMAND SENT BY THE DIALER.
-----------------------------------------------------------------
     Some modems have trouble decoding an "AT" command sequence when the
     characters are sent too fast.  Set the {MODEM}{PACING}{P} option to a
     value that allows your modem to reliably receive the dial command.


MY MACROS ARE SENDING INCORRECT DATA WHEN USING THE IBM DOORWAY MODE.
---------------------------------------------------------------------
     This is normal.  Function key macros are disabled during Doorway mode
     due to Terminus emulating the hexadecimal scan key codes that are sent
     whenever a key is pressed while this mode is active.  For this reason
     you cannot have macros when using this mode.


TERMINUS SOMETIMES REPORTS THAT IT COULDN'T OPEN A WINDOW.
----------------------------------------------------------
     You're running Terminus on a system that has little free memory.  Use
     a screen with less colors.


THE DIALER IS EXITING AFTER A "RING" OR 3 "NO DIALTONE" MESSAGES.
-----------------------------------------------------------------
     This is normal operation for the dialer when using a modem on a
     residential voice line.  But, if you're running a BBS system or have a
     separate data/fax line, you might have a collision with an incoming
     call while the dialer is attempted to dial out.  In order to eliminate
     this there are a few things that you will have to do.

     The {MODEM}{RING}{I} response will have to be deleted in order to
     disable that feature.  The "NO DIALTONE" feature of the dialer can't
     really be disabled, but a work around has been developed that will
     "fool" the dialer.

     Next, delete the string in {MODEM}{NO DIALTONE}{L}.  Now, change
     {MODEM}{NO CARRIER}{A} to "NO DIALTONE".  Lastly, set {MODEM}{IGNORE
     NO CARRIER}{R} option.

     What this accomplishes is that the dialer will treat the "NO DIALTONE"
     response as if the modem was a dumb Hayes that was using blind
     dialing.  Although an intelligent modem that has a call progression
     feature can still return a "NO CARRIER" response if the modem times
     out without the remote system picking up or if it fails to detect a
     "BUSY" signal, {MODEM}{IGNORE NO CARRIER}{I} will prevent the dialer
     from removing the phone entry from the selected list.


TERMINUS HAS TROUBLE KEEPING UP WITH 16 COLOR ANSI.
---------------------------------------------------
     If you're using an Amiga that only has "pseudo-fast" ram instead of
     "true" fast ram, the cpu is going to be locked-out during display and
     scroll functions.  An 8 color screen should help eliminate the slow
     operation that occurs on systems with no true fast ram.

     True fast ram is different than ram expansion that resides at the
     hexadecimal $C00000 address, such as the 512k A501 expansion for the
     A500.