I'm going to try to describe how to start using a modem setup with the Atari ST
series, so a beginner can get started and gain access to the Internet and/or
BBSes (Bulletin Board Systems). I've never used a "direct connection" (PPP.
SLIP etc..) so I don't know much about setting up such a system (maybe someone
else can write an "intro" article about that). All I know about is a "dial up"
connection, where you use your ST as a terminal. I'm no "expert" in this, just
a plain Atari ST user who's trying to share his experiences with fellow ST
owners/users. I'm going to try to explain this as simply and as thoroughly as
possible. Here goes.....


THE SETUP
---------
First of all you'll need a modem. These days 28800 baud is becoming the
"standard", but normal STs can't use them unless they're modified (there are
circuits around to do this, some DIY, others commercial ones- don't ask
me which ones are best). Anyway, 9600 baud is rated as the "minimum"
requirement, though 14400 baud is the most usual type. You can of course do
with a slower modem (like 2400 baud), but in the long run it'll be more
expensive than buying a faster modem since the longer time it takes to transfer
data will obviously run your phone bill higher.
Buying a second hand modem is definitely a good idea, as many people are
getting rid of their slower modems and going for 28800 baud instead.
Just remember to get hold of an *external* modem, since many of them are made
specifically for PCs, which are circuit boards that go inside the machine.
Obviously you can't use these with an ST.

Secondly you'll have to have a communications program. there are several around
for this, though I've only tried two. I'm currently using the excellent German
shareware "Connect" which has lots of great features, but is a bit hard for a
beginner to start off with. I particularly found the setup to be confusing.
But with a lot of trial and error (and patience) I got the hang of it.
Before I started using "Connect" and registered it (it's definitely worth the
fee, and you also get a printed manual) I used "Storm", also a shareware
program.
"Storm" is a lot easier to use, but has more limitations as well, but is great
for a beginner. I didn't get the Zmodem transfer to work though (even with the
"fix" update), maybe someone else has, and I did it wrong...
I'll get back to "Zmodem".
There are several other comms programs around, both shareware and commercial
ones, but these are the ones I've tried.

Oh, and ST is definitely useful to have as well ;-)
(and a phone line).....


DIALLING/CONNECTING/LOGGING IN
------------------------------
So, you've got your ST set up and running a comms program with your modem
switched on and connected to the phone line.... you're ready to go on-line!
In just about every comms program you have a "phone list" which is stored on
your disk/hard disk. This is where you type in the phone numbers for the BBSes
or Internet access points, so you don't have to manually dial them.
In "Connect" you simply double click the name of the place you want to dial
(yes, you give names to them, so you don't have to remember where the numbers
correspond to), or drag the name to the phone icon.
Depending on your setup, the program will probably initialize (reset) the modem
and you'll hear a "click" from the modem's relay followed by the dial tone.
Then the numbers will be dialled (usually tone dialling).

The rest normally goes automatically- when the modem gets a "connection" with
the other computer's modem things start happening. You get a login request
where you have to type in your password/username, or if you don't need that
you're faced with a menu of some sort.
(In some programs, like "Connect" you can write a "login script" where the
computer automatically logs you in- a great time-saver).

What happens from here is pretty individual from connection to connection.
Some connections might run Unix (like Internet connections) while many BBSes
run a menu system where you're just asked to type y/n, number or letter
choices.
You might think that if the other computer runs Unix you'll have to have Unix
on your ST. Not so... the ST merely acts as a "terminal"- all you do is send
commands from your ST's keyboard that control what happens at the remote
computer, and you get feedback on your ST's screen. Apart from that, all the ST
is doing is running the comms (or termial if you may) program, and if you get a
program or other data from your remote computer you'll be using your ST's hard
disk/RAM disk or disk drive to save that data.
You'll have to learn the most basic Unix commands to get round on your remote
computer though. You Internet provider will probably send you a brief manual
for this.
This might get a little confusing, but just think of the Internet provider's
computer as a machine that you're "remote controlling" via your ST, just like
you've got a very long cable from that machine to your ST's keyboard ;-)
What you ask the Unix computer to do, whether it be retrieving software from
FTP sites, copying/deleting/saving/editing files, will all be going on on that
computer, *not* your ST. When you log off, your ST won't contain any of the
software you just retrieved. So what's the use you might say? You wanted to do
this so you could get hold of software, send/get email and so on...


FILE TRANSFERS (ZMODEM)
-----------------------
Well, this is where file transferring comes in.
You have to transfer files from the Unix machine back to your ST, and sometimes
you might even want to send files from your ST to the Unix machine, so you can
upload them to an FTP site, or send them to a friend somewhere in the world.
"Zmodem" is the most used method here. Obviously your comms program has to
support it.
In a Unix system you simply type "rz" (without the quotes) which stands for
"recieve Zmodem". Think of the Unix machine recieving (after all, you're typing
the command in Unix).
The file selector on your ST will pop up, where you double click the file to be
uploaded (sent) to the Unix machine from your ST. You'll normally see a
representation of the file transfer, either graphically and/or in numbers of
bytes. When the transfer is over the Zmodem window disappears and you can check
if your file is there. Bingo!

Most of the time though you'll want to *get* files, say from FTP sites.
After having gotten the files the usual way via FTP you will have to transfer
them from the Unix machine to the ST. Simply type "sz" (again without the
quotes) in Unix (you guessed it... "send Zmodem") followed by the filename.
I.e "sz cpx.zip". You can also send multiple files with one command;
"sz cpx.zip gembnch.lzh diskinfo.txt test.arc slectric.zoo".
You'll once again get the file transfer window where you'll see the progress.
Be sure to have enough space on your disk, or else the time will be wasted
where you might almost have the whole file, but as the disk is filled up the
process will be cancelled.
File transfer is where you really get to see the difference in speed with a
fast or slow modem, and this is where you can really save a lot of money.
If all you do is read/write email online a slower modem will do (if you're
patient enough for the text to scroll by). I still recommend a faster modem
though- even in reading text a lot of time (and phone cost) can be saved.

You might wonder why I only talk about Unix systems here, well the answer is
simple- when using a BBS you normally get to simply answer yes/no or type in
your choice to a question, while in Unix you have to issue commands.
A BBS is literally self-explanetory.

Apart from the "Zmodem" which is normally used for *binary* data (i.e. all
sorts of data apart from plain ASCII text) there is also "ASCII upload".
By the way, you can use Zmodem for text transfers as well, but I'll try to
explain where ASCII upload comes in handy...... over to the next chapter.
Still with me?


ASCII UPLOADING/WRITING "OFFLINE"
---------------------------------
Normally, writing email is pretty time consuming (it is for me anyway). It
would be pretty expensive if you should write long letters and many of them
while being "online"- not something to look forward to when you get your next
phone bill. This is when doing things "offline" comes in. Being offline simply
means that you're not connected, your phone line's not in use by the computer.
This is when you have all the time in the world to write your electronic love
letters ;-)
You write each letter as one text file, and when connected the next time you
simply enter the mail program (I use "Emacs" in Unix) and start off as you
would when writing or replying a mail on line. Enter the email address and the
subject and go to the first line where you're about to start writing.
Now, here comes the magic! In your comms program you select "ASCII upload". You
will be faced with the file selector again, where you double click the letter
you've written to that person (be sure to get the letter that corresponds to
the person you've just written the email address to). It would be pretty
embarassing for aunt Edna to get you love letter, or even worse, if you
uploaded it and sent it to a news-group!! ;-)

You'll see the text fly by as if you were the world's quickest typist! When
you've reached the end you're ready to send it, as you would when being online.
This sure is a timesaver! (and moneysaver!!).

As for the "header" of the mail, where you enter the address and subject. Well,
I did a little experiment- I copied the empty header from the Unix mail program
that I use, and saved it as a file on my Atari.
When offline I simply pasted this header on top of the letter, entered the
address and subject, followed by the text. I even included a "signature" at the
end that I made on my Atari, and tried to send it- it worked!!!
(PS. I found out that the header included some control characters, so it won't
work if you simply re-type the header, you have to save an empty header and
send it via Zmodem)

This saves the confusion of sending the right letter to the right address, and
fumbling around typing those (often complicated) email addresses online.
You just have to remember to erase the existing empty header in the mailer
program when you're about to ASCII-upload so that you don't get two headers.


THE CAPTURE BUFFER
------------------
So, how are you going to reply email when you can't see what your mail? Are you
supposed to "sz" (send Zmodem) each email to your ST? You could do that, but
it'll take time. This is where the so-called "Capture buffer" comes in handy.
This is a feature that allows you to save every single character going by your
screen to make a sort of "log book". That way, when you're offline again you
can read that capture file and all the mails you've been reading online are
there!
The way I do it is to quickly read my email online, just to get them into my
capture buffer, then reply to them offline, using the cut/paste feature in my
text-editor.

A text editor is a simple word-processor which is used for making "readme"
files, programming, or anything that involves ASCII text. There are no features
that involve underlined, italic, bold text as these features can't be saved in
ASCII text files, and can't be tranferred over email either. A text editor has
basically all the features of a word processor that involves ASCII text. You
can't import graphics or do bold, italic, underlined text as none of this can
be done in ASCII). A text editor is usually a much smaller program than a word
processor and therefore quicker to load and takes up less space. It's
particularly good for editing text.
I recommend a GEM text editor that can work with several windows, like "7up"
Several windows comes in handy when cutting/pasting between the original
email and the reply.

You can often switch on/off the capture buffer as you wish, so that you don't
get all the text from the email you've uploaded (you're not interested in
reading all of that and waste disk space). And if you wish, it won't contain the
control characters and the like, just pure ASCII text. It also won't
contain all the "rubbish" characters that you see from binary files when "sz"
and "rz"ing files.

As the capture buffer is something that happens locally (on your ST) you don't
have to worry about transferring it from the Unix system, or converting it from
Unix text to Atari text (explained below).
One drawback with the capture buffer is that some of the text might come out
garbled or messed up. I think this is due to the scrolling. I'm not quite sure
why.
If I get really long emails I generally transfer them via Zmodem to get their
complete and correct contents.
Obviously you'll have to save that single email on your Unix system, so you
won't be tranferring your whole bunch of emails! (in my mailer; "Emacs" a file
called "RMAIL" is generated where new mails are added each time), but if I wish
I can extract and save a copy of each single email. Refer to your manual for
the mailer you're using.


UNIX/ATARI ST TEXT DIFFERENCE
-----------------------------
Something which you will have probably encounter pretty soon is the difference
between text files written in Unix and text files written in the Atari domain.
At the end of each line a couple of "invisible" characters are included- when
writing ASCII text on your ST there will be a "Carriage Return" (CR) and
a "Line-Feed (LF) at the end of each line.
In Unix there's simply just a "Line Feed" (LF).

In practice, this means that a Unix text file read on the ST will look like
a flow of random characters following each other vertically or spread all over
the screen.
If you double click on such a text file while in the desktop you can read it by
pressing the <RETURN> key for one and one line instead of the space bar (for
"next page"). This will manually put a "Carriage Return" after each line.
When loading the text file into a text editor/word processor you don't have to
worry about this. It'll look just like any Atari text file. If you want to make
it "normal" (readable in a normal way from the desktop) simply re-save the file
in the text editor/word-processor.

There are also programs made specifically for this purpose. the one that I've
found most reliable is a .TTP program called "UNIX2ST.TTP", where you simply
type the name of the file you want converted. I'm not quite sure about the
syntax for using another drive or several files. I've simply copied it to the
directory where the text files are, and typed the whole file name in.
be sure to check the file(s) afterwards to see if they really have been
converted.
It's not such a user-friendly program but does it's job well. I've tried a
couple of other GEM based programs that are supposed to do the same thing, but
they've messed up my files, by either leaving out half the file or messing it
up somehow!

There's also a program that does the opposite (converts from the ST to Unix).
You use this when you want to upload text to the Unix machine. If you don't do
this you'll see strange characters each time you've pressed <return>, notably
"^M" (without the quotes).
Normally you won't have to convert text which you'll be uploading via
ASCII-upload since most comms programs have setup features that allow you to
remove "CR" characters when uploading. If you're connected to a Unix system,
set it up like that, so you can just upload any Atari text file.

But when uploading ASCII text via Zmodem you'll have to convert it (remember,
Zmodem is for binary transfer, and this includes everything- all control
characters etc). So why would you use Zmodem for text transfers when you have a
transfer mode made specifically for text?
Well, normally you wouldn't have to use Zmodem for text, but I recently found
out that you do when uploading "UUencoded" files. I'll explain what this is all
about...


EMAILING BINARY FILES (UUENCODING/UUDECODING)
---------------------------------------------
You might want to send a program or a file to a friend of yours via the
Internet, but how do you do this when all you can reach him by is email?
The answer lies in UUencoding/decoding.
You can't email binary data, therefore you'll have to convert them into text.
That is, pure ASCII text without all those strange control characters etc. that
you see (and hear beeps) when "viewing" a .PRG, .RSC file or whatever on the
desktop by renaming them to something else and double clicking them as a text
file to be read (or loading such a program/file into a text editor).

The easiest program on the ST to use for this purpose is the GEM based
shareware "Esscode". It will convert binary files to text (UUencoding)
or text files back to binary (UUdecoding). UUdecoding is used when the reciever
gets the file and wants to convert it back to it's original form.

Don't expect to be able to send HUGE programs via the net though, because many
mailers have size limitations, though ESScode and similar programs can even
"cut" the programs/files into many parts, so you can send it as several files,
then re-join them again. But this is generally more of a hassle than sending
small files as one single UUencoded file.

One thing you can do to save space and make things easier is to compress the
file(s)/folder(s) you want to send.
I generally use Zip for this, since it can be used with Unix and PCs as well.
(the reciever can check it out if he/she's on a Unix machine or a PC, and
read the text files etc. before it's used on the ST).
You can of course use .ARC, .ZOO, .LZH or whatever if you wish.
After you've compressed and UUencoded the file you need to convert the text
from ST to Unix, if you're not using the mailer program that is.
The reason I'm mentioning this is that I've had very bad experiences with
transferring UUencoded data into my mailer using ASCII-upload. I'm not sure,
but I think it has something to do with it comparing quotes or paranthesises,
that's used when programming.
Anyway, I've found out that uploading the UUencoded files using Zmodem and then
inserting them into the mailer while they're in the Unix machine works just
fine. And since transferring files via Zmodem keeps all the special characters
you'll have to convert them to Unix standard before uploading.
I understand this might be a little complicated, so I'll go through it once
again step by step;

1) Compress the program(s)/files if it's large. If it's just a small file you
   don't really need this. I recommend STZip since it's compatible with Unix
   Zip and PKunzip on the PC, and it's easier to keep a standard on things
   instead of using all sorts of compression methods (thereby needing a bunch
   of compression/decompression software on your/the reciever's ST).

2) Using "Esscode" or similar program, "UUencode" the (Zipped) file.
   the UUencoded file will get a .UUE ending so you know that it's encoded.

3) If your mailer won't accept UUencoded files you will have to convert the
   .UUE file to Unix, by using ST2UNIX.TTP.

4) While online, "rz" (recieve Zmodem) the .UUE file to the Unix machine to
   transfer it from your ST.

5) Enter your mailer and start a "reply" or "write to", fill in the address and
   subject, and whatever you want to write to the reciever, then "insert"
   the .UUE file into that email. Send it!

As for the reciever of the mail, he/she will have to save that letter
individually and "sz" (send Zmodem) back to the ST.
Then use "Esscode" to "UUdecode" (*DECODE*) the file. There's no need to remove
the header or anything from the mail, or even convert it to Atari text
standards.


I guess that about wraps it up. There are probably lots of details that I've
skipped, but this wasn't meant as a detailed "user manual", but more as a "get
you started" helper text.
As for the software, they can be found just about anywhere (sorry, I don't have
the specific FTP sites/directories for them), and there are programs that
do the same things that I haven't mentioned.
All this is just based on *my* experience, others might have different
ideas about what software works for them.
Whatever works for you is fine! (I used "Storm" for a long time, which is a
very simple program compared to "Connect", but now that I've gotten used to all
the features of "Connect" I'll never go back. And no, just in case you were
wondering- I'm not paid to advertise for "Connect", just a happy user :-)

I hope this has cleared up some of the mysteries a beginner might have on
his/her way to Atari "computer communications" and gets you started
without too much hassle and problems.
You might even have snapped up a few tips along the way!
good luck!

Hallvard Tangeraas, Oslo, Norway   18th June, 1995
 (hallvart@oslonett.no)

