Trouble in PC CTTY (PC World by Richard Steck) According to the DOS 2.0 manual, CTTY changes the standard input and output console to an auxiliary console, or restores the keyboard and screen as the standard input and output devices. You will need, as a minimum: 1) an asynchronous communications adapter, also called a communications card or board; 2) a dumb terminal or a second personal computer to function as a dumb terminal; 3) a modem eliminator cable; and, 4) communications software for the terminal. Connect the remote terminal to the PC COM1: or COM2: port using the modem eliminator cable. Set the baud rate, parity, and other bit characteristics of the terminal. The defaults for the DOS MODE command (9600 baud, even parity, 7 data bits, and 1 stop bit) work fine. (In the discussion that follows, COM1: and COM2: are referred to as COMn:.) Type the DOS MODE command at the PC as follows: MODE COMn:9600. You should be able to issue a CTTY command at the PC as follows: CTTY COMn. Once this command is given, the remote terminal should begin to function as the PC's terminal. The command works only sporadically, however. Often the RTS and DTR signals of the COMn: are not supplied with the voltages required by some modems and terminals. A BASIC program can activate the RTS and DTR signals by issuing a command such as: OPEN "COM1:baudrate,parity,databits, stopbits" AS #1. An example of the command is: OPEN "COM1:9600, E,7,1" AS #1. This activates the COM1: port and permits you to read and write data to it. When the program ends either normally or abruptly, the active COMn: files are closed and the communications ports are deactivated. In other words, there is no simple way to open a COMn: port and hold it open with BASIC. A similar problem occurs when using the DOS 2.0 PRINT command and routing output to the COM1: port; the COMn: port cannot be held open. The program shown in Figure 1 opens the COMn: ports and holds them open for use with the CTTY and PRINT commands. The program pokes the appropriate addresses given in the IBM Technical Reference manual. Once the COMn: port is active, you can issue the CTTY command at the PC: CTTY COMn. At this point, the PC keyboard and screen become inactive and a DOS prompt appears on the remote terminal. You can issue some simple commands such as DIR to get the idea of how this works. You can also issue the following command to return control of the console back to the PC: CTTY CON. After CTTY transfers control to a remote terminal, nearly all DOS, EDLIN, and DEBUG commands can be used from the remote terminal. Some commands do not function properly, however. For example, the familiar command: COPY CON:filename (frequently used to create short text files directly from the keyboard) does not operate remotely. Instead, you must type: COPY COMn:filename to get the same effect. But even this command has problems. For some reason, when used remotely, the COPY command does not accept carriage returns. All remotely entered text enters the file in a continuous line. To add to the confusion, linefeeds (Ctrl-J) are accepted. Two carriage returns in succession cause the destination file to be closed. The reverse process: COPY filename COMn: works as you would expect, as does the TYPE command. Even when executed from a remote terminal, BASIC programs continue to display output on the PC screen. Programs can be written to route output to the remote terminal by OPENing the COMn: port and sending output directly to the port, but as soon as the program ends, COMn: is CLOSEd and the terminal is disconnected. You can run non-interactive BASIC programs through a remote terminal as long as the last statement in each program is a SYSTEM command. To stop scrolling, use Ctrl-S or you will lose date. True BREAK is not recognized, but Ctrl-C seems to have the same effect in a BASIC program. The type-ahead buffer works erratically. If you want to control your system remotely through a modem, you will need an auto-answer modem. The Hayes Smartmodem works well. To put the Smartmodem into an auto-answer state, run the program shown in Figure 2. After the AA indicator lights up, type CTTY COMn: and dial from a remote modem. When the DOS prompt appears, you're in business. You can make repeat calls as long as you don't lose control of the CTTY command or lock up the system. Accessing DOS in this manner is still very primitive compared to the results achieved with the Remote Access program from Custom Software. Remote Access gives nearly total remote control, while CTTY gives limited control. If you need to operate your PC through a remote terminal or a modem, CTTY can help you. CTTY gives you reliable access to a limited number of DOS functions from a remote hard-wired terminal, a computer or a modem. You can use it to extract files from the PC, to initiate batch jobs, and to access EDLIN and DEBUG. You can also attach an auto-answer modem and take control of your system via telephone. CTTY does not match the performance of a program specifically designed for accessing the PC through a remote terminal. Perhaps the next release of DOS will include an improved CTTY command that lives up to its potential. - - - - - Figure 1: 10 'This program fixes COM1: by turning on RTS, DTR 20 ' 30 OUT &H3F9,&HB 40 OUT &H3FB,&H1A 50 OUT &H3FC,&HB 60 OUT &H3FE,&HF0 70 SYSTEM 10 'This program fixes COM2: by turning on RTS, DTR 20 ' 30 OUT &H2F9,&HB 40 OUT &H2FB,&H1A 50 OUT &H2FC,&HB 60 OUT &H2FE,&HF0 70 SYSTEM - - - - - Figure 2: 10 'Sets up Hayes Smartmodem for auto-answer 20 ' 30 OPEN "COM1:300,E,7,1" AS #1 40 PRINT #1, "AT SO=1" 50 FOR I=1 TO 2000:NEXT I 'DELAY WINDOW 60 PRINT #1, "AT H" 70 SYSTEM ----------------------------------------------------------------- Remote Access with CTTY (PC Magazine Vol 4 No 3 Feb 5, 1985 by A. Glossbrenner) CTTY lets you run your PC from another computer's keyboard (console). To put CTTY to work, you'll need an auto-answer modem connected to your PC, as well as a second communicating computer and a modem at some other location. You'll also need a disk with COMMAND.COM and MODE.COM files, and possibly one or more of the batch files and other files discussed below. First, make sure your PC's modem is set properly. If you have, for instance, a Hayes Smartmodem, set Switch 5 to the up position to tell the modem to answer the phone on the first ring. Then set Switch 6 up to disable the modem's automatic assertion of the Carrier Detect signal. The PC doesn't need this signal, and it could cause unforeseen prblems later in the procedure. Since most commerical PC communications programs require you to disable Carrier Detect this way, there's a good change your modem will already be properly set. Next, create a simple batch file: MODE COM1:300 CTTY COM1 As the DOS manual explains, you may specify a variety of communications parameters when initializing the COM1 port with the MODE command. If you specify only the baud rate (300 or 1200 when using a modem), the program defaults to 7 data bits, even parity, and 1 stop bit. The parameters you enter will depend on the communications settings you'll be using on your remote machine. Interestingly, the PC does not seem to care whether the remote system sends it both a carriage return and a line feed or just a carriage return. Run this file and flip on your modem before leaving the office. Once you've issued the CTTY COM1 command, the keyboard will be disabled and nothing else will appear on the screen. To the computer the COM1 Receive Data line is the keyboard, and the Send Data line is the screen. The only way to restore keyboard control is to reboot or send the command CTTY CON into the machine via the communications port. Now you're at home. You've dialed your office computer, and the PC's modem has picked up the line and made the connection. The first thing you'll see on your screen is the PC-DOS prompt. From that point on, you can change logged drives, call for directories, display text file, redirect them to the PC's printer (with the command TYPE FILENAME.PRN), or enter any other DOS command. (If you're going to be accessing your hard disk or using DOS path names, be sure your remote system can generate a left backslash or transmit an ASCII 92.) You can also upload information from your home system to your office PC, and you can download in the opposite direction. You can even run at least some of your IBM programs remotely, specifically those that generate output a line at a time. Those that require sophisticated cursor controls to let you move all over the screen cannot be used. Fortunately, you can get around this limitation. For example, you may be disappointed to find out that you will not be able to add records conveniently to your dBASE files. But since that program's output is line oriented, you can easily list or print records to the screen of your remote system. You just have to remember one trick: Run the INSTALL module before trying to run dBASE remotely. When dBASE v2.4 is installed in your PC, the program sends its output to the PC's screen, regardless of whether CTTY is in effect. Installing it for the IBM Displaywriter (selection M on Menu #1) solves this problem and sends the output to the COM1 port when CTTY is enabled. Even with complex programs, you're not out of luck. Since the worksheets for such programs are stored as text files, you can transfer them to your remote system. Just key in TYPE FILENAME to display them on your home screen. Save the listing to disk; then hang up and load them into the version of the program that runs on your home system. When you're finished adding data to your spreadsheet at home, you will want to call your office computer again and transmit the updated worksheet text file. EDLIN.COM is the ideal tool for this purpose. Make sure that the EDLIN text editor is available to your PC; then type EDLIN FILENAME on your remote system's keyboard. When you see the EDLIN asterisk prompt, hit I (for Insert). You'll see 1:* on your screen, at which point the program will be ready to receive text. You can transmit VisiCalc and other text files to EDLIN continuously at 1200 baud with no problems. When the transmission is over, you'll see a line number followed by a colon and an asterisk. At this point, the DOS manual says to hit a Ctrl-Break to get back to the EDLIN command mode. If you're using a non-IBM computer, hit Ctrl-C. When the lone star appears, key in E to end the EDLIN session and write the file to disk. When you finish your on-line session, you'll have a number of choices. If you simply hang up the phone, the PC's modem will do likewise and then get ready to answer the next call. If you key in CTTY CON at your remote terminal, the PC will revert to normal operations and you will no longer be able to reach it via modem. Alternatively, you could tell the PC to run a previously prepared batch file or one that you create on the spot with EDLIN. You might want to have it print out the files you have sent it after you sign off, for example. Or you might order it to do a long sort. With the right equipment, CTTY can handle many tasks. If you use it often, consider getting a screen-blanking program to minimize the effect of leaving your monitor on all night. ----------------------------------------------------------------- Screen Blanker (PC Magazine Vol 4 No 15 July 23, 1985 User-to-User) For users who leave their monitors on all night to use the CTTY remote control, the program below will blank their screens as recommended in "Remote Access with CTTY" (Vol 4 No 3). Enter the program with DEBUG. To run the program, simply type BLANK at the DOS prompt. To return from the blank screen, use the DOS MODE command or change the byte at &h108 from 00 to 07. - - - - - BLANK.COM: A>debug -a 100 xxxx:0100 mov dx,1950 xxxx:0103 mov cx,0000 xxxx:0106 mov ax,0600 xxxx:0109 mov bh,00 xxxx:010B int 10 xxxx:010D mov al,00 xxxx:010F mov dx,03d9 xxxx:0112 out dx,al xxxx:0113 int 20 xxxx:0115 -rcx cx 0000 :114 -n BLANK.COM -w Writing 0114 bytes -q NOTE: To create UNBLANK.COM, substitute MOV BH,07 for the line MOV BH,00 and enter MOV AL,# instead of MOV AL,00 -- substituting the hex number of your border clor (3=cyan, 2=green, etc.) for the #. Also, name it UNBLANK.COM. ----------------------------------------------------------------- Control Your PC From Anywhere with CTTY (PC Magazine Vol 4 No 5 Mar 5, 1985 by S. Manes) CTTY lets you change DOS's default input/output device from your usual keyboard and screen (also known as the console) to any other character-oriented device you wish. The format is: CTTY device-name. For some reason, CTTY does not want to see a colon at the end of a device name. It expects COM1, not COM1:, and LPT1, not LPT1:. Violate the rule and you get an "Illegal device name" message. Let's say you decide to give your printer the job of standard I/O. You issue the command: CTTY PRN. As soon as you hit the Enter key, you see a blinking line cursor. And if the printer is on, the prompt is printed. You then bang on the keyboard to get some sort of response. Nothing happens, not even a Ctrl-Break. That one-line command ordered DOS to look for its input from and send its output to the printer. Your printer doesn't have a keyboard, so there's no way it's going to send input to DOS. You just locked yourself out of your computer. Reboot time. You can only use CTTY to transfer control to a device that can talk back to the computer such as a remote terminal connected somehow to the COM1 (or AUX) port, which is what you'll be using for your remote control experiment. CTTY can be handy for a couple of cute tricks. One is transferring I/O to the NUL device, a hypothetical peripheral that does absolutely nothing. Why would you want to transfer control to NUL? Say you wanted to keep somebody from peeking at the operation of a batch file you'd set up. The batch command ECHO OFF suppresses the display of the individual commands in the file but not the results of those commands. By transferring control with CTTY NUL, you can keep a user in the dark about what's really going on. Or by using CTTY PRN, you can get, for future reference, a complete printed record of what's happening. A simple batch file might look like: rem I'LL BE BACK IN A SECOND CTTY NUL WHIZDRIVE D: SPOOLEM ETC ETC2 CTTY CON rem ALL DONE The next-to-last line of the file (CTTY CON) restores control to the keyboard and screen (CONsole). Put the following little file in the root directory of someone's hard disk and call it AUTOEXEC.BAT: ECHO OFF CLS CTTY NUL Every time the machine boots from the hard disk, you'll see ECHO OFF for a second and then a flashing cursor on an otherwise blank screen. That's all, until somebody gets the bright idea of booting from a normal floppy. You'd think that sticking the CTTY NUL command at the beginning of a batch file would, by disabling the keyboard, keep the user from being able to terminate operations prematurely with Ctrl-Break. Wrong. For some reason, Ctrl-Break will, as usual, force DOS to ask, "Terminate batch job (Y/N)?" Unfortunately, since the question goes to NUL or PRN or wherever and not the console, you'll have to boot again. Furthermore, just because DOS knows that the NUL device or some other device is taking the place of the keyboard and screen doesn't mean all programs do. Many programs violate the sacred rules of DOS, bypassing it to write directly to the screen memory and pick up input directly from the keyboard buffer. Thus, it's possible to write a cute little batch file containing: CTTY NUL BASICA All this one does is transfer control to the NUL device and then call up BASICA which, since it violates DOS rules, runs just fine. But as soon as you exit BASICA, you're back at DOS, utterly helpless, since the statment CTTY CON has never been invoked. Replacing the BASICA line with WS would give you the same effect with WordStar. But DEBUG and EDLIN, both of which do use DOS keyboard and display functions, would effectively hang the system in this situation. Understanding this quirk is important when you start controlling your computer from afar. You won't be able to run and use remotely any program or utility that doesn't stick to DOS rules. With CTTY, you can't use the BASIC(A) editor from afar (and most BASIC programs will be likewise useless), and WordStar and its ilk will remain shut-ins. A quick rule of thumb is that if a program lets you move your cursor around the screen with aplomb, chances are CTTY won't redirect it. You can use virtually every extant DOS function -- TYPE, COPY, RENAME, ERASE or FORMAT. You can use DEBUG and even EDLIN. You can run programs written in BASIC that have been custom designed to take advantage of CTTY. And you can upload and download files to your machine. If your idea of remote telecommunications is a machine in the next room, all you need is a COM port, an RS-232 cable and a null modem adapter to hook up the two machines back to back. A null modem adapter is a device that merely swaps two of the wires in the RS-232 line to fool computers into thinking that they are talking to terminals. A modem cable and a null modem adapter will hook up from an IBM PC to, say, a Radio Shack Model 100. But if you want to use the same modem cable and null modem adapter to connect two PC's together, you'll need the gender changer, another connector that turns one PC's male DB-25 plug into a female. You've now got two machines hooked together. Say one's your PC and the other's a Radio Shack Model 100, but what the "remote" machine is doesn't matter as long as it's a terminal or is running software to emulate one (PC-TALK or Smartcom II will do). Most COM ports are capable of speeds up to 9600 baud, but the terminal software that drives them often has trouble keeping up beyond 1200 baud. The Radio Shack's slow screen updates, for example, effectively limit its TELCOM terminal program to 300 baud for all but uploading files. So you'll start the Radio Shack's terminal program (TELCOM) running with parameters of 300 baud, no parity, 8 bits, 1 stop bit, and disable Xon/Xoff -- Stat 38NID in TELCOM's code. At this point, you see the A> prompt on your PC. First make sure the DOS file MODE.COM is in your default directory. Then, to initialize COM1 to match the parameters of the terminal, enter from the PC's keyboard: MODE COM1:300,N,8,1 or whatever's needed to match the other machine. The MODE command will reply with parameters, including a trailing comma and hyphen that are immaterial for your purposes. To check the connection, enter from the PC keyboard: DIR>COM1 If you see the directory scrolling up the remote machine's screen, you're in business. If not, there may be a problem with the connection or the way you typed the command. An error message that appears on the PC's screen should give a hint. Once you're properly connected, enter from the PC keyboard: CTTY COM1 The PC's A> DOS prompt should appear on the remote machine's screen. From then on, your PC will respond to what you type in from the remote keyboard and remain deaf to characters from its own. Just about any DOS command will work. If you use TYPE on a file, you'll see it on the remote machine's screen. You can use CHDIR, MKDIR, DIR, DATE, ERASE, PATH, RENAME, TIME, RMDIR, VER, VERIFY and VOL with ease with any terminal from Apple to Zenith. You can change default drives, directories, and even the prompt. And if the proper files are available in the machine, you can use them with COMP, FORMAT and so on. EDLIN works fine, and so does DEBUG. About the only DOS command that won't work is CLS. The PC echoes your commands back to you, so it's possible that you may see doubled characters on the terminal. In that case use your terminal software's option to disable echoing to the screen. It may be called "full," "half," "duplex," "echo," or "local mode." Whatever it is, try both positions and use the one that doesn't stutter. While you're at it, learn how to engage and disengage the feature: for certain operations, such as typing to a file, the PC won't echo what you type. When you're ready to swap control back to the PC, all you have to do is enter: CTTY CON The A> prompt will reappear on the PC's screen. Now you've got the basic idea. But how do you turn it into truly remote control with the help of a modem and password protection? If you're ready to see your machine's A> prompt on a machine 3000 miles away, here's what you need: * An IBM PC with a functional asynchronous comms port * DOS 2.1 * BASICA 2.1 * A Hayes-compatible intelligent modem, cable and phone Substitutions are possible, and DOS 2.0 or higher should work. If everythings hooked up properly and turned on, you first need to initialize your COM1 port. Do it at 1200 baud, no parity, 8 bits, and 1 stop bit. Assuming MODE.COM is on your default drive, enter: MODE COM1:1200,N,8,1 MODE should return a message confirming your request. The extra comma and hyphen at the end of the parameter list it displays in response are ok. Now enter: TYPE CON>COM1 This statement will send everything you type from the keyboard out to your COM1 port and, if your modem is turned on, to the modem itself. Since the next step is to initialize your modem and put it in auto-answer mode, enter the Hayes commands: AT S0=1 E0 Q1 Hit Enter, then hit Ctrl-Z and Enter to get back to DOS. If you have an outboard modem, you should see the auto-answer LED on. The AT gets the modem's attention. The S0=1 readies it to answer the phone on the first ring. The E0 command keeps the modem from echoing commands back to the terminal. The Q1 suppresses the modem's "Result codes" -- messages such as "Connect" and "OK." This function is absolutely essential to avoid some frustrating problems. One problem may have occurred already. When you gave the modem its first command, including, in essence, the order to "shut up," it probably insisted on echoing the command or a response to you nonetheless. That bit of noise is probably somewhere in the comms buffer, ready to produce an irritating "Device read fault" error or some such thing. Best to purge it: Simply issue another MODE command exactly like the one you gave before: MODE COM1:1200,N,8,1 Now your modem is in auto-answer mode. All that's left is to transfer control to the COM1 port. Enter: CTTY COM1 At this point, your job is done. Anybody with a terminal that can dial up your machine with the right parameters should discover your machine's A> prompt on the screen after the first ring. From the remote terminal, just about anything goes. The remote machine can use virtually any DOS function on your machine. The Ctrl-C key combination breaks out of most mistakes, serving as a Ctrl-Break surrogate. If you want to see what's in a file, simply enter from the remote terminal: TYPE filename>COM1 The remote console remains COM1 for purposes of redirection. Re- directing something to CON will put it on the host PC's screen. Watch out with stuff that doesn't obey DOS rules. Type BASICA or WS, and you'll find you've started a program that won't respond to your commands, including Ctrl-C. Your machine will be dead until you return to it and set things up again. If the DOS prompt is visible when you hang up, your modem will return to auto-answer mode, and you'll be able to dial in again. This situation is one big reason you must suppress the modem's inclination to chatter, as noted above. If you don't, the modem sends the message "No carrier" to your machine when you hang up. DOS parses the NO CARRIER command. Finding no file with that name, DOS sends the modem a "Bad command or filename" message. The modem sends an "Error" message to your PC. DOS parses this ERROR command. And this goes on and on. Let's say you hang up and leave your PC ready for later use. Your machine is at the mercy of the person with the remote terminal. He can steal or erase your files, debug your programs, put obscene messages in your AUTOEXEC.BAT files, or even format your hard disk. Just deleting FORMAT.COM from your hard disk won't help. Somebody can simply upload a copy of FORMAT.COM. The solution is password protection, the purpose of the program PW.BAS in Figure 1. The first three lines put a message on your PC screen so you know the program is running. Lines 40 and 210 try to get around the comms errors that have a way of occurring when you least expect them. Line 50 simply opens the COM port as a file. Line 60 does precisely what you did when you typed in your modem command from the keyboard. Line 70 takes the modem's unwanted response and shoves it into a variable called JUNK$, which gets it safely out of the way. The carriage returns and "Hello" in lines 80 and 90 get things going and should print out at the remote terminal when it logs on. The remote user should hit a carriage return at the "Hello" prompt. In lines 120 through 190 the remote terminal gets three tries at the correct password, which is this case is "jones", all lowercase, although you can insert anything you like between the quotation marks. Line 150 prints the user's tries to the PC's screen, just for testing purposes; it, too, can be deleted without harm. When a user gets the password right, the program sends a short message to the user and writes a 1-byte file called OKAY to the default disk. If all three password tries fail, no such file gets written. Either way, the program exits to DOS. Why write an apparently useless 1-byte file to disk? Because you're going to use the IF function of DOS batch files, and IF can spot only three things: a parameter typed in after a filename, an errorlevel code that only assembly language programmers know how to set, and the presence of a specific file. The batch file is shown in Figure 2. This file makes the whole process of setting up your computer for remote answering as easy as pie. You type ANSWER. The batch file initializes your COM port and runs PW.BAS. But PW.BAS has not yet given the remote terminal any sort of control over your machine. The command that does that is CTTY COM1, and it hasn't been issued yet. When PW.BAS returns control to DOS, the batch file tests the line IF NOT EXIST OKAY GOODBYE. If the file OKAY isn't there, it means the caller didn't get the password right, and the batch file passes control to another batch file called GOODBYE which hangs up the phone. If the password is correct, OKAY has been written to the disk, so ANSWER erases it to clear things up for next time. Then it gives the remote machine control with CTTY COM1 and sends it a little message about logoff procedures. This program is pretty bulletproof. If you somehow break out of PW.BAS the machine will just sit in BASICA and go nowhere. Control does not pass to the remote terminal until the password has been verified. GOODBYE.BAT is shown in Figure 3. The first thing this file does is wrest control back from the remote user. Then it runs a short program, BYE.BAS (Figure 4), whose sole function is to hang up the modem. Finally, it reinvokes ANSWER.BAT, setting up the machine for the next user. Hayes-type modems use time delays to make sure they're looking at commands, not transmitted data. Lines 40 and 70, which do the delaying, work fine on a PC or XT; on an AT, you'll probably have to change the 2000 to 10000 or so. So to run this system, all you need to do is have the following files in your default directory: ANSWER.BAT BASICA.COM BYE.BAS GOODBYE.BAT MODE.COM PW.BAS Type in ANSWER, and the rest is automatic. As the welcoming prompts indicate, the remote user should type GOODBYE before logging off, thereby readying the system for the next user. If for some reason the remote terminal fails to log off properly -- say, by typing GOODBYE from somewhere other than the original default directory, or simply by getting disconnected inadvertently -- the machine will remain available for remote control to all comers. It can be reset for password protection simply by logging on again and exiting properly. You can modify any or all of these files for special situations -- different comms parameters would be the most likely. Just be sure you modify all the comms parameters in all the programs. What about uploading and downloading files? The commands: TYPE filename>COM1 and COPY filename COM1 work reasonably well for uploading files to the remote terminal. But for some reason, the commands: TYPE COM1>filename and COPY COM1 filename can be fraught with problems. When you try them, DOS somehow adds up two carriage returns (ASCII 13) in a row and interprets them as Ctrl-Z (ASCII 26), thereby terminating your file transfer. The solution is the program MOVIT.BAS in Figure 5. Line 10 of MOVIT may look a bit unusual, but it is important because when any error occurs, it simply tosses you back to DOS. Without this line, the program might somehow die, print an error message to the host PC's screen, and then refuse to return control to the remote terminal. Including the line makes sure that you'll always get back control one way or another. Lines 30 through 150 are pretty much self-explanatory. You can add error trapping to 160 and 170 if you choose. Line 200 of the downloading module asks the remote user for a filename in which to store the file to be sent. If you like, you can add a module offering a directory, but the remote user can easily hit the Enter key, drop back into DOS, and then call up whatever directory is needed. Line 210 accepts the filename. Line 220 does some rudimentary error trapping to avoid creation of a file with a space in the middle of the name. Whereas BASIC can handle such files, DOS can't. A truly decent error-trapping module here could eliminate the possibility of other illegal filespecs. Line 230 prints a message, establishes how many characters are in the comms buffer, and calls that number JUNK. Line 240 opens the file for appending; that way, you can't accidentally overwrite a file that already exists. The loop in lines 250 through 270 simply checks the comms buffer for incoming characters. As soon as it senses something coming in, it gives control to line 280; if nothing comes in for a good long while, it terminates the program. AT users may want to increase the maximum size of the variable in line 250. Line 290 ignores the junk in the comms buffer and sends the first incoming characters to the open files; line 300 sends the rest. Line 310 senses when the communication is at an end and returns control to DOS and the remote terminal. If you're planning to use this program to type a file in directly from the remote keyboard, increase the test value of FLAG in line 310 to a value in the thousands; you'll need a similar increase on an AT or super-performance machine. Uploading, in lines 400 through 480, is equally straightforward. Again, you may have to extend the time delays if you have a turbocharged system. The reason for them is to avoid introducing unwanted characters into your files. Without the delay at the end of the uploading module, for example, you'd be stuck with the DOS prompt at the end of your file. The delay gives you time to terminate the remote terminal's downloading mechanism before the DOS prompt reappears. This is an absolutely bare bones and plain vanilla demonstration program that seems to do the job. With a little talent and forethought, you could add Xon/Xoff or Xmodem protocols, addition of line feeds, character stripping, error trapping and lots of other goodies. The easiest way to use the file is to make it callable from a one- line batch file. Call it MOVIT.BAT and makes its entire contents: BASICA MOVIT Be sure to include a carriage return as the last character. Then when you want to do a file transfer, all you'll have to do is type MOVIT at the DOS prompt. - - - - - Figure 1: PW.BAS, a password-checking program. 1 'PW.BAS 10 PRINT "WAITING FOR INCOMING CALL ....":PRINT 20 PRINT "Do NOT disconnect or turn off modem!":PRINT 30 PRINT "In fact, don't touch this machine, period!" 40 ON ERROR GOTO 210 50 OPEN "com1:1200,n,8,1" AS #1 60 PRINT #1,"AT S0=1 E0 Q1" 70 INPUT #1,JUNK$ 80 PRINT #1,CHR$(13;CHR$(13) 90 PRINT #1,"Hello .....?" 100 INPUT #1,R$ 110 FOR I=1 TO 3 120 PRINT #1,"Password?" 130 PRINT #1,CHR$(10) 140 INPUT #1,R$ 150 PRINT R$ 160 IF R4<>"jones" THEN 190 170 PRINT #1,"Okay. One moment, please." 180 OPEN "OKAY" FOR OUTPUT AS #2:PRINT #2,"*":CLOSE #2:SYSTEM 190 NEXT 200 SYSTEM 210 CLOSE #1:GOTO 50 ---------- Figure 2: ANSWER.BAT, prepares a host PC for remote control MODE COM1:1200,N,8,1 BASICA PW IF NOT EXIST OKAY GOODBYE ERASE OKAY CTTY COM1 rem When you're ready to sign off, rem please type the word GOODBYE rem and hit the Enter key. Thanks. ---------- Figure 3: GOODBYE.BAT hangs up the phone and readies PC for the next caller CTTY CON BASICA BYE ANSWER ---------- Figure 4: BYE.BAS, in conjunction with GOODBYE.BAT commands a modem to hang up the phone 1 'BYE.BAS 10 PRINT "Hanging up modem ...." 20 OPEN "com1:1200,n,8,1" AS #1 30 PRINT #1, "Bye ...." 40 FOR I=1 to 2000 50 NEXT 60 PRINT #1,"+++"; 70 FOR I=1 TO 2000 80 NEXT 90 PRINT #1,"AT H" 100 SYSTEM ---------- Figure 5: MOVIT.BAS 1 'MOVIT.BAS 10 ON ERROR GOTO 500 20 OPEN "com1:1200,N,8,1" AS #1 30 PRINT #1,"Be sure your terminal is echoing";CHR$(10) 40 PRINT #1,"what you type. Adjust it now.";CHR$(10) 50 PRINT #1,"When you can see what you type,";CHR$(10) 60 PRINT #1,"hit the enter or return key.";CHR$(10) 70 PRINT #1,TRASH$ 80 PRINT #1,"Be careful!";CHR$(10) 90 PRINT #1,"If you specify an invalid filespec,":CHR$(10) 100 PRINT #1,"or commit some other error,";CHR$(10) 110 PRINT #1,"you'll be dropped back to DOS,";CHR$(10) 120 PRINT #1,"and you'll have to try me again.";CHR$(10) 130 PRINT #1,"Now, will you send (S) a file to me";CHR$(10) 140 PRINT #1,"or receive (R) one from me?";CHR$(10) 150 INPUT #1,R$ 160 IF LEFT$(R$,1)="S" OR LEFT$(R$,1)="s" THEN 200 170 IF LEFT$(R$,1)="R" OR LEFT$(R$,1)="r" THEN 400 180 SYSTEM 190 'Downloading module 200 PRINT #1,"What should I call it?";CHR$(10) 210 INPUT #1,FIL$ 220 V=INSTR(FIL$," "):IF V<>0 THEN PRINT #1,"Illegal filename. Try again.";CHR$(10):GOTO 200 230 PRINT #1,CHR$(10):PRINT #1,"Waiting ....";CHR$(10):JUNK=LOC(1) 240 OPEN FIL$ FOR APPEND AS #2 250 FOR I=1 TO 30000 260 IF LOC(1)>JUNK+1 THEN 280 270 NEXT:SYSTEM 280 PRINT #1,"Receiving ....";CHR$(10) 290 A$=INPUT$(LOC(1)-JUNK,#1):PRINT #2,A$; 300 IF LOC(1)>0 THEN A$=INPUT$(LOC(1),#1):PRINT #2,A$;:FLAG=0:GOTO 300 310 FLAG=FLAG+1:IF FLAG<100 THEN 300 ELSE 320 320 CLOSE #2:PRINT #1,"File received";CHR$(10):SYSTEM 390 'Uploading module 400 PRINT #1,"What file would you like to receive?";CHR$(10) 410 INPUT #1,FIL$ 420 PRINT #1,CHR$(10):PRINT #1,"Set up to receive:";CHR$(10) 430 PRINT #1,"Transmission begins shortly ....";CHR$(10) 440 OPEN FIL$ FOR INPUT AS #2 450 FOR I=1 TO 25000:NEXT 460 IF EOF(2) THEN CLOSE #2:GOTO 490 470 PRINT #1,INPUT$(1,#2); 480 GOTO 460 490 FOR I=1 TO 20000:NEXT 500 SYSTEM ---------- If you've got two modems, an easy way to make the connection is to hook them up directly. With the Radio Shack Model 100, you just plug the modem cable's modular phone jack into the matching receptacle on the PC's modem. Or you can connect two standard modems with one modular phone cable. This method will require a couple of extra steps to initialize the PC's modem. After you've initialized the PC's COM port, enter: TYPE CON>COM1 AT A and hit Ctrl-Z and the Enter key. The modem should produce its answer tone, and you'll have about half a minute to make the connection with the other machine. Then be sure to reinitialize the PC's COM port; it's guaranteed to have garbage in it. ----------------------------------------------------------------- Poor Man's MODE (PC Magazine Vol 4 No 15 July 23, 1985 User-to-User) While the DOS MODE command performs a variety of I/O functions, many readers probably use it only to select video modes. It's possible to bypass MODE.COM and do this directly by using the SCREEN.COM program below, which speeds things up and saves 5K of space on disk. Once you've entered the program using DEBUG, simply use the command SCREEN n, substituting a number from 0 to 3 in space of n. Here are the new SCREEN n values along with their old MODE n equivalents: New SCREEN n Old MODE.COM n 0 BW40 (or 40) 1 CO40 2 B@80 (or 80) 3 CO80 Editor's Note: This does the job, but MODE.COM cones in handy elsewhere and at 5K isn't a space hog, especially on a hard disk. But if you're tight for space on a floppy, or if you want to give away or sell a disk and don't want to put IBM's copyrighted MODE.COM on it, this is for you. - - - - - SCREEN.COM: A>debug -n screen.com -a xxxx:0100 xor ax,ax xxxx:0102 mov bx,0081 xxxx:0105 cmp byte ptr [bx],20 xxxx:0108 jnz 010d xxxx:010A inc bx xxxx:010B jmp 0105 xxxx:010D mov al,[bx] xxxx:010F cmp al,33 xxxx:0111 ja 0117 xxxx:0113 cmp al,2f xxxx:0115 ja 0119 xxxx:0117 mov al,33 xxxx:0119 sub al,30 xxxx:011B int 10 xxxx:011D int 20 xxxx:011F -rcx CX 0000 :lf -w Writing 001F bytes -q