Problem:
Telix and the modem do not seem to be able to detect busy signals.
Solution:
Some modems (especially older 1200 bps units) do not have the capabil-
ity to detect busy signals. Assuming yours does, you'll still probably
have to edit the default modem Init String. The X1 that Telix uses in
the string to be compatible with all modems does not enable busy de-
tection in most modems. Try a value like X3, X4, or higher.
Solution:
Your modem is almost certainly overriding the true state of the Car-
rier Detect signal. This is the factory default on most modems, but
should be disabled. For proper operation, Telix needs to see this sig-
nal on when connected to another computer, and off when not. If your
modem has dip switches, as do most 1200 bps units and all US Robotics
external Couriers, switch number 6 usually controls this and must be
in the up position. If your modem does not seem to have any dip
switches (look carefully, sometimes the front needs to be popped off),
it is probably controlled solely by software commands, as are most
2400 bps units. Just a few examples of these are the Hayes 2400, ATI
2400etc., GVC 2400, and many others. For these modems, adding &C1 in
the modem Init String (before the final ^M (Carriage Return is a good
spot)) will configure the modem properly.
Solution:
In the Telix Configuration Menu, select the 'Screen and colors set-
tings' option, then select as the Screen Write Mode, 'BIOS calls used
for writes'. Screen updating will be slower but will not bleed
through.
Solution:
Telix knows when a connection has been reached in one of two ways:
when it receives a Connect string from your modem, or when the Carrier
Detect signal turns on (if it was off). Make sure that the Connect
string is properly defined in the Configuration Menu, or that your mo-
dem does turn on the Carrier Detect signal regardless of whether or
not there is a connection.
Solution:
Telix is set by default to use the Hayes 'AT' modem command standard.
There are modems that are not Hayes compatible however, and use other
commands to dial, hang up, and perform other tasks. Make sure that if
your modem is not Hayes compatible Telix has been properly configured
to its commands.
Solution:
The file COMMAND.COM is the DOS command interpreter. Telix must be
able to find it to use many DOS functions. The location of COMMAND.COM
is stored in an environment variable (explained in your DOS manual)
called COMSPEC. COMSPEC is set at boot-up, but if you boot of a floppy
and then change to another floppy or a hard disk, it will not point to
the right place anymore. In short, make sure that COMSPEC always
points to the location of COMMAND.COM, or that COMMAND.COM is in the
current directory.
Solution:
The communications parameters are probably wrong. Most of these sys-
tems need a setting of Even parity, 7 data bits, and 1 stop bit. This
is different from the normal standard of N81 used for most bulletin
boards.
Solution:
Unfortunately, the solution here is not simple, and requires some
knowledge of hardware. If you are not comfortable with configuring or
jumpering your hardware, please contact a qualified computer consul-
tant or service shop. The problem is likely that two devices in the
computer wish to use the same part of the computer at the same time
(called using the same interrupt). This will be the case with internal
modems on COM3 or COM4, when you have other serial devices (mice,
Sound Blaster cards, network interface cards, or other interrupt
driven devices). By default, COM1 shares an interrupt with COM3, and
COM2 shares with COM4. Only one device may use an interrupt at a time.
You should try to place your internal modem on an unused interrupt
(IRQ 5 is free in most AT or 386 class systems), and then tell Telix
under the Configuration menu that COM3 or COM4 now uses IRQ5.
Solution:
First ensure that CTS/RTS hardware flow control is enabled and that
DSR/DTR hardware flow control is disabled both in Telix under the Con-
figuration menus in the Terminal Options section and in your modem
(refer to your modem manual for instructions on setting up your modem
properly, or use the MODEMCFG.EXE program). If this fails, it may sim-
ply be hardware limitations. Sometimes such hardware limitations can
be circumvented by running Telix with the /D parameter.
Many high-speed modems, especially in a multitasking (Windows, DESQview, TopView, etc.) environment or on XT or slower AT-class ma- chines are simply too fast for the hardware, and may need some help to prevent lost characters. A UART (Universal Asynchronous Receiver- Transmitter) is a chip found on every serial card or internal modems. Most serial cards or internal modems come stock with 8250 or 16450 chips that are not rated for high speed modems. A replacement chip called the NS16550AN will likely eliminate such problems.
Solution:
ANSI.KEY is a file required for Telix operation, but due to the menu
not changing to the Telix directory, Telix cannot find this file.
Telix expects to find all of it's system files in the current
directory or in the directory pointed to by the TELIX environment
variable.
An environment variable is a setting that DOS can look at (or other programs, like Telix) to find out certain information it needs.
By placing the command:
SET TELIX=C:\TELIX
in your AUTOEXEC.BAT (modified for your own Telix path, of course) Telix will then know to look there for all of it's files if they are not in the current directory. There should be no spaces in the command as above, other than between SET and TELIX.
Solution:
Call waiting is usually disableable on outgoing calls only. Contact
your operator or phone company to determine if it can be disabled, and
if so, what the codes are in your area. In many areas, it is *70, so
we will use that as an example.
First, check your modem manual to insure that the modem is capable of dialing all the necessary characters like * or #. If not, you will have to do this by hand on your phone before each call, or ask the operator if there are alternatives (often 1170 will work, but it takes longer).
If your modem CAN dial the needed characters, or you are told of a suitable substitute, edit the dialing prefixes under Telix's Config:
ALT-O - Modem and Dialing - Options B,C,D
Insert after each "DT" (or DP if on pulse dialing) the appropriate call waiting cancel string. Note that often a comma is necessary as a pause to get a second dial tone. Once this is saved permanently to your Telix config ("W"rite setup to disk), you're set. Most often these will be:
ATDT*70,
Solution:
This is one of the great misconceptions about high speed modems, so
you're not along in wondering this. Let me try to detail why it
doesn't matter, and at the same time give you a bit of an idea what's
going on behind the scenes when you call another modem...
The link to get from your computer to the other computer looks much like this:
Telix <--> Your modem <--> Their modem <--> Their computer
DTE rate DCE rate DTE rate
38,400 14,400 57,600
As you can see, it is really a series of three links; one between
your computer and your modem, one between the two modems, and one
between their modem and their computer. What might surprise you is
that each of these three rates can be, and often are, completely
different, as above. So you know, DCE stands for Data Communications
Equipment (i.e. a modem to modem link) and DTE is Data Terminal
Equipment (i.e. terminal to modem link). You are not concerned with
the final link, the remote DTE rate. That is up to the remote site,
and does not matter at all to you. Once the data leaves your modem,
and is received by theirs, it is out of your hands.
Your modem likely has either MNP-5 or v.42bis data compression built in. For transferring non-.ZIP files, these modems can be extremely efficient in compressing the data before sending it -- sometimes as much as 4 times compression (25% of the original size).
If the modems can take 1000 characters from Telix, and then turn it into perhaps as little as 250 characters with compression, your modem still transmits at 14,400 and would need 1000 characters from the comm program to transmit a mere 250 characters. In order to keep the DCE link flowing with data non-stop, Telix has to send data to your modem at 4 times the speed the modem is talking to the other modem (in the best case, which almost never happens). Thus, the DTE (Telix to modem rate) must be higher than the DCE (modem to modem rate) by a good margin, or the modems will sit idle frequently, waiting for the comm program to supply it with enough data. Since you have no way of knowing how much the data will be compressed, or at what speeds the two modems will actually connect up at, you should ALWAYS leave the DTE rate on your end (the link between Telix and your modem as specified in the Telix configuration) locked in, or fixed, at that high rate that can accommodate the most efficient case, since that most efficient case can occur at any time.
That's why you're always advised by MODEMCFG.EXE to set the comm program's speed, as well as all dialing directory entries (no matter how fast the board actually is), to a speed higher than the 9,600 or 14,400 you really have. Typically, you'll be told to use 19,200 or 38,400 (nowadays, typically 38,400, and even some will say 57,600). But the important thing is, that speed is constant. Your DTE (program to modem rate) always stays the same, so that when that most efficient case comes along, you're ready.
Solution:
When a user is downloading, the other system is by definition
uploading to him. BOTH systems must know exactly what is happening at
every given moment, and this is especially true at the beginning of
the transfer.
First the downloader must tell the remote system (the one to be downloaded FROM) that s/he requests a download. On most systems, this is accomplished with the "D"ownload command.
The sending system will then ask the downloader to choose a protocol. You may choose any one that Telix supports, but we recommend Zmodem if it is available, and 1K-Xmodem (sometimes labeled Ymodem) if Zmodem is not available. In any case, the important thing to remember is that BOTH the sender and the receiver must be using the same protocol, and it must be agreed upon in advance.
Perhaps before choosing a protocol, you will be asked what files you wish to download. Then the system may tell you that it is ready to send the files. If you have selected Zmodem, and have Zmodem auto- downloads on in Telix (the default) you should not have to do anything more. Telix will sense the Zmodem transfer coming and go into ZModem receive mode. Sometimes this will appear as "garbage" like an up arrow, a bunch of asterisks, and numbers like 0's and 8's. This is a signal to start!
The most important thing to remember when downloading is that first you have to tell the other system what to send and how to send it, and let it get started. As soon as the other system starts, you generally have about 30 to 60 seconds to start your receive with the SAME protocol. It is crucial that both sides know that a transfer is taking place. You cannot start yours early, or the other side will never send the file.
Thus, don't hit Alt-R (or PgDn) until you are *sure* the other side is ready to send, and ready for you to tell it that you are ready to receive (ALT-R does this automatically).
Solution:
Some OEM versions of DOS 2.11 (notably, the Tandy DOS burned into the
1000 HX) are incompatible with the compiler used in these cases. This
does not apply to Telix itself.
It is highly recommended that you upgrade your DOS if possible. For users with the DOS burned into the ROM of the machine, you may boot from a system floppy of a higher DOS system to compile scripts.
Solution:
Telix expects to be able to open a new file in the subdirectory you
have defined for the Download Directory under ALT-O/Filenames and
Paths. If this subdirectory does not exist, that will cause this
message to appear:
"Unable to open file!"
This is a sure sign that you need to check your configuration in this area, and either create the defined subdirectory from the DOS prompt with the MKDIR command, or to change the configuration under ALT-O/F to reflect the location of an existing path.
Solution:
This is completely normal, and signifies a "flow" control, or a signal
to Telix or the modem to slow down or stop momentarily. It signifies
that things are in good working order.
Solution:
TELIX.PIF included with Telix is a Program Information File for
Windows that should allow best operation of Telix under Microsoft
Windows. Windows doesn't offer the best of communications handlers,
though, and for best communications results under Windows, we
recommend a Windows-based program. deltaComm is currently programming
a Windows comm program expected to be released in the first half of
1994.
Solution:
No, it is not, and there is little likelihood that we will support RPI
or software MNP in the near or distant future. RPI is an attempt by
Rockwell and the modem manufacturers to create a cheaper modem (by
about $5) by pushing off some of the hardware implementation into
software. We disagree with this for the sole reason that software
cannot be as efficient as hardware (esp. when coprocessed), and that
these functions truly belong on the hardware for efficiency and speed.
Most comm developers we know feel the same way and without our support
the manufacturers will have to go back to putting these functions on
the hardware -- where they belong.
Our recommendation is to take the modem back to the place of purchase, and don't leave until you get a REAL MNP/v.42bis modem at exactly the same price, because what you bought was not what you thought you did, and the only way the industry will stop these shenanigans is for the ones being taken advantage of to stand up for themselves and do something about it.
Solution:
Networking a comm program, or using a modem across the network as a
resource requires two things.
1) The network must be NETBIOS compliant.
2) The comm program must use the BIOS (Int-14) for comm routines. Telix normally bypasses the slower BIOS and writes directly to the comm port for speed considerations, making it incompatible with networks.
However, we have developed a version of Telix which uses the Int-14 calls, and it is now available as a separate product. please call our sales staff for more information about Telix for Networks.
Solution:
If you receive this message when running the QDHost mode then you need
to do the following:
From Telix Terminal mode (the blank screen that you are at after the opening screen goes away), press ALT-G, and type "QDCONFIG". The QDCONFIG.SLC script must exist in the same directory as QDHOST (i.e. in the script directory as defined under ALT-O/Filenames).
You will then see a menu that pops up something like this:
A: Level 1 password : pass1
B: Level 2 password : pass2
C: Remote Shell password : shell
D: Shut down host pass : shut
E: Host download directory: C:\TELIX\HSTFILES\ <------
F: Host upload directory : C:\TELIX\HSTFILES\ <------
G: Connection type : Modem
H: Modem locked at >= 9600: No
I: Exit without saving changes.
J: Exit and save changes to disk.
The indicated lines are the ones that need to be changed. You can
either Exit without saving and then do MKDIR with the above paths:
MKDIR C:\TELIX\HSTFILES
or, better, is to change options E and F above to paths that you know already exist (NEVER set these equal to your Telix subdirectory!), and then "Exit and Save Changes to Disk". For more information concerning DOS paths, please consult your DOS manual.
Solution:
Telix can, with the use of long distance codes, send much more than
this, but the modem will not likely respond to this, since anything
past 40 characters is simply ignored (and this includes your
Many long distance companies have gone to 13 character card codes to
protect you against fraud, and this is a good idea. However, it does
limit you via your modem (again, Telix is not the limitation here).
In the number you wish to dial, rather than making the number in the
directory read: "1-919-481-9399"
Save space (it's STILL tight) and make it read: "1-919-481-9399!"
The exclamation point tells Telix to append the contents of that code,
and the code can be edited to include any sequence you wish, under
Alt-D/Other/Edit LD codes.
Solution:
Telix 3.22 now makes its best attempt to read the actual connect speed
(DCE), but needs a little cooperation from the modem. Telix cannot
determine the DCE on its own -- it must rely on the modem to report
it.
Telix must accept the rate that the modem offers -- it has no way to
"validate" it. The best way to demonstrate this is to dial a number
without using the dialing directory. Type ATDT and the number, and
press Enter. Watch for the first string that displays. It will be
something like:
CONNECT 14400/ARQ/V42BIS/LAP-M
If you have a vanilla 2400:
CONNECT 2400
If the dialing directory had been used, Telix would have read the
connect rate as 14400 in the first case and 2400 in the second.
(Telix reads the connect rate as the first number to follow the
connect string on the same line as the connect string). Some modems,
however, (notably newer v.32bis modems) can be configured to return
very detailed information like this:
CARRIER 14400
PROTOCOL: LAP-M
CONNECT 57600/V32BIS/V42BIS
Now, if your connect string was "CONNECT", the value is not the 14400
you wanted, but the 57600 you didn't want. In this case, you need to
find the command in the modem manual that disables extended result
codes (often the S95 or S44 registers) and reverts to the simple
CONNECT 14400/ARQ/V42BIS string as above -- then Telix will get the
connect string you wanted.
Another option above (but not for all such modems) is to change the
connect string to match the word right before the number. Above,
you'd change the connect string to CARRIER. This one won't always
work, and it is best to disable extended result codes if you want
correct estimates.
Some modems do not return a correct response string at all, such as
the older US Robotics HST Dual Standard 1441 (v.32/ 9600) modems.
They return 9600 even if the connect was at 14400, and your estimates
in such cases will err by the difference.
The MODEM is going to be your bottleneck here. Most modems cannot take
as many characters at once as a comm program can send out. The vast
majority of modems have a 40 character command string limit, which
must include the
Problem:
Telix seems to be grossly optimistic when estimating the length of
time it will take to transfer a file. Its usually about four times
slower than Telix thinks it will be. Why is this?
Previous versions of Telix merely estimated transfers based on the
speed that Telix dialed at (the DTE), even though this could be up to
four times greater than the actual connect speed.
[Table of Contents]
Page layout and HTML programming by Spyros Spyrou