Amiga Elysian Archive/AmigaElysianArchive.iso/comm/jrc102.lzh/Q&A.doc

Text File | 1991-04-03 | 18KB | 385 lines

JR-Comm 1.02 - FREQUENTLY ASKED QUESTIONS
-----------------------------------------

   This text was extracted from chapter 19 of the JR-Comm 1.02 users manual.



- MY FILE TRANSFERS ARE MUCH SLOWER THAN THOSE WITH OTHER PROGRAMS. WHY?

     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
     JR-Comm.

          There are three options that standout above all others in terms
     of slow file transfer performance.  One, the "Escape ctrl chars"
     option in the FILE TRANSFER PARAMETERS requester effects ZMODEM file
     transfers only, but tremendously.  DO NOT USE THIS OPTION UNLESS YOU
     ABSOLUETLY NEED TO!!!

          The second option, "File saver" in the GENERAL PARAMETERS
     requester effects any type of download.  What this causes JR-Comm to
     do is to close and then reopen the file each time a disk write
     operation is performed.  By doing this, the file is gauranteed 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 last reason for slower transfers has to do with high-speed
     ZMODEM and YMODEM-g uploads only.  If the "Overdrive" feature is not
     enabled, JR-Comm will not do a burst mode send of data out the serial
     port.  Although it can speed up throughput by a good margin, it has
     the drawback of increasing error recovery time.  It is not recommended
     for noisy connections or for baud rates below 9600bps.

          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 JR-Comm 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 "Disk check" option will slow down the beginning of a file
     transfer due to JR-Comm performing a free space check before
     proceeding with the transfer.

          The "Logfile active" option will also slow down batch transfers
     since a write to the logfile performed at the completion of each file
     transfered.




- I'M GETTING DOWNLOAD ERRORS AT OR ABOVE 9600BPS WITH AN MNP MODEM.

     Since an MNP modem is an error correcting device that gives you an
     error free connection, any errors at high baud rates can only mean one
     thing; data 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.

          Unlike the IBM style computer, the Amiga does not have the
     ability to simply pop in an alternate (and more powerful) UART that
     would eliminate this problem.  Do not despair however.  There are a
     few simple things that you can check to determine the cause of these
     bytes getting lost.

          Using an 8 or 16 color screen can have a direct effect on these
     problems, try dropping down to a Workbench or 2 color screen to see if
     this eliminates the errors.

          Next, are you running JR-Comm or any other task with an
     excessively high priority?  Do you have any device drivers (hard disk
     drivers are a common one) that run at an unreasonably high priority?
     Is the hard disk controller you're using a programmed I/O version?  If
     it is, contact the manufacturer for help.  Use the diagnostic key
     sequence in JR-Comm to create a ram:jrc.diag file and examine its
     contents or contact the support BBS for additional help.

          If the task priority in the GENERAL PARAMETERS requester hasn't
     been modified, you may want to bump it up one or two at a time and see
     if this cures the problem.

          Having more than two floppy drives connected (one internal and
     one external) will definitely give you problems with the internal
     serial port.  This is due to AmigaDOS checking for a changed disk once
     every second or so for each drive.  The same holds true for certain
     hard disk controller devices that have more than two or three
     partitions active.  Believe it or not, AmigaDOS also checks each
     partition once every second to see if it too has been changed!

          Finally, check if you are running any cpu intensive tasks in the
     background while you're downloading.

          Although the Amiga is a multitasking machine, the resources
     available are finite, especially when you're running JR-Comm (or any
     communications program) at 9600bps or 19.2kbps (anything higher than
     19.2kbps is definitely not recommended with the internal port).
     Remember that the internal port can't buffer the data it receives, so
     don't bog down the cpu or it won't be able to respond to the data fast
     enough to prevent it from being overwritten.

          If you still continue to receive errors contact the support BBS
     for any additional help that may have been discovered since the
     printing of this manual.

          As an aside, you may wish to look into a third party serial board
     for the A2000 and A3000 series of Amiga computers.  These boards can
     greatly reduce the problems you may be having, especially if you can't
     completely eliminate them.



- WHY DOESN'T JR-COMM HAVE A YMODEM-batch PROTOCOL?

     It does.  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 MNP 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 (JR-Comm 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 JR-Comm's
     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
     the FILE TRANSFER PARAMETERS requester.  In almost all cases, leave
     the 1k version selected.  Only use the other for instances where the
     receiver must have 128 byte blocks sent.

          JR-Comm 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 JR-COMM SOMETIMES TAKE SO LONG TO ABORT A FILE TRANSFER?

     JR-Comm 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 the close window gadget 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.  The "Overdrive" option will aggravate this delay
     substantially for low baud rates.



- ALL FILE TRANSFERS IMMEDIATELY ABORT WITH "Carrier not detected..."

     This is related to the previous problem except that the carrier detect
     signal (DCD) is never active, even 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.



- ATREDES BBS ZMODEM DOWNLOADS SOMETIMES HAVE "WEIRD" FILE SIZES.

     Some versions of the Atredes BBS system had a bug that gave incorrect
     information for this protocol.  The file will be received correctly
     though.  Inform the sysop of that system to upgrade to a newer
     version.



- FILE TRANSFERS WITH A BBS-PC! SYSTEM <INSERT YOUR PROBLEM HERE>.

     Unfortunately, there is no easy way to determine which version of
     BBS-PC! you are really dealing with.  Although it may "say" that it is
     version 4.20 (or whatever), it could be any one of a number of
     releases due to the publisher of this product not bumping the version
     number as they fix things.  The only certain way is to know the file
     size of the executable for this program and, as a caller to the
     system, you cannot find this out.

          Contact the sysop of the system in question to determine what is
     the best way to correct the problems you're experiencing with this
     BBS.



 - 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.



- JR-COMM 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 JR-Comm
     by setting the button gadget "Ignore carrier detect" which is located
     in the MODEM PARAMETERS requester.



- 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 the
     "Ignore No Carrier" option in the MODEM PARAMETERS requester to
     deactivate this feature of the dialer.



- THE DIALER ALWAYS SETS THE BAUD RATE TO SOMETHING OTHER THAN THE
   SELECTED OR CONNECTED RATE, WHY?

     There are two reasons why this would happen.  The most common one
     would be have the "Auto-baud" option in the MODEM PARAMETERS requester
     active while your modem is not set (or capable) of returning extended
     result codes for the "CONNECT" message.  The second reason is if your
     modem does not adhere to the Hayes standard for these extended result
     codes.  Please refer to section 2.8.5 for more details about the auto-
     baud feature.



- 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 "Dial pacing" parameter in the
     MODEM PARAMETERS requester to a value that allows your modem to
     reliably receive the dial command.  This value represents tenths of a
     second delay between each character in the command string.



- 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 JR-Comm 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.



- JR-COMM SOMETIMES REPORTS THAT IT COULDN'T OPEN A WINDOW.

     You're running JR-Comm on a system that has little free memory.  Use a
     screen with less colors.



- I'M USING JR-COMM TO DIAL OUT ON A BBS LINE.  HOW DO I PREVENT IT FROM
   EXITING AFTER RECEIVING A "RING" OR 3 "NO DIALTONE" MESSAGES?

     The "RING" message in the MODEM PARAMETERS REQUESTER 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.

          What you need to do is first delete the "NO DIALTONE" string.
     Now, change the "NO CARRIER" to "NO DIALTONE".  Lastly, set the
     "Ignore no carrier" option in the MODEM PARAMETERS requester.

          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, the "Ignore no carrier" feature will prevent
     the dialer from removing the phone entry from the selected list.



- WHY DO 4 DOTS APPEAR IN THE STATUS LINE WHEN USING VT-10x?

     These dots represent the four LED indicators on a real VT-10x
     terminal.  They are software controlled by the remote system during
     operation.  An '*' character is used to indicate that the LED is "on".



- JR-COMM HAS TROUBLE KEEPING UP WITH 16 COLOR ANSI.  WHY?

     If you're using an Amiga that only has chip ram or "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.

          A 16 color screen also is limited to 2400bps operation.  Somewhat
     less for PAL screens, even if fast ram is installed.  If you're using
     a high-speed modem, you should drop down to at least an 8 color
     screen, or risk serial data loss.  See the next problem discussion
     which is closely related to this one.



- WHY ARE THE COLORS ORDERED DIFFERENTLY THEN A TRUE MS-DOS MACHINE?

     JR-Comm uses a translation table to convert the ANSI sequences that
     change color to the correct hue.  This was done to make the various
     requesters and default white on black text look "right" on the Amiga.
     If the "correct" color ordering was used, the default text would have
     been red for both the terminal and the string gadgets in the
     requesters.

          The color scheme was further designed to allow the gadgets and
     their labels to be readable from a 2 color to 16 color screen.



- BUT, DID IT HAVE TO EMULATE THE "FLICKER" OF THE OLD CGA MONITORS TOO?

     The slight flicker you see as colored text scrolls up the screen is a
     result of the blitter scrolling each of the four component bitplanes
     that make up a 16 color screen one at a time.  Since the total scroll
     operation takes longer than the time to refresh and paint the bitplane
     data once or twice, you see a small flicker.  Some of the colors are
     more prone to this than others.  The color scheme of the palette was
     also modified to take this into account by separating some of the more
     offending colors to minimize this effect.  Unfortunately, this wasn't
     completely successful.

          A future version of JR-Comm may have a better solution to this.
     Only authorized system calls and methods were used to prevent problems
     from occurring with the new version(s) of Kickstart and Workbench that
     were still under development when JR-Comm 1.02 was released.