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