home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
World of Ham Radio 1997
/
WOHR97_AmSoft_(1997-02-01).iso
/
packet
/
intrflex
/
amsoft.iii
next >
Wrap
Text File
|
1997-02-01
|
39KB
|
889 lines
__________________________________________________________________________
THE VERSION 9 SOFTWARE NOW INCLUDES SUPPORT FOR THE AMSOFT CALLSIGN CD-ROM
__________________________________________________________________________
VERSION 9 NEW FEATURES
Excerpt from "Performance Software" -- GOLD Software User Manual
Copyright (C)1993,94 by InterFlex Systems Design Corporation
All Rights Reserved
Quick Summary:
ALL For all users, GOLD (Pk, Ka, dsp, etc) adds the ability
for you to setup your station as a callbook server,
conference bridge, general file/information server, as
well as support for ANSI pics, restartable file
transfers, and more.
AEA Ver 9 supports AEA's version 7 ROM additions, GUSERS,
MYGATE and ARXTOR. AEA's rom for the PK-900 and dsp-2232
has a number of other changes that have fixed the pactor
changeover bug.
KAM Ver 9 supports G-TOR, the new mode from Kantronics that
is about 4 times faster than Pactor, and about twice
that of Clover, based on may on-the-air tests. The KAM
version 7 rom also allows more NUMNODES (KaNode
connects) -- well beyond the original 4 max. Lower the
PBBS size, and raise NUMNODES. Ver 9 also displays ARQ
link status information including Huffman compressed
frame, link speed, error condition, etc.
G-TOR tests were conducted by W0XI, WK5M (Phil Anderson,
Karl Medcalf, both of Kantronics) and WA4EGT (Jeff
Towle, InterFlex systems), transferring a 9718 byte file
using G-TOR and Pactor. The file was transferred in each
mode, under the same band conditions. The test was
repeated over 100 times during the next two months.
G-TOR was faster than Pactor in EVERY case, and averaged
about 3-times faster. InterFlex Systems program, KaGOLD
w/Pactor fully supports G-TOR mode, as well as Pactor,
Amtor, RTTY, Morse, split screen, multi-connect, ANSI
graphics, command files, conference mode, and much more.
VERSION NUMBERS -- ALL PROGRAMS NOW VERSION 9
Starting with the 1994 release of PkGOLD and KaGOLD, version
numbers are now consistent across different GOLD programs. This
is a result of bringing all versions up to the same set of
features.
Version 9 represents a significant departure from the earlier
versions of GOLD software. Commands from remote stations are
now allowed, two screen modes are supported for every session- -
the normal text character screen and a new ANSI graphic screen
-- direct interface to callsign databases (SAM, Buckmaster, QRZ)
is supported, restartable file transfers, and improved operation
in Windows and other multi- tasking environments, and support
for CW announcements through ad-lib type sound cards.
As you read the rest of this description, look for more about
each of the following subjects:
o Callbook Support for four (4) CD based systems, and the
SAM disk-based callbook. Users can lookup callsign data,
the program does lookups automatically, and remote users
can request callsign data making the station a callbook
server (if remote commands are enabled and the
appropriate callbook cmd file exists). Callbooks
supported include Amsoft CD, Buckmaster CD, QRZ CD, SAM
CD, and SAM Disk based callbook.
o ANSI Graphics supported on all sessions simultaneously.
Pics are saved automatically if desired, and the program
can "flip" to graphics mode automatically. No other
program offers simultaneous, multiple ANSI picture
receiving.
o Restartable YAPP and GOLD transfers. YAPP-C is
supported, and restartable transfers are done
automatically, as the program determines if the remote
station supports these features. Partially complete
files have a text header that makes it easy to determine
which files are only partially received.
o Conferences can be started remotely, allowing your
station to be a conference server. Users can switch
conferences, start new conferences, and leave the
conference and remain connected if desired. They can
also send messages directly to other stations in the
same or different conference.
o Remote commands, including user defined commands in CMD
files. This allows you to create a file server, ANSI
pic server, radio mods server and more. The ability to
create commands that remote users can issue opens a
whole new set of outlets for for your programming
creativity.
o Morse messages can be directed to an Ad-Lib compatible
sound card. Also, CW pitch can be set by the user, both
user options are in the SETUP area.
o Network View lines now show headers in low-video, and
text in high-video, making it easier to distinguish
headers from text. This is done automatically.
Callbook Support
If you have AmSoft, BuckMaster, QRZ, or SAM (disk or CD-based)
callbook, the program will access these automatically, as well
as allow other users to lookup callsign data through your
system. To activate the support, use [Alt-S], then Setup, then
Callbook.
SAM Callbook
First, find and load the SAMAPI (SAM Application Programmers
Interface). The SAM callbook access requires this SAMAPI
program. It is included with SAM, possibly in a subdirectory of
one of the SAM disks. To load SAMAPI from the GOLD directory
you might type:
C:\SAM\SAMAPI C:\SAM For Disk based Version
C:\SAM\SAMAPICD S:\SAMCDDAT C:\SAM For CD ROM version
If this does not load SAMAPI, check your SAM disks for SAMAPI
and copy it to the SAM subdirectory. The second parameter in
this command is the "Path" to the actual dataset. If you wish,
make up a batch file to run GOLD and put this command before the
KAGOLD or PKGOLD command. To unload SAMAPI from memory:
C:\SAM\SAMAPI /R (or /UNLOAD depending on version of SAM)
While in SETUP (see above) select SAM as your callbook type if
this is the only callbook you plan to use. If you also have CD
ROM callbooks, indicate that you have both SAM and CD callbooks.
The program will search for callbook data in the following
order:
CD based calldata first, then the
SAMAPI or SAMAPICD.
CD Callbook -- Buckmaster, AmSoft and QRZ In Setup, select CD
ROM callbook data. If you also have SAM, select CD ROM and SAM.
The search for callbooks is described above. The reason we don't
choose the and by default is to save the time required to check
for the SAMAPI if it will never be on your system. We use the
index files directly from the QRZ disk, but on the Buckmaster
disk, we create a unique index file for each version of
Buckmaster. This may take up to 10 minutes the first time you
use the Buckmaster option.
Local use of the Callbook
You can access the callbook using [Alt-I] then enter a callsign.
You can also send callbook data to a session using:
SENDCALL <callsign> [more callsigns] [F10]
This causes the program to access the callbook for each callsign
in the list (one or more) and produce a "mailing label" format
for each callsign, sending it to the current session (packet,
amtor, pactor, etc).
Last, if you are using [Alt-E] to edit the logbook entry for the
callsign showing in the banner (a connected station), you can
then use [F9] to look up the callsign in your on-line callbook.
Callbook Server -- Remote Access
If you have enabled remote commands on the [Alt-Z] menu, a
remote user can type //CALL WA4EGT or even a log list of
callsigns separated by spaces or commas, to request callbook
information from your station.
How does this work? The answer is simple (we think it is
anyway). CALL is the name of a CMD file. Here is what CALL.CMD
contains:
* Contents of CALL.CMD (this is a comment)
CALLBOOK @0
* Use zero not the letter O
The command SENDCALL <callsign list> is a command in GOLD just
like other TNC commands, and can be entered in a CMD file as
above. The @0 (commercial "AT" sign followed by zero) is filled
in with the string of characters supplied by the user who issued
the CALL command.
This means you can change the //CALL command to some other
command, like //LOOKUP <callsign> if you wish. All you need to
do is change the name of the file call.cmd to lookup.cmd and
inform users that the new command name is lookup.
Changing the names of this and other CMD files may introduce a
lot of confusion.
Conference Bridge Server
If you have enabled remote commands in the [Alt-Z] menu, another
station can connect to your station and join a conference
without your assistance. This means that your station can be an
unattended conference bridge or conference server. A remote user
can connect and issue the following commands:
//WHO To list stations & conferences
//JOIN A To Join or create conference A
//OFF Exit conference, remain connected
//BYE Exit conference and disconnect
//[call] text Send text msg to [call]
The last command allows a conferenced station to send a message
to another conferenced station directly. If N6WIK and WA4EGT are
both connected, the following:
//N6WIK Let's start Conf C, type //JOIN C
would send the message to N6WIK only.
Users can log //OFF a conference, ask //WHO else is connected,
and create a new conference with //JOIN C or any letter up to J.
Remote CMD files
Users who connect to your station can issue 1 to 8 letter
commands that you create through the use of command files. A
command file is a file in the directory cmdfiles off the GOLD
directory. It must have a cmd extension, and can contain any of
the following kinds of lines:
Comments: A line beginning with an asterisk (*) is a
comment and is ignored.
Message: A line beginning with a quote (") is sent
to the station who issued the command
Commands: TNC commands, or other "pseudo" commands that
can also be run from command line with [F10]
Most of the pseudo commands would not be issued directly by you,
but would be put into CMD files for use in developing commands
that remote users will find helpful.
CMD file layout
In the CMDFILES directory (which must be a subdirectory of the
GOLD directory) you will create one or more files with .CMD
extensions. A simple collection of 4 files might be as follows:
CMD File #1
* Help.cmd file contents (used to list
other commands)
" ?NAME, you may use any of the following commands
" note: some may provide additional help
"
" //WHO To list who else is connected
" //CALL ?MYCALL Information about ?MYCALL
" //CALL ?CALL Callbook information about yourself
" //HFPARMS Help about HF-Packet Parameters
" //LISTMODS List of Radio Modification files
" << END OF HELP >>
CMD File #2
* LISTMODS.CMD file
" ?NAME, here is a list of MOD files
SENDDIR S:\MODS\*.MOD
" Note: Use //GETMOD <filename> to get a mod file
" << END OF LISTMODS >>
CMD File #3
* GETMOD.CMD file
SENDTEXT S:\MODS\(@0)
" << END OF RADIO MOD >>
CMD File #4
* Call.CMD file -- returns callsign data
SENDCALL @0
These examples show a number of features built into the CMD file
processing. First, the use of the comment line to show the file
name. You can document your CMD files using the asterisk (*)
comment line, and it is a good idea to make liberal use of
comments.
The use of the Quoted text line, the (") quote mark signals GOLD
to send the text to the remote user. A good way to tell them
what is coming, and notice at the end of each file, we've put a
line to clearly indicate to the user that the command file is
finished.
The senddir command (described below) sends a directory, and can
use "wildcards" for the directory mask, just like DOS. This
usage gives a directory of all files in the S: drive MODS
directory.
The sendtext command is used to send a prepared text file, in
this case a radio modification file that resides on drive S:
(the QRZ CD ROM for example). The (@0) is a special case of the
user supplied substitution string. It removes any path
information from the user parameter, leaving only a file name
(if any).
The last file is the CALL command file, and contains only the
pseudo command SENDCALL followed by the user parameter string.
It will perform the Callsign lookup function on the string (one
or more callsigns) supplied by the remote user.
Remote user parameters
When a user sends a // command, the program looks after the //
for a valid CMD file name. If a match is found, the line is
processed as a command. The remote user can include a parameter,
like a file name or directory name, or both. In the CALL.CMD
file example, the parameter @0 is used.
If multiple parameters (words separated by spaces) are passed to
the CMD file processor, you can use @1 @2 @3 etc. to identify
each word separately, which is useful for DOS batch file
processing.
A CMD file can use the EXECDOS command to pass user parameters
to a batch file as follows:
EXECDOS DOSPROG @0
When the CMD file processor sees this, the DOS shell is invoked,
the program or batch file called DOSPROG is run, and the
parameter @0 is passed to the spawned process as a single
parameter string, as though typed at the DOS command prompt.
Note: The "at" sign (@) is similar to the percent (%) sign
used in DOS Batch files. The @0 is the entire user string,
and the @1 through @9 are the individual words (parsed out of
the string) in the @0 string.
CMD file functions
Senddir [path] [filespec]
This cmd file function will send the directory of the default
upload path if no parameters are passed to it. If you include a
path, the directory of the files in that path are sent to the
user connected that issued a CMD filename with a SENDDIR.
Examples: Senddir S:\MODS\*.MOD
Senddir S:\@1
The first example simply sends a directory of all files matching
the *.MOD filespec. Similar to the DOS directory command and how
it proc esses this kind of filespec (file specification).
The second Senddir takes the first parameter (or the only one)
provided by the remote user and substitutes it for the @1. A
remote user typing a command followed by mods\IC*.* will get
all files that match S:\mods\IC*.* due to the substitution that
follows the S:\ in the above example.
Sendyapp [path] [filename]
This command sends a filename using YAPP protocol. The file name
can be provided as "hard coded" or it can use the substituted
parameter approach, similar to the SENDDIR above.
Examples: Sendyapp S:\mods\ft990.mod
Sendyapp s:\@1
The first example sends one file, that's it! No options. The
second example allows the remote user to contribute a path and
filename to request.
Sendgold [path] [filename]
This is a variant of binary file transfer using YAPP, only in
this example, the transfer protocol is the GOLD protocol, which
allows you and the remote station to continue conversing on the
session/stream. This is only honored if the remote station is
identified as a GOLD user by the automatic exchange process.
Sendbin [path] [filename]
This method is like SENDYAPP and SENDGOLD with another layer of
automation -- it figures out whether to use YAPP or GOLD
protocol depending on whether the remote station is a GOLD user
or not. If you want to send using GOLD protocol to any GOLD
user, and to use YAPP with all other stations, then sendbin is
the right command.
Sendtext [path] [filename]
This sends a file as plain ascii, no special protocol (like yapp
or gold) and cannot be used to send binary files, like programs
that have .COM or .EXE, or .ZIP extensions (to name a few). Use
this method to send a MOD (radio modification) or some other
file of text data.
SendRaw [path] [filename]
Some files, in particular ANSI graphic or "pic" files, and
specially formatted text files such as M.A.R.S. messages created
with programs that produce multiple Linefeeds rather than
multiple CRLF sequences, must be sent with the Raw send
capability of PK and KAGOLD. This command can be used in CMD
files that need to use this raw send capability. It is this
command, coupled with SendText and SendDir that can make your
station into an ANSI Picture "Server" and allow remote users to
receive ANSI graphics in an unattended mode.
Recvyapp
This command puts the current session into a YAPP receive mode.
It will be ready for a yapp transfer from the other station. It
does not require any parameters, and the files will be put into
the default download directory that is specified as the
"download path" in the setup area (under file transfers).
There is no need for a "recvgold" because this is handled
automatically when GOLD gets a "here comes a file" type packet.
SENDCALL [callsign or list of callsigns or @0]
This was described above in the example for the //call
<callsign> command file. It will access whatever callbook it can
find and produce the callbook information, sending it to the
remote station. The use of @0 means the entire line of text
(several callsigns) will be passed to the SENDCALL routine, with
several callsign lookups. You can use this command to send
calldata to a friend: try SENDCALL W1AW [F10].
Conference Commands
The following commands are specific to the conference only, and
are built-in, internal commands read directly by the software
and processed immediately. While they look like the other
commands, using the //cmdname format, they are unique to the
conference processing.
//who
Display a list of Who is connected, and what conferences
are in progress, if any, with letter identifiers. You can
JOIN any conference. Outside of the conference, a user
typing //who can access a WHO.CMD file to perform a similar
function. The file might look as follows:
*who.cmd contents (or name it USERS.CMD)
"At ?Time SENDWHO
Understand that the //who command issued by a station in
conference will be processed by the internal "who" command
parser, and will list only the connected stations. Outside
of the conference, the same //who command is processed by
the CMD file processor, using the SENDWHO tnc pseudo
command. You can issue SENDWHO locally, as you can with
any TNC or Pseudo-TNC command, type it and push [F10].
//name [yourname]
A conference member may fill in his/her name, or change
his/her name that is associated with the callsign.
//Join <conference letter>
This causes the station to be "joined" into a conference,
or to create a conference with the letter chosen.
//<callsign> <text to send to callsign>
Send a string of text directory to the callsign typed out.
Callsign must include the station's SSID if that is how it
appears in the conference.
//Off
Exit from the conference, but remain connected to the
station. Useful to issue other remote commands, get files,
etc. Here is another conference command that can have a
counterpart outside of the conference. You could create an
OFF.CMD file, or LOGOFF.CMD file with the following format:
* OFF or LOGOFF.CMD file layout
"73 from ?MYCALL -- OFF at ?DATE ?TIME
DISC
//Bye
Exit from conference, and disconnect. Again, you could
create a BYD.CMD with a DISC command in it (like the OFF
command) for use outside the conference.
Advanced CMD file examples
You can create some interesting CMD files, and with some
planning, make your station into a resource for radio mods,
information files, propagation forecasts, just about any
collection of information you wish.
Here are a few CMD files with a brief explanation of what each
does. Use them as a prototype for making your own CMD files.
* This sends a list of my brg files (first line -- a comment)
"Here is a list of my BRG files:
execdos dir/w brgfiles\*.brg > upload\brgfiles.lst
sendtext brgfiles.lst
"<< END OF LIST >>
"Use //GETBRG filename to have a file sent back to you
The second line uses the Quote command to send the text Here is
a list of my BRG files to the remote user. The next line is more
interesting. It shells to DOS with EXECDOS, does a DOS
directory (with /W meaning wide) of all files in the BRGFILES
subdirectory with the BRG extension, redirecting the output of
the DIR command to the upload directory, to a file called
BRGFILES.LST. Finally, the SENDTEXT command is used to send the
list of files.
A couple of things to note: First, all directory references
begin with the GOLD directory as the default directory. The DIR
command, if issued from the GOLD directory, need only refer to
BRGFILES subdirectory to cause the output to be redirected
there. It is not necessary to fully specify the directory name.
That means, for example, you can write these relatively benign,
generic CMD files that will work on ANY drive letter, and can be
used no matter what name was given to the main GOLD directory.
Second, this example demonstrates the power of CMD files coupled
with the EXECDOS command.
Here is what the GETBRG.CMD file might look like, to allow users
to request one of your BRG files.
* GETBRG CMD file, used to get a BRG file
"Here is a copy of "@0"
sendtext brgfiles\(@0)
Radio Modifications "server" example Here is group of files that
provides radio modifications lists.
*Helpmod.cmd file -- explains how to use MODS list
"To get a list of MODS, or a partial listing type
"//LISTMODS for all MODS
"//LISTMODS FT all mods starting with FT
"//LISTMODS TS4 TS430, TS440, TS450, etc
This first HELPMOD.CMD file is straightforward. It uses the
quote character to send help information to the remote station
that typed the command //HELPMOD.
This next file does the LISTMODS command from a remote user.
* listmods.CMD, shows mods from QRZ dir
senddir s:\mods\@0*.mod
"Use //GETMOD <Modfilename> to get file
Line 1 is a comment line, it begins with an asterisk (*). Line 2
sends a directory from the S:\MODS directory using the remote
request, and adding the asterisk followed by .MOD. If the user
were to type //GETMOD FT the @0*.MOD would become FT*.MOD which
will give a directory of all files beginning with FT and having
a .MOD extension.
The last line tells the user how to actually retrieve one of the
mod files. The getmod.cmd file might look like this:
* Getmod.cmd file, sends the mod requested
//sendtext s:\mods\@0
"<<end of mod file>>
In this example, the user would have to type the exact filename,
including the .mod extension.
Calling a batch file example
This last CMD file example shows how to call a batch file using
EXECDOS and how to refer to the GOLD directory itself. The
objective here is to call the Buckmaster ICALL program and
request the extra station information that comes along when you
use the /S option (supported in the BuckMaster Callbook CD).
The user will be told to type //LOCATE <callsign>, and
LOCATE.CMD is the file we need to create. In addition, a batch
file is needed that does the actual work of calling ICALL once
the program shells to DOS and gives control to the batch file.
Here is the listing of LOCATE.CMD:
* LOCATE.CMD for locating (Lat/Lon) by Callsign
* Usage:
* //LOCATE <callsign list>
"Processing call(s)....
execdos ic_loc @0
* This next line is tricky, the only way to send from the GOLD
* directory itself. This is a DOS issue, where dot (.) is the
* current directory. The backslash is needed to separate the
* dot from the filename.
sendtext .\location.dat
"<< END OF LIST >>
This file has a lot of comments in it, a good idea when writing
your own CMD files that others may use, or that you will
maintain. The two highlighted lines do the work. First, the
execdos command calls ic_loc.bat, a file located in the main
GOLD directory. It passes the parameter(s) that were typed by
the user by referring to the @0. The IC_LOC.BAT file will be
shown in a moment.
The next highlighted command uses the DOS syntax ".\" which is
way to refer to the default directory. Without a directory
specified like this, GOLD reverts to the default directory for
sending files, namely the upload directory. We want to perform
the callsign and station information lookup in the GOLD
directory. Here is what IC_LOC.BAT has in it:
@echo off
rem Put this BAT file into the GOLD directory
IF %1x==x goto Nocall
S:\ICALL S: %1 /S > location.dat
edlin location.dat < fixdata.cmd > nul
GOTO ENDBAT
:NOCALL
ECHO Need a callsign to lookup! > location.dat
:ENDBAT
This batch file takes the commands from the execdos command in
the locate.cmd file that were typed by the remote user. The
callsigns requested have traveled through the network, to GOLD,
to the CMD file in the @0, to the batch file and DOS sees the
parameter as %1.
The only twists here the redirection of the output of ICALL to
location.dat, and the editing of location.dat using the DOS line
editing program EDLIN. We pass EDLIN a filename to edit, and
tell it what to do in the file FIXDATA.CMD. The confusion about
CMD files here is evident, but this CMD file has commands to the
EDLIN editor.
Here is what is in FIXDATA.CMD:
1,3d
e
These EDLIN commands simply delete lines 1 to 3 of the resulting
buckmaster icall output, and then exit the editor. You can learn
more about using the EDLIN editor, and passing commands to it by
referring to your DOS manuals. The idea of presenting these
examples is to give you an idea of the power of the the new GOLD
command file processing, especially when combined with batch
files.
ANSI Pics
KaGOLD and PkGOLD are the only programs available that can
capture and display multiple ANSI sequences simultaneously,
capture them automatically, and on dual port units, capture ANSI
graphics on both ports simultaneously. The only HF mode that is
capable of supporting ANSI, without causing errors, is PACTOR.
American National Standards Institute defines several "escape
sequences" that involve cursor positioning, color setting,
screen clearing, etc., and with the GOLD ANSI capabilities, you
can view these ANSI "Picture" or "Graphic" files.
An ANSI sequence is easily recognized by its use of the [ESC]
character, which prints as a left arrow, and the opening square
bracket. If you see in some text, this is very likely the
beginning of an "escape sequence" that contains cursor position,
color, or other information for an ANSI interpreter.
When an ANSI "picture" is received
Every "session" has its own memory buffer, allocated and
deallocated automatically. When an ANSI picture is detected, a
second buffer is created for the session, and it becomes the
scratch-pad or canvass to draw the resulting ANSI picture. This
buffer is only created when the software detects the need for
it. Therefore, as you read the next few sections about ANSI
pictures, realize that [Alt-G] the keystroke used to "flip" to
and from the graphic will only work if there is or was a graphic
for this session. The purpose here is to save computer memory,
another aspect of dynamic memory management that is built into
GOLD software. If you use [Alt-G] and nothing happens, then no
ANSI picture is available for display on the active session.
Manual Display [Alt-G]
As explained above, the ANSI screen is not always available. You
can use [Alt-G] to see the ANSI graphic only if one exists.
[Alt-G] is a toggle, switching between the graphic (if any) and
the "normal" text screen.
Auto-Capture
By default, ANSI "pictures" are captured into the ANSFILES
directory. Automatically captured "pictures" are given file
names as follows:
GOLDnnnn.ANS
where nnnn is a number from 0001 to 9999. If you collect more
than 9999 pictures, the file will be named GOLnnnnn.ANS,
dropping the "D" in GOLD and using 5 digits to express the
picture number. Hopefully, you will review the files
occasionally, and rename them to something more reasonable, like
BART.ANS, or TRAIN.ANS. You can turn this feature OFF if you
wish, in the Setup area under Screen Settings.
Auto-Flip
The program defaults to "flipping" to the graphics screen when
incoming ANSI sequences are detected. You can change this to OFF
in the Screen Settings area under Setup (as above). When the
screen flips to graphics, you can always use [Alt-G] to return
to the regular session screen and see the ANSI sequences in
their raw, uninterpreted form. If you turn Auto- Flip OFF, you
will always have to use [Alt-G] to see ANSI pics. The ON
setting is probably the most useful, but some users may want to
avoid flipping to ansi graphics and do everything manually.
Reviewing ANSI pics
A program called SHOW.EXE may be in the ANSFILES subdirectory.
It is also available on the InterFlex Systems BBS. Use this
program to review ANSI graphics by typing the following command:
SHOW sample.ans (or whatever the filename is)
A second method is to have ANSI.SYS loaded from your CONFIG.SYS
file. If ANSI.SYS is active, all you need to do is TYPE the
file and let the ANSI interpreter display the graphic. ANSI
graphics with animation do not show very well, if at all, using
this approach, but it is a quick way to review pictures. The
command would be:
TYPE sample.ans (assuming this file exists)
Other programs can be used to edit and create your own ANSI
pics.
Creating ANSI Pics
There is at least one program available on the InterFlex Systems
BBS that can be used to create ANSI "graphics" files. It is
TheDraw. You can download the zip file called TDRAW450.ZIP,
extract the files, and take a shot at creating your own ANSI
files.
Here is the most important caveat: when you write your files, or
save them, set the right margin, or maximum line length to 75,
or some length below 80 characters. Using 75 allows others to
copy/paste the ANSI sequences.
Restartable File Transfers
In Version 9, file transfers using a "protocol" like YAPP-C or
GOLD are restartable. Text files and raw send (for ANSI pics)
are "one way" type transfers and have no "protocol" and do not
always result in creating a file on the other user's system.
GOLD and YAPP do create files on the receiving station's
computer. If the transfer is stopped, or aborted, the partially
received file is saved with a special header that allows the
transfer to resume, or restart rather than start from the
beginning. This saves time.
GOLD protocol
On the [F6] transfer menu, sending or receiving files
automatically supports restartable transfers (see above). With
earlier versions of PkGOLD and KaGOLD, the restartable transfer
is not supported, but you will still be able to send and receive
files while connected to some earlier versions of PkGOLD and
KaGOLD.
YAPP-C protocol
The YAPP (yet another packet program) system for sending and
receiving files has been extended to YAPP-C, with and without
restarting. With PkGOLD and KaGOLD, this is entirely
transparent. If the remote station supports restarting, your
station will handle it automatically. If not, again the software
"knows" and handles things automatically. Just transfer files
with YAPP to a local BBS or other user, and if YAPP-C or
restartable YAPP is supported, your station will automatically
comply with the newer protocol.
Setting Alt-Messages
You can use the Setup menu, Alt-n message selection to alter
your one-line Alt-n messages (alt-0 through alt-9) or use a new
feature in this latest version, the setalt <n|p><0..9> text...
pseudo tnc commands. The syntax of this new command is the
setalt command, the alt-n message you want to change, and the
text string. The <n|p> means "Non-packet OR packet" and the
number 0 through 9 must be included to identify which Alt-n
message to change.
In any of your TNC or CMD files, you can put one or more of
these new commands. You can also type the command from the
command line to change an alt-n message. For example:
setalt p5 My QTH is Laguna Niguel, CA [F10]
setalt n1 ?call de ?mycall [F10]
You can include any number of setalt pseudo commands in your tnc
or command (cmd) files. Be sure the strings do not exceed about
100 characters. Even better, do not exceed about 65 characters
so that you can read the entire line when you hit the Alt-n.
Hints for usage: Some users have suggested that we have a set of
Alt-n messages for each mode, not just packet and non-packet.
This new feature allows you to create a set for each of the non-
packet modes, and put them into a tnc file that also calls up
the mode. For example, an AMTOR.TNC file might contain several
setalt messages for usage in amtor. It might be good as well to
create a tnc file with a collection of default alt-n messages.
RESETALT.TNC would be a good name.
Special Connect BRG files
You can do some new things with connect files. If you have
enabled the sending of "connect.brg" when a station connects (do
this in the Setup menu, under Alt-n messages) you will have a
few new options for naming the files.
The program will look for any one of three files. First, a file
with the same name as the callsign of the connecting station.
Second, a file with the name "CO-xxx.brg" where "xxx" is the
name of the port (the name you give the port on dual-port tncs).
For example, create a short file called CO-HF.BRG and a larger
CO-VHF.BRG file. Then, when a station connects on HF, the HF
connect text file will be sent. This allows you to send short
files on HF, and longer files on VHF. Third, the program looks
for CONNECT.BRG, and sends it if it cannot find another file to
use.
If you create CO-HF.BRG, and K8TNK.BRG, and have the standard
CONNECT.BRG in the BRGFILES directory, here is what would be
sent under each condition:
K8TNK connects on either HF or VHF, send K8TNK.BRG
WA2VSM connects on HF, send CO-HF.BRG
WB8TKE connects on VHF, send CONNECT.BRG
Hints for usage: You can use the callsign.brg approach to leave
a message for another station. It will be sent every time the
station connects until you delete that file, but you may have a
message that is intended as a reminder for another station.
Changes from Prior Versions
In addition to the major changes explained in this chapter,
there are several minor adjustments that will improve the
operation of the program. For example, the logging system uses a
B-tree index rather than a hashing index. This is a technical
matter, but the new system is faster, and has much larger
capacity and is much faster. The monitor screen has been
modified to show information frames with a bright color
attribute, with headers in a dim or normal brightness. The
on-screen clock uses a different technology that improves
reliability of the program when operating in a multitasking
environment.
The technology for determining when to unkey the transmitter in
the non-packet modes has been beefed up, to assure that unkeying
occurs as quickly as possible when the buffer empties. The way
the program does overlays is improved, to be faster and more
reliable on systems that are slow to switch between real and
protected mode. The program handles more types of nodes,
including TEXNET which uses the commercial at sign (@) in
certain parts of the connect commands. Other changes to version
9 are the result of the months of beta testing that this program
has been through.
When other users ask what is new about Version 9, tell them the
major new additions, which are (1) Callbook support for 3 CD ROM
based systems, and SAM; (2) Support for ANSI graphics, on all
sessions, simultaneously; (3) Conference server mode, with
remote started, and changed conferences; (4) Remote command
files that are user defined and able to send textfiles,
directories, and start binary file transfers; and (5) File
transfers are now restartable with both YAPP-C, and GOLD
protocols supported. Some changes may be more useful than others
to certain users, but we hope that you find these additions fun
and easy to use.
<<END>>