Classic Computer Magazine Archive COMPUTE! ISSUE 56 / JANUARY 1985 / PAGE 145

JTERM For Atari

Frank C. Jones

This versatile terminal program lets you communicate with electronic bulletin boards, access commercial information services, link up to mainframe computers at your school or business, and to upload and download files over the phone lines. Version 3.2 was first published in COMPUTE! in January 1983. The improved version 3.8 listed here adds support for 1200 bps modems and several other features. The program is written in BASIC and ma­chine language, and requires at least 32K RAM plus a modem attached to an 850 Interface Module or its equivalent.

"JTERM" is a flexible and responsive terminal program developed over several months with feedback from many people. It was born primarily because I was too cheap to go out and buy a commercial product. I wanted to try out my new communications hardware and look into some of the electronic bulletin boards (BBSs) I had heard about. Furthermore, I used a mainframe computer at work and thought it would be convenient to access it from the privacy of my home.

My first attempt was to copy a short BASIC program by Henrique Veludo in COMPUTE! ("Atari As Terminal," February 1981). The program worked, but I started making enhancements here and there, including a machine language routine to speed things up a bit. Before long I added the upload/download capability so I could transfer programs and text files to friends who had computers and modems.

About this time I joined an Atari user group in Washington, D.C., and discovered its BBS, run by sysop (system operator) Frank Huband. Soon I learned that some members did not have terminal programs that would do some things that mine would. I offered to donate my program to the club and uploaded it to the BBS. That's when the fun started.

I got calls with problems. I got calls with complaints. I got calls with suggestions. Huband picked up a few suggestions and complaints too. We started working together to incorporate as many of the reasonable ideas as we could, and during the next few months the program grew. As a result, JTERM is a thoroughly tested and debugged terminal program. Over the past few years it's been used successfully for thousands of hours by thousands of people.

Starting Up JTERM

First—and this is important—save the program on disk or tape before running it for the first time. To conserve memory, JTERM erases part of itself after initializing. If you run it before saving a copy, most of your typing will go down the drain.

When you're ready to get started, insert the BASIC cartridge (of course, the Atari 600XL and 800XL have built-in BASIC instead of a car­tridge). Plug the modem into RS-232 port 1 on the Atari 850 Interface Module. To work properly, the module must be switched on before you turn on the computer.

Next, if you're using a disk drive, before loading and running JTERM you must boot up with the RS-232 handler routine as an AUTORUN.SYS file on your DOS disk. The handler routine, included on your Atari DOS Master Diskette, allows the computer to address the RS-232 port on the interface module. Copy the handler routine from the DOS Master Diskette to your regular DOS system disk and give it the filename AUTORUN.SYS. This causes it to load and run automatically when you boot up.

Finally, load and run JTERM. It's normal for the screen to black out for a short period of time as the program initializes. When the first menu appears, JTERM is ready.

Note: For various reasons, Atari did not place the RS-232 handler routine in a very secure place in memory. If you exit BASIC to DOS after booting up, the handler will be overwritten. You must either have a MEM.SAV file on your disk or reboot the handler after making a DOS call. Furthermore, it appears that the NEW command damages or wipes out the handler as well. Therefore, you should always reboot the handler after using this command.

Selecting Menu Options

The first screen in JTERM tells you the size and location in RAM of the text buffer. The text buffer is an area of memory set aside so you can upload (transmit) and download (receive) files. The file, of course, can be text, a program, simple graphics, or merely a record of everything you send and receive when communicating with a remote computer. Naturally you can't upload or download a file larger than the buffer, unless you divide it into parts. The size and location of the buffer varies according to how much memory is installed.

This screen also presents the first menu choice, transmission speed. All menu choices in JTERM are made by simply typing the appropriate key highlighted in inverse video (type an ordinary character, not an inverse video one).

JTERM 3.8 now works with modems transmitting at either 300 or 1200 bits per second (bps), also referred to (less accurately) as 300 or 1200 baud. Remember that the modems at both ends of the phone connection must be transmitting and receiving at the same rate. If you aren't sure what the rate should be, the proper response is probably 300 bps.

Next, JTERM asks if you want to Download or Upload a file with the remote computer. If you want to communicate without transferring files, choose the Download mode.

Setting Translation And Parity

Now JTERM asks you to pick a translation setting. You can choose between No Translation, Light Translation, and ATASCII (Atari ASCII). This can get rather technical, so if in doubt, consult the section below on "General JTERM Guidelines." Most often, you'll probably choose Light Translation.

In the No Translation and ATASCII modes, the 850 Interface Module does not tamper with the characters as they're sent and received. (However, JTERM does some translation itself; more about that later.) With Light Translation, the high-order bits are stripped from all outgoing and incoming characters and the ATASCII end-of-line (EOL) character, 155, is changed to the ASCII carriage-return character, 13, during output, and vice versa during input.

The next choice is between the various settings of outgoing parity (incoming parity is not checked or changed by this program). You should always choose None if you've already selected No Translation, because setting the parity on output will change the high-order bit that you presumably wanted to preserve. This option is also rather technical, so if in doubt, choose None. The other parity options are included for those who wish to access mainframe computers that require' certain parity configurations.

At this point, if you chose the Upload option, you'll be asked for the filespec (device and filename) of the file to be uploaded. When you press RETURN, the file is loaded into the buffer and listed on the screen as a check. JTERM then enters the terminal mode, where all communications take place. If you chose the Download option, JTERM enters the terminal mode immediately after you select the parity.

Terminal Operations

Whenever you enter the terminal mode, the word TERMINAL appears in inverse video at the top of the screen. You're now in the machine language portion of JTERM. If you've made all the right connections, you can start talking with the remote computer.

If you selected the Download option, you can switch the memory save function on and off by pressing the SELECT button; the flags MEMSTORE ON and MEMSTORE OFF are printed on the screen as you toggle back and forth. With MEMSTORE ON, everything you send and receive is captured in the text buffer. With MEMSTORE OFF, everything is lost as it scrolls off the screen. If the buffer fills up, the flag MEMORY FULL appears.

If you selected the Upload option, JTERM prevents you from switching MEMSTORE ON until after you've uploaded the file. This is a new feature of version 3.8. It prevents incoming characters from overwriting the buffer.

The OPTION button toggles between full duplex and half duplex. JTERM defaults to full duplex when you enter the terminal mode for the first time. That is, only the characters received from the remote computer are printed on the screen or captured in the buffer. This assumes that the remote computer echoes all the characters it receives. If the remote computer is operating in half duplex, it cannot send and receive simultaneously and does not echo the characters. Therefore, you won't be able to see your own typing. The solution is to switch to half duplex mode yourself by pressing the OPTION button. The flags HALF DUPLEX and FULL DUPLEX appear on the screen each time you press OPTION.

Leaving Terminal Mode

When you're ready to exit terminal mode, press the START button. One of three things will happen:

  1. If you chose the Upload option and have not yet sent the file, JTERM immediately begins uploading. The flag UPLOADING appears on the screen and the buffer is transmitted, 25 characters at a time, to the computer at the other end of the line. You'll still see all incoming characters displayed on the screen, so if the remote computer is echoing your transmission you can watch the uploading in progress. When the transfer is complete, JTERM returns to the terminal mode as if you had selected the Download option from the menu.
  2. If you chose the Download option and did not capture anything in the buffer with MEMSTORE ON, you'll return to the first menu. You can start another session with different parameters if you wish.
  3. If you chose the Download option and captured anything at all in the buffer with MEMSTORE ON, the program asks you to type a filespec for the file you wish to save. (You can also press RETURN for further options—more about this in a moment.) If you enter a filespec, you can send the file to the cassette recorder (C:), the printer (P:), the screen editor (E:), or the disk drive (D : FILENAME). After you press RETURN, the file is sent to the appropriate device and JTERM lets you go back to terminal mode by pressing START.

If, however, you wish to save the buffer again (perhaps to a different device) before returning to terminal mode, press START and before releasing the START button, press OPTION. You'll be prompted for a filespec again. You can repeat this process as often as you want.

Now for those other options we mentioned. If you simply press RETURN at the filespec prompt, you get three alternatives. Pressing OPTION erases the buffer and returns you immediately to terminal mode without changing any parameters; pressing START erases the buffer and returns you to the menus, where you can change parameters; and finally, pressing SE­LECT returns you to the menus while preserving everything in the buffer.

Taking A Break

An additional feature of JTERM is its ability to send a break signal when you press the BREAK key. This flashes the screen, sounds a beep, prints the flag BREAK on the screen, and transmits a true break signal (approximately a halfsecond space tone).

The break signal is rarely needed when communicating with a BBS, since most of them don't recognize it anyway. But it can be essential when you're accessing a mainframe computer—there may be no other way to get its attention. Keep in mind, however, that the break routine passes briefly through BASIC. If you press BREAK a few times very quickly, you can trigger a standard program break and find yourself back in BASIC. If this happens, don't try to restart JTERM by typing RUN (it erased part of itself after initializing, remember). Instead, type GOTO 100.

A note to programmers about the BREAK key: If you've already studied the listing, you may have noticed the call in line 65 to the mysterious subroutine at line 2110. This subroutine was added when I discovered that the BREAK key doesn't perform the same way on different Atari computers. Actually, it's not the computer's fault—blame the 850 Interface Module. Whenever concurrent input/output is turned on, the RS-232 port handler substitutes its own interrupt handlers for the ones in the operating system ROM. This is necessary because concurrent input/output handles the serial bus interrupts differently than the operating system. Originally, the machine language portion of JTERM detected the BREAK key by sensing what the 850 interrupt handlers did with it. Of course, this was too good to last; later versions of the 850 handle the BREAK key by ignoring it.

So, the subroutine at line 2110 detects the presence of the newer interrupt handlers and installs a patch, if necessary, to make the BREAK key work as it should. This is a new feature of JTERM 3.8. Version 3.2 required users to remove a REM to activate the patch if needed. Now the program does this itself.

A warning: Do not renumber JTERM without modifying the subroutine in lines 2080–2100. This is the routine that erases all the DATA statements and initialization code after the program is run to conserve memory for the buffer. If you renumber the program without changing this routine, it will perform fatal surgery and what­ever is left won't be of much use. (To find out how this routine works, see my article in COMPUTE!'s Second Book Of Atari.)

General JTERM Guidelines

The JTERM menus were designed for maximum flexibility when communicating with many different types of computers, terminals, and bulletin boards. This may cause some confusion, so here are some general guidelines:

Most often you will select 300 bps, 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 BBSs. If your modem and the equipment on the other end both have 1200 bps capability, you can select the faster 1200 bps speed. However, remember that some utilities such as Compu­Serve charge more for 1200 bps access.

For communicating between Atari computers, 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 a TRS-80 BBS, choose No Translation.

Usually you'll select None for the parity option unless you are communicating with a main­frame computer.

The half/full duplex option accomplishes with software what the half/full duplex switch on some modems does with hardware. It is included for those whose modems lack the duplex switch.

Technical Notes: Translations

When you choose between Light Translation, No Translation, or ATASCII in the third menu, you're setting the configuration of your 850 Interface Module RS-232 ports. You should read your 850 instruction manual for information about these configurations.

Even in the No Translation mode, JTERM does some translating of its own. First, nothing received through the port is changed at all before it's stored in memory. Therefore, if you choose ATASCII or No Translation, JTERM saves everything exactly as it was sent. Except for the ATASCII mode, however, there is some translation before characters are displayed on the screen. JTERM won't display control characters (ASCII values less than 32). This means that you will not see linefeeds, for instance; they will, however, be stored and can mess up a program you are downloading. You should not ask for linefeeds from the other computer; you do not need them even if the test messages are single-spaced.

The cursor-control keys will not work in these modes since they have ASCII values of 28, 29, 30, and 31. In addition, before displaying anything on the screen, JTERM translates the carriage-return character (ASCII 13) to the ATASCII EOL character, the printer bell character (ASCII 7) to the console bell (ATASCII 253), and the backspace character (ASCII 8) to the ATASCII DELETE/BACKSPACE (ATASCII 126). Again, none of this translation affects what is stored in memory; characters are stored exactly as they are received.

In ATASCII mode everything is sent to the screen as it is received, because JTERM assumes you are communicating with another Atari. JTERM won't translate any outgoing characters, either.

In the No Translation mode, two characters are changed. The DELETE/BACKSPACE charac­ter is changed to the ASCII backspace, so it does the same thing on most remote computers that it does on the Atari. And the RETURN key, or EOL, is changed to the ASCII carriage return before it is sent. In Light Translation the 850 module would do this automatically, but in No Translation it doesn't. I added this feature because I felt there were enough situations in which inverse video characters (ASCII values from 128 up) could be sent and received even though the host computer would still not recognize the EOL character.

In half duplex operation, outgoing characters sent to the port are returned to the input routine and handled just like any other incoming characters.

Additional Details

•When terminal mode is entered for the first time, the DTR line on RS-232 port 1 is set for modems that monitor this line.

•JTERM is designed to work with the Atari 850 module and the Atari RS-232 port handlers. It will also function with any equipment that properly emulates this system. JTERM works fine, for example, with the ATR8000 RS-232 port and the handlers included with MYDOS version 3.18.

• 1200 bps operation was added to JTERM 3.8 because these faster modems are becoming cheap enough for home computer users to afford. Even I bought one.

•Although it was not mentioned in the January 1983 article, JTERM 3.2 switched MEMSTORE OFF and changed to full duplex whenever the program cycled through BASIC. The same thing happened when you returned to the menus or even pressed the BREAK key. Now these settings are preserved no matter what, even if the program is stopped and then restarted with GOTO 100.

• In ATASCII mode, JTERM 3.8 now lists all characters to the screen, including control characters. However, the screen editor does not respond to screen control characters (other than EOL) in three situations: (1) when a file to be uploaded is listed on the screen just after it has been loaded into the buffer; (2) during the upload process itself; (3) whenever you switch MEMSTORE ON in terminal mode. This feature was added by popular demand to make files being uploaded or downloaded easier to read on the screen. They now appear just as they do when you type LIST in BASIC.