Msg: 6823 *Conference*
10-09-96 20:50:35
From: RON WIESEN
To : BILL ADAMS
Subj: REPLY TO MSG #6817 (LAPTAP)
Welcome back Bill. Desklink is a Portable Disk Drive emulator. It does a fine job and handles all three Model T file types: BASIC, ASCII, and binary (.BA, .DO, and .CO). Desklink keeps these in unaltered form in one dedicated subdirectory of a drive in the PC. It may not be convenient to have all Model T files in one subdirectory. Luckily Desklink recognizes the signature of TS-DOS so if the Model T uses TS-DOS while Desklink operates at the other end of a nul-modem cable then file transfers can occur in subdirectories (mult-level) under the dedicated subdirectory. Note that with or without TS-DOS, there is only one dedicated subdirectory in the PC. In summary, Desklink handles all Model T file types and with TS-DOS allows subordinate directories under the dedicated subdirectory. You're mistaken about Win95. It has the DOS built-in command MODE. MODE merely configures a COM port but it doesn't invoke file transfer. Another command, such as COPY, is needed for file transfer through a COM port. So as long as the Model T file type is ASCII then you can still port files between the Model T and a PC via a nul-modem cable. Note that the Model T BASIC interpreter provides various commands to port the ASCII equivalent of it's tokenized BASIC programs through the COM port. All you need at the PC end is a means to port ASCII files via one of its COM ports. The file attached here contains generic means which I keep on diskettes along with other bread and butter items I rely on for use in "foreign" PCs that my various clients own. With such means you can transfer ASCII and the ASCII equivalent of BASIC, but not binary (.CO) files. Here's the dope on porting a BASIC program to the PC. Recall that Model T BASIC has an ASCII option to SAVE a program in ASCII form rather than in tokenized BASIC form. Where device COM is the destination of SAVE, BASIC implicitly uses the ASCII option. Where a RAM file name is the destination of SAVE, BASIC lets you explicitly give the ASCII option. From BASIC it works as follows. First a program source is needed: this means that either a .BA file in memory is "current" (evidenced by * next a .BA file name listed by Files), or merely the presence of numbered program line statements of the "unnamed" nature. Next the ASCII option is used implicitly or explicitly. For example of the implicit ASCII option, SAVE"COM:88N1E exports program statements in ASCII to the COM port - you're done, the BASIC program is ported to the PC. For example of the explicit ASCII option, SAVE"ABC.DO",A creates an ASCII equivalent file named ABC.DO in memory - to port it to the PC you then exit BASIC (MENU), invoke TELCOM and use [F4](Term) followed by [F3](Up) no Width, [F8](Bye) Y, and [F8](Menu). I dislike this method because it takes more time and it consumes memory for an ASCII file in RAM (ABC.DO) which eventually I must "Kill". Here's the dope on porting a BASIC program to the Model T. Say ABC.DO is an ASCII eqivalent file of a BASIC program. ABC.DO can be ported back into BASIC as numbered programs lines of the "unnamed" nature with either LOAD"COM:48N1E or with RUN"COM:48N1E - you're done, the BASIC program is ported to the Model T. Of course you can port ABC.DO back in two steps: TELCOM [F4](Term) followed by [F2](Down) ABC, another [F2](Down) to end the download, [F8](Bye) Y, and then [F8](Menu) to exit TELCOM, invoke BASIC and use NEW followed by MERGE"ABC (where no ABC.BA exists, elsewise use MERGE"ABC.DO). I dislike this method because it takes more time and it consumes memory for an ASCII file in RAM (ABC.DO) which eventually I must "Kill". Once it's ported back, the program can be subsequently named and tokenized to a BASIC file type by SAVE"ABC which creates ABC.BA in memory, assuming that name doesn't exist. In the attached file (BATS) are two batch files which are the means I use often to port ASCII files between a Model T and a PC. They are batch files, hence they operate as external commands for DOS-based invocation. Under Win95 you can make a "shortcut" that links a batch file. Personally I don't bother with shortcuts but just invoke the DOS command prompt from Win95 and then invoke the batch files as needed. I name these batch files as shown below so that DOS command D and U respectively Download and Upload from the perspective of the Model T: . D.BAT downloads to Model T laptop (PC out to one of its COM ports) . U.BAT uploads from Model T laptop (PC in from one of its COM ports) PC port COM1 is assumed - you can edit U.BAT and D.BAT if another COM port is preferred. Transmission speed is implicit per default, but can be explicitly given as an optional command argument. The default speed of D.BAT is 600 baud for maximum the Model T can handle in regard to ASCII equivalent of BASIC. The default speed of U.BAT is 9600 baud consistant with limit COM ports of older PCs. All statements that begin with REM act as ignored REMarks but they provide the logic to change the default speeds to 19200 baud - just "cut" each "REM " from its logic line and "paste" the "REM " at the front of each subsequent line. In other words, move the REMs. Due to suppression of control characters by the Club 100 BBS, a Bell character which is in each batch file doesn't appear within the enclosed BATS file. The Bell character belongs right after "ECHO " in the second to last ECHO statement of each batch file. Bell is ASCII code 007. If you know how to restore the Bell character, fine - it gives a beep on the PC at the end of a file transfer. You can live without the Bell and watch for the " ended" message on the PC screen, rather than listen for the beep. I find beep helpful on long-time transfers. Because BEEP isn't a primitive every version of DOS (I must live with various versions), I instead used "ECHO *" which is generic. Here's an upload session that uses U.BAT to "move" (i.e., save/kill) BASIC program PROG.BA from the Model T to the PC where it's retained as file PROG__BA.100. -- Model 100 -- | ------ PC ------ BASIC TRS-80 Model 1.. ... ... Bytes free Ok LOAD"PROG Ok C:>U PROG__BA.100 Begin 9600 baud upload from laptop computer. Laptop must send End-Of-File (ctrl Z) to end this upload. SAVE"COM:88N1E (beep happens here) Ok Upload ended Volume in drive C .... Directory of C: PROG__BA 100 size mm-dd-yy hh:mm . . C:> NEW Ok KILL"PROG.BA Ok Here's a download session that uses D.BAT to load file PROG__BA.100 from the PC to the Model T where it's retained as BASIC program PROG.BA. -- Model 100 -- | ------ PC ------ BASIC TRS-80 Model 1.. ... ... Bytes free Ok NEW Ok LOAD"COM:48N1E C:>D PROG__BA.100 Begin 600 baud download to laptop computer. (beep happens here) Ok Download ended SAVE"PROG C:> Ok A few fine points about End-Of-File are handy to know. U.BAT appends an EOF to the file in the PC via the COPY COM1:+NUL %1 statement. The +NUL is the active phrase. D.BAT includes an EOF in the download, in cases where the file in the PC contains an EOF, via the COPY /B %1 COM1 statement. The /B switch is the active phrase. So much for U.BAT and D.BAT and what happens for files in the PC. For the Model T, the lack of or the appearance of an EOF during COM port input matters for BASIC and for TEXT. It matters not to TELCOM; TELCOM [F2](Load) ignores any EOF. For BASIC (LOAD or RUN) or for TEXT [F2](Load), the appearance of an EOF terminates transfer. If an EOF is not present, BASIC and TEXT continue COM port input - you must use CTRL+BREAK to terminate the transfer. *Enclosed File: BATS