UTILITY

Any Resolution

Dial XR

by Maloney

Multi-tasking the ST

We all have our own dream programs. The two main things that I do with my ST are writing and BBSing. The problem is that BBSs, unlike commercial systems, are single-user. If someone else is on-line, then I have to keep re-dialing until the line is free. If I use an attack-dialing terminal program, then my computer is tied up. Frankly, I have better things to do with my time than to watch a screenful of "ATDT" lines slowly scrolling by.

What I need is a program that will allow me to write while simultaneously auto-redialing. Connecting with the BBS would signal me, and one quick point-and-click mouse operation would activate the terminal. After I had logged-off, a single keystroke would return me to my original text screen. My file would be intact—the cursor would even still be right where I had left it.

After about a year I realized that no one else was going to implement my idea; there just isn't a large enough market to justify the investment of time and money. After all, my dream program is not necessarily yours. You might want to attack-dial while forecasting with a spreadsheet, plotting your bio-rhythm cycle, or whatever. Besides that, we're all accustomed to using the programs that we already have. We don't want the hassle of learning new ones to do the same tasks.

The Power of the GEM Interface

GEM provides part of the answer for us—the ability to access programs as desk accessories. Most of these are convenience items like calculators and notepads. Others, such as the VT-52 emulator provided on the ST language disk, are much more powerful. Insofar as I usually only access message bases, I don't often need a terminal with upload/download capability. The emulator would normally serve my needs if somehow I could make it auto-redial.

This is what inspired me to write "DIALXR." It functions as a shell, interfacing between the emulator and the operating system to turn the ST into an attack-dialing terminal. You can put it into the AUTO folder, and its operation is completely user-transparent. It is compatible with just about any GEM program (including the desktop), and it will also work (with some adjustments on your part) with many TOS programs. Best of all, it steals less than ¾ K of memory.

How It Works

TOS was written to be "programmer friendly." By this I mean that its four major sections—GEMDOS, GEM, the BIOS, and the XBIOS—are accessed indirectly through memory vectors which point to the addresses at which they actually reside. Because these "hooks" are located in RAM, a programmer can modify their contents to point to custom routines.

I used this technique to intercept characters being sent from the keyboard to the modem on the RS-232 port. The BIOS vector is changed to the address of a routine which interprets keystrokes, setting and resetting flags and timers. The address of a second routine is placed in the vbl (vertical blanking) interrupt queue. This latter code is invoked about 60 times per second.

Magic Fingers

These two routines work together. After you enter the ‘ATDT’ (or ‘ATDP’) sequence to dial a number, the system waits for 30 seconds. If a connection has not been established, then the program forces the modem to disconnect from the line. It then waits for two seconds (to let the phone line settle), reconnects, and finally the "A/" redial command is sent to the modem. The BIOS handles this as though you had the emulator on-screen and were manually typing in the command.

You can use any Hayes-compatible (or semi-compatible) modem connected to the RS-232 port. The only requirement is that it accept the "ATD" and the "A/" commands.

So Let's Use It

If you're not familiar with the VT-52 emulator, you should check out the sections in your ST owner's manual about the emulator and changing the RS-232 configuration. Chances are that the only parameter that you will need to change is the baud rate. Be sure to save the desktop after doing so.

Enter and RUN the BASIC loader to create the file "DIALXR.PRG" on the disk in drive A. (Don't forget to check your typing with ST-Check.) Again I suggest that you place this file into the AUTO folder. Your boot disk will also require the emulator .ACC file.

Boot-up your ST. If your application program is GEM-based, then double-click on it, and after it is up, load in the file with which you will be working (if any). Turn on your modem and select "VT-52 Emulator" from the "Desk" menu. Enter the dialing sequence, and then return to your main program by pressing the "undo" key.

When the BBS answers your call the bell will sound, and the screen will change to reverse video. In about a quarter second the bell will again ring, and the screen will return to normal. Then just select the emulator and logon. That's all there is to it!

After you log-off press "UNDO" to return to your application. You may, of course, elect to attack-dial another system before doing so. "DIALXR" is fully re-entrant.

Another option that you have is to ignore the on-line signal. Insofar as BBS programs will log you off if they do not receive a keystroke within a couple of minutes, if you've changed your mind about going on-line, you can continue with your main program. As an alternative you can switch your modem from "Data" to "Voice" or just turn it off.

A Few Final User Notes

"DIALXR" plays by the rules of TOS, so you should not have compatibility problems with any application program—providing that it also follows proper programming procedures. Any program that insists on stealing the second vbl interrupt vector rather than searching the queue for a free one will incapacitate "DIALXR." This also applies to other utilities that you might put into the AUTO folder. To prevent this problem, copy "DIALXR" into the folder last.

Another possible pitfall could arise if your main program intercepts the BIOS vector. If the program does not restore the vector when it exits, your ST will definitely crash. Also beware of video games—some of them can be excited only by resetting your machine.

The only other limitation was mentioned earlier. If your application is a TOS program, you must dial through the emulator before loading and running the main program. Likewise, when you receive the on-line signal, you must exit before the BBS times out. As a rule of thumb do not initiate any unstoppable process which requires more than a couple of minutes.

I think that you will find that even if you have a full-featured terminal program you will be using it less and less as you become familiar with "DIALXR."