Download/Upload For The Atari

Download/Upload For The Atari

Frank C. Jones, Silver Spring, MD

Use this to transfer programs and text files to or from your Atari using a modem and the telephone lines.

The program described in this article was developed over several months, with feedback from many people. I started writing it primarily because I was too cheap to go out and buy one. I wanted to try out my new communications hardware and look into some of the electronic bulletin boards that I had heard about. Furthermore, I used a mainframe computer in my work, and I thought that it would be convenient to be able to access it from the privacy of my home.

My first approach was to copy a short BASIC program by Henrique Veludo from COMPUTE! (February 1981, #9). This worked fine until I realized that a lot of the text went by too fast for me to read. I tried POKEing the incoming characters into a string, hoping to print it out later, but this was too slow; characters were being dropped, making things a bit hard to read. This led to an assembly language routine to speed things up a bit, and before I knew it I was on my way.

It wasn't long before I had added the upload capability so that I could transfer programs and text files to friends who had computers and modems. About this time I joined the downtown Atari club of Washington, D.C., and discovered their ARMUDIC bulletin board, developed and operated by Frank Huband.

After several weeks of enjoying the capabilities of this system and downloading lots of useful programs, I discovered that some of the members did not have terminal programs that would do some of the things that mine would do. I offered to give my program to the club and subsequently uploaded it to the ARMUDIC BBS.

I got calls about problems. I got calls with complaints. I got calls with suggestions. When I next talked to Frank Huband, I discovered that he had picked up a few suggestions and complaints too. We started working together to incorporate as many of the more reasonable ideas as we could, and over the next few months the program grew.

Since this article was intended to be utilitarian rather than tutorial, I have included no discussion of how the program does what it does. Instead, I have included complete instructions on its use and the BASIC listing. There are, however, a few peculiarities about the program that should be pointed out before we get into its operation.

Two Cautions

You may have already noticed that the statements on line 90 are preceded by a REM so that they are not executed. This line is to be used only by those people who find that the BREAK function does not work as described on their machines. The fault lies not in the computer, but in the 850 Interface Module.

Whenever concurrent I/O is turned on, the RS-232 port handler substitutes its own interrupt handlers for the ones in the OS ROM. This is necessary because concurrent I/O handles the serial bus interrupts differently from the way the operating system handles them. The machine language portion of JTERM detected pressing of the BREAK key by sensing what the 850 interrupt handlers did with it. Of course, this was too good to last: newer versions of the 850 Module handle the BREAK key by ignoring it (undocumented).

This leads us to line 90; it's a patch into the interrupt handler (new version) that enables the BREAK key. Warning: if the BREAK function works on your machine without line 90, don't use it; it will cause a crash if used with the older version handlers. So try it without line 90 first, and remove the REM if you find the BREAK key does nothing when you press it.

A further warning: this program should not be renumbered unless the subroutine at lines 2080-2110 is changed. This routine removes all of the data statements and initialization code after they are used to gain as much memory space as possible for the text buffer. If the program is renumbered and this routine is not changed accordingly, it will perform fatal surgery, and whatever is left won't be of much use. (To find out more about how this routine works, see my article in COMPUTE!'s Second Book Of Atari.)

For those of you who have some download capability already, the latest version of this program is available (free) from the ARMUDIC BBS (202) 276-8342. The program is available under the name of JTERM32 (or JTERM33 or... who knows what version will be available by now; this thing seems to have a life of its own). For the rest of you, type it in, being very careful with the data statements; an error here will probably make the system crash. Then read the instructions and start communicating.

Starting Up

JTERM is a download/upload terminal program for the Atari. It was written in BASIC and assembly language to combine ease in setting up and speed when in the actual terminal mode.

Note that an AUTORUN.SYS file with the RS-232 handler boot routine must be on disk and booted when you turn on your machine, if you are using a disk. The DOS command will cause the RS-232 handlers to be overwritten, so you must either have a MEM.SAV file on your disk or re-boot the handler after making a DOS call. Furthermore, it appears that the NEW command damages or wipes out the port handler as well. Therefore, you should always reboot the handler after using this command. An additional note: JTERM assumes that the modem is connected to RS-232 port #1. Also, the 850 Interface must be switched on before booting the disk.

JTERM is LOADed as a BASIC program, and when RUN it POKEs the machine language routine into a string called PROG$. While this is going on, the screen is black. After this set-up period is over, the first menu appears on the screen, along with information about the size and location in RAM of the available text buffer. All menu choices are made by simply typing the appropriate key that is highlighted in inverse video. (Type an ordinary character, not an inverse video one.)

The first choice to make is whether you wish to Download a file from the host computer or Upload a file to the host computer. If you wish to do simple communication without file transfer, Download is the proper mode to choose. After you choose between the Download and Upload modes, your next choice is between no translation (None), Light translation, and ATASCII. With Light translation, all high order bits are stripped from all outgoing and incoming characters, and the ATASCII EOL character (155) is changed to the ASCII CR character (13) on output and vice versa on input. No translation and ATASCII modes means that the 850 Interface Module does no changing of characters during either input or output. However, be warned that the program does some translation itself — more about that later.

The next choice is between the various modes of outgoing parity setting. (Note: incoming parity is not checked or changed by this program.) You should always select None if you have selected no translation because setting the parity on output will change the high order bit that was presumably to be preserved. This option was included for the users who wish to access mainframe computers that require certain parity configurations.

At this point, if you choose Upload you will be asked for the filespec of the file to be uploaded. When this has been entered, the file will be loaded into RAM and then listed to the screen as a check. You will then enter the terminal mode. But if you choose Download, you will go directly from the parity choice to the terminal mode without going through the file loading routine.

Terminal Operations

Whenever you enter the terminal mode, the flag (i.e., inverse video word) TERMINAL will appear at the top of the screen. This informs you that you are now in the machine language portion of JTERM. While you are in this mode, you may send data to and receive data from a host computer, provided all of the appropriate connections have been made. You may toggle the memory save function off and on by pressing the SELECT button; the flags MEMSTORE ON and MEMSTORE OFF will be printed on the screen as you toggle the memory.

While the memory save option is in effect, all incoming characters will be stored in sequence until the buffer is full. If the buffer should fill up, the flag MEMORY FULL will be printed on the screen. Note: If you have filled your buffer prior to an Upload, you should not turn on the memory save feature until you have completed the Upload. Otherwise, the incoming characters will overwrite your file.

When you enter the terminal mode, you will be in full duplex (i.e., only those characters that are received are printed on the screen and stored in memory). If the host computer echoes all characters that it receives, these characters will be incoming and will be printed and saved if desired. If the host computer operates in half duplex, it cannot send and receive at the same time, so it will not echo the characters that it receives from you. In this case you should turn on the half duplex mode. You can toggle between half and full duplex by pressing the OPTION button. Whenever you do, the flags HALF DUPLEX and FULL DUPLEX will be printed on the screen as appropriate.

Leaving Terminal Mode

When you are ready to leave the terminal mode, you may do so by pressing the START button. When you do, one of three things will happen, depending on the circumstances. If you have chosen the Upload option and have not yet uploaded the file, you will go into the upload mode. The flag UPLOADING will appear on your screen, and the buffer will be printed, 25 characters at a time, to the computer on the other end of the line. During this period you will still see all incoming characters displayed on your screen, so, if the host computer is echoing your transmission, you can watch the upload progress. When the upload is complete, you will reenter the terminal mode, this time in Download mode.

If you exit the terminal mode without saving anything to memory, you will automatically bail back out to the main menu, and you may start another session with different parameters if you wish.

If you were in Download mode and saved anything at all in memory, when you press START you will be asked for the filespec of the file to which you wish to save your memory, or you can type RETURN for further options (more about this in a moment). If you enter a filespec, this can be the cassette (C:), the printer (P:), the screen editor (E:), or a disk file (D:FILENAME). After you enter the filespec, the saved memory will be written to the file, and you will be told that you may reenter the terminal mode by pressing START.

If, however, you wish to save the memory to another file before returning to the terminal mode, press START and, before releasing the start button, press the OPTION button. This will bring you back to the request for a filespec. This may be repeated as many times as wished.

If you simply type RETURN instead of a filespec, you will be presented with a menu of three alternative choices. Pressing OPTION will erase your memory buffer and return you immediately to the terminal mode without changing any parameters. Pressing START will erase the buffer and return you to the main mode selection menu where you may reset any or all parameters. Finally, pressing SELECT will return you to the main mode menu while preserving everything saved in the memory buffer.

Internal Translations And Other Features

When you choose between Light and No translation in the second menu, you are choosing the configuration of your 850 Interface Module RS-232 ports. You should read your 850 instruction manual for information about these configurations. This program does some additional translation of its own, however.

First of all, nothing that comes in from the port is changed at all before it is stored in memory. Therefore, if you choose ATASCII or No translation for your port, you will save in memory everything exactly as it was sent. There will be some translation, however, before it is displayed on the screen. For example, no control characters (ASCII values < 32) are displayed. This means, for instance, that you will not see line feeds; they will, however, be stored and can mess up a program that you are downloading. You should not ask for line feeds; you do not need them even if the test messages are single spaced.

The carriage return character (ASCII 13) is translated to the ATASCII EOL character. The printer bell character (ASCII 7) is translated to the console bell (ATASCII 253). Finally, the ASCII backspace character (ASCII 8) is changed to the ATASCII DELETE/BACKSPACE (ATASCII 126). Again, none of this translation affects what is stored in memory; everything is stored exactly as it is received.

In ATASCII mode, no translation is done on any outgoing characters; everything is sent exactly as it comes from the keyboard. In the No translation mode, two characters are changed. The DELETE/BACKSPACE character is changed to the ASCII backspace character so that the key will have the same function with most host computers that it does in the Atari. Also, the RETURN key or EOL (ATASCII 155) is changed to the ASCII carriage return (ASCII 13) before it is sent. In light translation, the 850 module would do this translation automatically, but in the no translation mode it would not be done. There were enough situations in which inverse video characters (ASCII values > = 128) could be sent and received, but the host computer would still not recognize the EOL character to warrant this feature.

In half duplex operation, after a character has been sent to the port it is handed over to the input routine and handled just like any other incoming character.

An additional feature of JTERM is the ability to send a computer "BREAK" by simply pressing the BREAK key. This will cause the screen to flash, a beep to sound, the flag BREAK to be printed on the screen, and, last, a true break signal (approx. 0.5 sec. of SPACE tone) to be sent. (If all of this doesn't happen, see the discussion in the introduction.) Sending the BREAK signal will not be of much use when you are connected to a BBS since most of them do not recognize it, but it can be essential when you are connected to a mainframe computer whose attention cannot be gotten any other way.

You should note, however, that the BREAK routine passes briefly through BASIC. Should it be pressed more than once in rapid succession, you can cause a standard BASIC BREAK and terminate the program. If you should terminate the program, accidentally or on purpose, do not attempt to re-RUN it. Instead, restart it with GOTO 100. When the program is RUN for the first time, all of the DATA statements and most of the initialization statements are removed to make more room for the buffer; it cannot, therefore, be reinitialized without crashing.

One added note: when the terminal mode is entered for the first time, the DTR line on RS-232 port #1 is set for those modems that monitor this line.

Guidelines For Using JTERM

The JTERM menus were designed to provide maximum flexibility in communicating with many different types of computers, terminals, and bulletin board systems. This may cause some confusion, so here are some general guidelines:

Most often, you will select Download, Light Translation, No Parity, and Full Duplex. This should work fine when communicating with information utilities such as CompuServe and The Source, as well as with most bulletin boards.
For communicating between Ataris, choose the ATASCII mode instead of Light Translation. This allows full compatibility between characters sent and received. Also select half duplex instead of full duplex.
For downloading TRS-80 graphics from TRS-80 bulletin board systems, choose No Translation.
Usually you won't have to select a Parity option unless communicating with a mainframe computer.
The half/full duplex option accomplishes with software what the half/full duplex switch on some modems does with hardware. This option was included for those users whose modems lack the duplex switch.