Whatever software driver you use, its main purpose is to
communicate between your computer and the computer at the other end
of the wire. The two computers must speak the same language at the
same speed with the same inflection and have common ground for
knowing when to talk and when to listen. The computer yours is
talking to is probably a big mainframe. It is bigger and meaner than
yours, so you must adapt your communications settings to its wishes.
You must have the same settings on the communication programs on both
ends of the line.
For example, If you are using 9600
baud on one end, then you should NOT have the other end set up for
1200. Similarly you want to use the same bits- per-character etc. You
can't check this stuff too closely. It is especially confusing when
communicating between two different kinds of machines. This is due,
it seems to me, to using two completely different communications
programs. This can makes it hard to compare settings. Networks and
bulletin boards publish the settings to use and may have different
telephone numbers for different baud rates.
Some bulletin boards use "smart"
modems that automatically adjust to whatever speed and settings you
call in at. You can tell by the requirement to press RETURN a couple
times at log-on. That usually means the receiving modem is adjusting
to you.
3.0 Data Communications
Programs
Data comm programs are the things
that you actually use to make your Apple /// talk to other computers.
If you want to do no more than chat back and forth as a dumb
terminal, you can set up Business BASIC (or Apple II emulation) to
open your .RS232 driver (or logical communications card slot), and
you'll be directly hooked to your modem to yak all you want. Cheap.
Absolutely no one in his or her right mind does that. Al Bloom has
done it. Just to prove it can be done, mind you.
If a data comm program can't do more
than turn your Apple /// into what is called a dumb ASCII terminal,
that program is useless. You have a powerful computer in your hands,
and a data comm program must minimally recognize that power. It
should at least let you send (upload) and receive (download) text
files and offer the ability to "capture" ("log" and "record" are
synonyms) a data comm session. Other features to look for are
"terminal emulation" if the computer you want to talk to has benefits
for particular terminal types. A program that does not emulate a
specific terminal, or one that emulates a dumb ASCII terminal, is not
the same as being a dumb terminal. It may still offer file transfer
and session logging. Also look for "error free file transfer
protocols" that let you send and receive (1) critical text data that
you don't want garbled -- by a thermonuclear burst or normal
telephone line crackles or your spouse picking up an extension phone
while you're on line, or (2) any kind of non-text data -- executable
programs, graphics, spread sheets, other neat stuff that you as a
human cannot read when looking at a file in Apple Writer but would
like to transfer anyway.
1 2
3 4
5 6
7 8 9
10 11
12 13
14 