____ ___ ___ ___ ___ ___ ___ ____ ___ ___ ___  / /__//_ /__ / //_ //__ / //_ / / / //_ //__//_   / / //__ ___//__//__/___//__// / /_/_// // \/__  ------------------------------------------------------------------------------ - FOR ABO'S CONTACT US AT: BP:28 1170 WATERMAEL-BOITSFORT 1 BELGIUM!!... ------------------------------------------------------------------------------ - DON'T SEND ANY DISKS - ------------------------------------------------------------------------------  THE LEGENDARY >> SUBSOFTWARE << IN 87/88/89/90/91!!...  ------------------------------------------------------ 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 . 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.