Atari ST Modem
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;
- 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).
- Using "Esscode" or similar program, "UUencode" the (Zipped) file. the UUencoded file will get a .UUE ending so you know that it's encoded.
- If your mailer won't accept UUencoded files you will have to convert the .UUE file to Unix, by using ST2UNIX.TTP.
- While online, "rz" (recieve Zmodem) the .UUE file to the Unix machine to transfer it from your ST.
- 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)
