BinkleyTerm Documentation
Addendum to BinkleyTerm Documentation
Changes and Additions
for BinkleyTerm Version 2.40
Copyright (C) 1990 Bit Bucket Software, Co.
INTRODUCTION
Rather than update the BinkleyTerm documentation as we have done
in the past, we are issuing this addendum file. It is important
that you read this file thoroughly, as some of the information
herein will supersede what is shown in the manual itself.
By issuing this addendum, the printed versions of the BinkleyTerm
manual now in circulation (and still available from Bit Bucket
Software) will continue to be current (except for this addendum).
The printed manuals were produced at great expense, and it has
taken us a great deal of time to recoup our expenses. We hope to
produce a printed manual again in the future, but for this
release, the BinkleyTerm Version 2.30 docs (printed or otherwise)
will remain current with this addendum.
The mailing address for Bit Bucket Software has changed. If you
wish to get ahold of us by mail for any reason, our address is:
Bit Bucket Software, Co.
P. O. Box 460398
Aurora, CO 80046
Please - do not write for technical support. Support is provided
EXCLUSIVELY through the international BINKLEY EchoMail
conference. When sending correspondence for other reasons,
please include a self-addressed stamped envelope for replies.
(Those persons not in the United States should enclose an
International Postal Reply Coupon.)
PRINTED MANUALS
As mentioned previously, printed BinkleyTerm manuals are still
available. Pricing covers the cost of printing, processing your
request, and mailing. The prices are as follows:
Within the United States:
$15.00 Manual Only
$25.00 Manual and Disk
Outside the United States:
$25.00 USD Manual Only
$35.00 USD Manual and Disk
All manuals will be delivered via regular mail.
----------------------------------
USER'S GUIDE CHANGES AND ADDITIONS
----------------------------------
---------
SECTION 3 Operation as an Automated Electronic Mailer
---------
Janus Mail Protocol
BinkleyTerm now features an experimental mail transfer
protocol called "Janus." It is a bi-directional, full-
duplex protocol, and generally requires a full-duplex modem
to work properly (USRobotics Courier HST modems, for
example, are not full-duplex and cannot use Janus
effectively). Under ideal conditions, Janus allows you to
transfer mail simultaneously in both directions with Zmodem-
like performance.
Due to the depth of the subject, Janus is covered completely
in its own section toward the end of the document.
Domain Support
BinkleyTerm now features support for "domain" addressing.
Due to the depth of the subject, domain addressing is
covered completely in its own section toward the end of this
document.
Assumptions
BinkleyTerm supports zone, net and domain assumption. If
you have more than one address and different zones, nets, or
domains are designated in the configuration file, then
BinkleyTerm will use whichever address is appropriate when
transacting mail.
For example, net assumption might work as follows. If I
have two addresses - 104/36 (primary address) and 1052/1
(secondary address) - and someone calls from net 1052, then
my system will identify itself at 1052/1. In all other
cases, my system will identify itself as 104/36 (since it's
my primary address). The purpose is that your system will
identify itself as the most appropriate address depending on
the address of the calling system.
File Requests
BinkleyTerm will no longer place calls for a stand-alone
.REQ file. In order for a call to be placed, a packet or
file attach of the proper flavor must also exist. As
always, a manual poll will also allow a call to be placed.
More Connect Messages
Support for the following connect messages has been added:
CONNECT 75 (Giving 1200/75 bps)
CONNECT 103 (Giving 300 bps)
CONNECT 12 (Giving 1200 bps)
CONNECT 212 (Giving 1200 bps)
-------------------------------------
REFERENCE GUIDE CHANGES AND ADDITIONS
-------------------------------------
---------
SECTION 1 Configuring BinkleyTerm
---------
CONFIGURATION FILE
Colors <brdr> <sett> <today> <pend> <act> <txfr> <rev> <popwin>
Identical as documented in the manual, except the addition
of two more parameters. The <rev> parameter designates the
reverse video color used in the Pending Outbound window to
mark the node you are calling. The <popwin> parameter
designates the color of pop-up windows (such as those
produced with the Alt-G and Alt-S commands in Unattended
Mode).
Flags <dir>
The directory name specified is used by BinkleyTerm to create
task identification files. The filename is TASK.# where # is
the task number. These files can be used to determine if any
given Binkley task is currently running. The file is created
whenever Binkley has carrier present and a mail session is
in progress.
FTS-0001
When used, this statement will force BinkleyTerm to use only
base FidoNet protocol (FTS-0001), effectively enabling the
equivalent of the following statements: NoWaZOO, NoResync,
NoSLO and NoSEAlink. Used mostly for debugging and testing
of FidoNet policy compliance; not for regular use.
JanusBaud
JanusOK
Controls whether Janus bi-directional protocol will be used
during WaZOO sessions. Please refer to the complete Janus
explanation later in this document.
KnownMaxBytes
See 'MaxBytes' for information.
LockBaud [<lock_rate>]
Works the same as what is documented in the manual, except
it now accepts an optional parameter. The <lock_rate>
parameter tells BinkleyTerm what baud rate at which locking
should occur. This is useful for modems that allow a
floating baud rate to a certain speed, then are locked at
higher connect rates.
Most ROM revisions of the USRobotics Courier HST 14.4k model
and the USRobotics Courier HST Dual Standard allow this type
of operation by setting the modem for &B0 which floats the
baud rate at 2400 bps or lower. Bit 7 (and perhaps Bit 6)
of the S27 register also need to be set appropriately.
TO LOCK AT 19200 AND FLOAT AT SLOW SPEEDS: Use the
'Baud 19200' and 'LockBaud 4800' statements in your
configuration file, and set the modem for &B0 and S27=128.
TO LOCK AT 38400 AND FLOAT AT SLOW SPEEDS: Use the
'Baud 38400' and 'LockBaud 4800' statements in your
configuration file, and set the modem for &B0 and S27=192.
MaxBytes
Together with the 'ProtMaxBytes' and 'KnownMaxBytes'
statements, you can control file requests by number of bytes
sent. These three statements work in the same manner as the
other file request limiting statements detailed in the
documentation. NOTE: There is a response file "Type 6"
response now, which indicates that the caller has exceeded
the byte limits.
NoResync
When used, this statement will tell BinkleyTerm not to allow
SEAlink Resync (an ability to restart failed SEAlink mail
sessions). Used mostly for debugging purposes; not for
regular use.
NoSEAlink
When used, this statement will tell BinkleyTerm not to allow
SEAlink mail sessions at all, including SEAlink extensions
to base FidoNet protocol (FTS-0007) and WaZOO/DietIFNA
sessions.
NoZedZap
When used, this statement will tell BinkleyTerm not to allow
ZedZap (Zmodem) transfers during a WaZOO session. It is
primarily intended to force BinkleyTerm to use DietIFNA mode
(SEAlink) during WaZOO sessions. Used mostly for debugging
purposes; not for regular use.
ProtMaxBytes
See 'MaxBytes' for information.
ScreenBlank [<method>]
Identical in function to what is documented in the manual,
but now accepts an optional parameter. The <method>
parameter may be "Key" or "Call" and tells BinkleyTerm which
method to use to "unblank" the display. "Key" tells it to
unblank upon a keypress (and is the default); "Call" tells
it to unblank when a call comes in or is placed.
TaskNumber <number>
This statement performs two functions for persons operating
in multi-processing or multi-line environments (through a
LAN or multi-tasker).
First, it designates a task number for the BinkleyTerm that
uses the configuration file that this statement appears
inside of. The <number> parameter must be greater than zero
(0).
Second, it tells BinkleyTerm to operate in "multi-processor
smart mode." If BinkleyTerm is transacting with a
particular system, it will create a "xxxxyyyy.BSY" file for
that node, named in the conventional packet form (xxxx = net
number in hex, yyyy = node number in hex). This file can
serve as a flag to other BinkleyTerm tasks, or to compatible
mail processing packages so that other tasks or processors
will not handle any mail for the particular node until the
".BSY" file is gone. Additionally, BinkleyTerm will not
send files to any node for which there is a ".BSY" file.
TermInit <modem_string>
Identical in structure to the 'Init' statement, this
statement provides a modem initialization string that
BinkleyTerm will use in Terminal Mode. The string will be
sent to the modem if BinkleyTerm is initialized in Terminal
Mode, or when switched to Terminal Mode from Unattended
Mode. The string will also be sent when an Alt-I command is
issued in Terminal Mode. NOTE: The 'PreInit' statement, if
designated, will NOT be used in conjunction with this
initialization string.
SCHEDULING EVENTS CHANGES AND ADDITIONS
Event Exits
Event exits E4-E9 can now be followed by a three character
string. If that string is matched in the file extension of
a received file, then the designated errorlevel exit will be
taken. For example:
E4=100,TIC (Received .TIC Files Cause Exit 100)
E5=100,FLE (Received .FLE Files Cause Exit 100)
E6=110,REQ (Received .REQ Files Cause Exit 110)
E7=120,MO? (Received .MO? Files Cause Exit 120)
The order of exit precedence is as follows:
E3
E4-E9
E2
AfterMail
When more than one E4-E9 exit applies, the first one is the
one taken.
Send Only Events
The "S" event parameter was not documented in the manual.
It designates an event which is "send only" meaning that
BinkleyTerm will continue to send normally, but will not
answer the phone (or if the modem is in auto-answer mode,
BinkleyTerm will not respond).
---------
SECTION 2 General Reference Information
---------
TERMINAL MODE KEYSTROKES CHANGES AND ADDITIONS
Alt-E
Erases the display screen.
Alt-I
Re-initializes the modem.
UNATTENDED MODE KEYSTROKES CHANGES AND ADDITIONS
Alt-G
Allows the generation of an outbound file request. When
executed, this command will pop-up a window on the screen
where you will be prompted to provide information
appropriate to creating a file request. See 'Colors' in
"Configuration File" for related information.
Alt-I
Re-initializes the modem (equivalent to Alt-T/Alt-U in
previous BinkleyTerm versions). Also causes BinkleyTerm to
re-read the outbound mail holding area.
Alt-K
Allows you to kill all mail for a particular node. When
executed, you will be prompted for the appropriate
information.
Alt-S
Allows the generation of an outbound file attach. When
executed, this command will pop-up a window on the screen
where you will be prompted to provide information
appropriate to creating a file attach. See 'Colors' in
"Configuration File" for related information.
Alt-Y
Polls the boss node (same as Alt-Y in Terminal Mode).
--------------------------------------------------
MISCELLANEOUS NOTABLE ITEMS ABOUT BINKLEYTERM 2.40
--------------------------------------------------
Time Slice Release
In situations where BinkleyTerm would normally release time
slice when used in a multi-tasking environment, it will now
call the MS-DOS scheduler interrupt (int 28h for the
technical among us) when running in a straight DOS
environment. This will improve performance of any
background tasks like print spoolers and networks.
Mode Switching
When switching from Terminal Mode to Unattended Mode,
BinkleyTerm will switch back to using the port shown in the
configuration file (if changed while in Terminal Mode).
Multi-Taskers
The PC-MOS operating system is now detected by BinkleyTerm
at start-up, and if identified, time slice will be properly
released when appropriate by BinkleyTerm to improve overall
system performance.
Foreign Language Capabilities
This release of BinkleyTerm allows you to generate your own
translations or modifications of much of the BinkleyTerm
internal text. Enclosed with this release is a file named
ENGLISH.TXT, which is the raw English language text created
by the authors, and BINKLEY.LNG which is the compiled binary
representation of ENGLISH.TXT for BinkleyTerm's use.
To create your own translation of BinkleyTerm's text
strings, copy the ENGLISH.TXT file to a file of your choice
for editing. Use a standard ASCII flat text file editor
(such as DOS EDLIN or your favorite word processor in non-
document mode) to edit the file for your needs. The strings
should in most cases be self-explanatory.
When finished editing the file, use the included language
compiler, BTLNG.EXE, to compile the text into binary format
for BinkleyTerm's use. The command line for BTLNG.EXE is as
follows:
BTLNG <source_file> <output_file>
For example, to compile the ENGLISH.TXT file, use the
following command:
BTLNG ENGLISH.TXT BINKLEY.LNG
The binary language file must be named BINKLEY.LNG in order
for BinkleyTerm to recognize it.
Persons who are qualified (bilingual and sufficiently
experienced or educated) to translate ENGLISH.TXT into
foreign languages are encouraged to do so and to make your
translations available to others through appropriate means.
Filtering Negotiation Sequences
In some situations, incoming MNP or V.42 negotiation
sequences would cause BinkleyTerm to improperly respond to
incoming callers. In this release, BinkleyTerm recognizes
the negotiation sequences (if your modem does not filter or
use them internally) and will properly discard them.
----------------------------------------------------
DESCRIPTION AND OPERATION OF THE JANUS MAIL PROTOCOL
----------------------------------------------------
NOTE: Janus is an EXPERIMENTAL protocol. It is not at this
writing a documented FTSC standard. BinkleyTerm 2.40 represents
the first implementation of Janus in a released software product,
and is providing its first "real world" testing. With all of
this in mind, it is important to understand that Bit Bucket
Software cannot and does not provide any assurances or guarantees
that Janus will work for you in your environment. PLEASE READ
THIS SECTION IN ITS ENTIRETY IN ORDER TO UNDERSTAND AND PROPERLY
IMPLEMENT JANUS. FAILURE TO DO SO WILL YIELD UNPREDICTABLE
RESULTS!
An Introduction to Janus
Janus is a file transfer protocol specifically designed for WaZOO
mail transfers. It can achieve Zmodem-like performance and
reliability, with the major added benefit of being able to do
transfers in both directions simultaneously. It is implemented
as dual independent state machines; one for sending files, and
one for receiving files. Both state machines run simultaneously,
sharing the phone line. All data is exchanged in variable-length
packets, with either a 16 or 32 bit CRC. Under ideal conditions,
you can expect Zmodem-class performance going both ways at the
same time.
The bottom line is that when two machines exchange mail using
Janus, the smaller of the two nodes' batches of files will be
sent for free while the larger batch is being sent. If you poll
your EchoMail feed nightly, and usually only send a couple of
kilobytes while picking up a couple hundred, you won't get any
real benefit from using Janus. But if you normally send 100kb
and pick-up 200kb, you'll see significant time and money savings.
However, even if you don't usually need to send and receive much
data at once, and don't get much benefit from the full-duplex
file transfers, you should get Zmodem-level performance even on
one-way transfers, and so shouldn't have any penalty for using
Janus rather than ZedZap (Zmodem). The idea is for the benefits
to be there when you need them, without costing you anything
extra if you don't.
What You Should Be Aware Of
There are some important considerations that you should be aware
of before using Janus. Most importantly, Janus is a FULL DUPLEX
protocol, and works best with a full-duplex connection. It's not
a good idea to try and shove streaming, non-stop, full-duplex
data through a half-duplex connection, since the modems will end
up constantly flip-flopping the line around and retraining, and
you'll get terrible performance.
What this means is that normal low speed (1200 and 2400 baud)
connections should work fine with Janus, and that high speed
links that use V.32 should also work fine. High speed
connections with high speed in one direction and a low speed back
channel (such as an HST) will not allow Janus to work well at
all.
There are some other situations where Janus will not work very
well. Many systems, modems and networks just don't seem to have
the sustained bandwidth to allow full-duplex streaming data to be
transferred accurately.
Telenet's PC Pursuit service is a good example. The service has
great difficulty with Janus, frequently dropping and mangling
data. Janus simply saturates the capabilities of the packet
switched connection.
Some modems and even some serial port hardware doesn't seem to
bear up very well under the tremendous load Janus can put on them
either. This is probably to be expected, since full-duplex
streaming protocols are rare, and the hardware has probably never
been tested under this type of extreme, sustained load.
The bottom line is that Janus may or may not work for you with
your hardware, and if it does work, it may not work well on all
connections. Its implementation in BinkleyTerm has been tested
thoroughly, and works very well in many cases. You'll need to
enable Janus (by default, Janus is not enabled) and test it
yourself in your own environment to know whether Janus is a
workable solution for you.
+--------------------------------------------------------+
| Bit Bucket Software cannot guarantee the performance |
| and applicability of Janus. If Janus does not work |
| for you in your environment, please do not bombard us |
| with questions and comments about the protocol; simply |
| disable Janus again (which it is by default). |
+--------------------------------------------------------+
Configuring Janus
Your first consideration before using Janus is your FOSSIL driver
buffer configuration. Janus really needs at least a 2kb receive
buffer (or better yet, 3kb) and no more than about a 1kb transmit
buffer (including whatever transmit buffering your modem does).
The reason for the large receive buffer may be obvious; the
largest packet Janus ever sends is 2kb, and while it's sending
2kb, you can obviously receive 2kb, which Janus won't be able to
read from the FOSSIL until it's done sending. So up to 2kb of
data can easily be received before Janus gets a chance to read
any of it, and possibly a bit more in some situations. If your
receive buffer is too small, you'll constantly lose incoming data
and require massive numbers of retransmissions.
The send buffer should be kept fairly small, because of the way
the packets for the two directions are interleaved on the phone
lines. If I'm receiving a large file from you while I'm sending
you lots of small files, every time I finish sending you a small
file I have to wait until I've received your entire send buffer's
worth of data before I see the acknowledgement that says you
received my file okay. If your send buffer is more than 1 or
2kb, this can end up wasting a lot of time.
Configuration File Modifications
IF YOU HAVE A LOW SPEED MODEM (2400 baud or under), then you will
generally use the 'JanusBaud' statement in your configuration
file. Set 'JanusBaud' to your highest supported baud rate.
IF YOU HAVE A HIGH SPEED MODEM (9600 baud or above), then you
might need to use a combination of 'JanusBaud' and 'JanusOK'
statements in your configuration file. 'JanusBaud' should be set
to the highest FULL DUPLEX baud rate you support. The only
exception is if you have a multi-standard modem. Use the
following as a guideline:
Modem Type JanusBaud Statement
-------------- -------------------
V.32 Only JanusBaud 32767
Non-V.32 Only JanusBaud 2400
Multi-Standard JanusBaud 2400
NOTE: 32767 is the maximum setting for 'JanusBaud.'
If your high speed modem is single-standard, then 'JanusBaud' is
all you will probably need to use. Multi-standard modems require
'JanusOK' statement(s) in order to take full advantage of high
speed full duplex (V.32) connections when they occur.
Your multi-standard modem should be set to return extended modem
connect information. This information is appended to the end of
the modem connect message, and can be used to determine what type
of connection has been made in conjunction with the 'JanusOK'
statement.
In the case of a USRobotics HST Dual Standard, you will normally
want to use Janus on V.32 connects, but not on HST connects. For
example, these connect strings would indicate connections where
Janus can be used:
CONNECT 9600/Arq/V32
CONNECT 9600/V32
But a connection like this would not take advantage of Janus:
CONNECT 9600/Arq/Hst
NOTE: The extended connect information is not shown in all upper
case, since BinkleyTerm will convert everything but the first
character to lower case for display, automatically.
You would permit Janus only on the desired connects, like this:
JanusOK /Arq/V32
JanusOK /V32
Make certain that you also set 'JanusBaud' no higher than 2400,
or your 'JanusOK' statements may not have the desired effect. In
addition, you will probably want to dial out in V.32 mode if you
frequently connect with multi-standard modems of the same make
and model. This will allow Janus to be enabled on the maximum
number of connections.
If your multi-standard modem is not an HST Dual Standard, consult
your modem manual for details extended connect information for
your particular modem make and model.
NOTE: In testing, it has been found that the "PEP" mode of the
Telebit Trailblazer series modems can handle Janus, even though
PEP mode is not full duplex. Throughput may not be as high as it
would be on a true full duplex connection.
----------------------------------------------
DESCRIPTION AND OPERATION OF DOMAIN ADDRESSING
----------------------------------------------
Introduction
Domain addressing is a relatively new concept in FidoNet, and
represents an alternative, more complete method of designating
various networks than the zone method now commonly in use. In
theory, domain addressing adds an additional "layer" to address
designation that represents a particular network. Within that
network, zones and nets can all be specified without conflict to
identical zones and nets in other networks.
Domain support in BinkleyTerm requires you to use separate and
distinct nodelist files for different domains. BinkleyTerm can
now be used much more effectively in multiple network
installations, assuming all the elements are configured properly.
'Address' Statement
BinkleyTerm will accept a domain designation in any 'Address'
statement in the configuration file. A domain is a valid
Internet domain in most cases. For example, 1:104/501 might have
the following in its configuration file:
Address 1:104/501@fidonet.org
At this writing, FidoNet is the only FidoNet technology network
that is listed with Internet, but that is subject to change.
Alternative networks should be designated by their "common" name
followed by ".ftn" (for FidoNet technology network). For
example, a node in Alternet might be designated as follows:
Address 7:520/1015@alternet.ftn
'Domain' Statement
There are several elements to successful domain implementation,
in that nodelist and outbound areas change by domain. This
information is given by you in the form of 'Domain' statements in
your configuration file. The format of the 'Domain' statement is
as follows:
Domain <designator> <abbreviation> [<nodelist>]
The <designator> is the actual domain name. As shown previously,
FidoNet would be "fidonet.org" and Alternet would use
"alternet.ftn" for the designator.
The <abbreviation> is the abbreviated form of the domain name,
and is LIMITED TO EIGHT (8) CHARACTERS. This name is passed in
the packet header during a session. In most cases, this will be
the common name of the network, such as "fidonet" or "alternet"
in our examples.
Finally, the optional <nodelist> parameter provides the base
nodelist name to associate with this domain. If not given, it
defaults to the same name given for the <abbreviation> parameter.
In our examples, "nodelist" would be used for FidoNet, while
"anetlist" would be used for Alternet.
Here are two complete examples of the use of the 'Domain'
statement, one for FidoNet, one for Alternet:
Domain fidonet.org fidonet nodelist
Domain alternet.ftn alternet anetlist
NOTE: If you designate a domain in your 'Address' statement,
then you must also create a corresponding 'Domain' statement.
Outbound Area Naming
The name of the outbound area also changes according the domain.
As always, the outbound area for your primary address (including
domain) is given with the 'Hold' statement.
Outbound areas for other domains take an identical path, except
the name of the last sub-directory is changed to the
<abbreviation> parameter. For example, if your 'Hold' statement
designates C:\BINKLEY\OUTBOUND for an outbound holding area (and
you are in FidoNet), Alternet outbound mail would be held in the
C:\BINKLEY\ALTERNET.xxx directory instead. Note that outbound
areas for domains other than your own will ALWAYS have a zone
extension.
Working Example
If you're thoroughly confused at this point, possibly a working
example will help. Assume that a configuration file has the
following:
Hold c:\bink\outbound
Address 1:104/501@fidonet.org
Domain fidonet.org fidonet nodelist
Domain alternet.ftn alternet anetlist
Domain eggnet.ftn eggnet egglist
The nodelist files would be as follows:
NODELIST.* (for FidoNet)
ANETLIST.* (for Alternet)
EGGLIST.* (for Eggnet)
The examples of outbound holding areas are as follows:
c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.005 (FidoNet Zone 5)
c:\bink\alternet.007 (Alternet Zone 7)
c:\bink\alternet.059 (Alternet Zone 89) c:\bink\eggnet.063 (Eggnet Zone 99)
Addendum to BinkleyTerm Documentation
Changes and Additions
for BinkleyTerm Version 2.50
Copyright (C) 1991 Bit Bucket Software, Co.
INTRODUCTION
Once again, the documentation for this latest release of BinkleyTerm is
being issued as an addendum to the previous docs. Information contained
herein should be considered as superseding any previous documentation.
We expect to have a comprehensive update for the BinkleyTerm docs by Q4
1991 or Q1-1992.
------------------------------------------------------------------------
--== WARNING!!! ==--
--== THIS VERSION IS NOT A PLUG IN UPGRADE FOR VERSION 2.40!!! ==--
------------------------------------------------------------------------
Bink 2.50 will MOST DEFINITELY break your 2.40 batch files, if you're
using the "BBS Spawn", "BBS Batch", or "ExtrnMail" methods of calling up
your BBS.
The way that Bink hands the baton to the BBS has changed - TWO bps
rates are now passed to the outside world. Previously, Bink would exit
with the following parameters written to the batch file:
For the "BBS Batch" and "BBS Spawn" methods,
OLD STYLE (v2.40 & earlier):
SPAWNBBS %1 %2 %3 %4
%1 = caller's connect rate as reported by the modem
%2 = the comm port in use
%3 = time to the next event in minutes
%4 = extended information in the modem connect string (/ARQ, etc)
For the "ExtrnMail" method,
OLD STYLE (v2.40 & earlier):
EXTMAIL %1 %2 %3 %4 %5
%1 = caller's connect rate as reported by the modem
%2 = the comm port in use
%3 = time to the next event in minutes
%4 = errorlevel exit from the original batch file
%5 = extended information in the modem connect string (/ARQ, etc)
NOW, BinkleyTerm 2.50 passes the link rate first, and the caller's
actual connect rate as the second parameter.
For the "BBS Batch" and "BBS Spawn" methods,
NEW STYLE (v2.50):
SPAWNBBS %1 %2 %3 %4 %5
%1 = speed of the computer-to-modem link rate in bps
%2 = caller's connect rate reported by the modem
%3 = the comm port in use
%4 = time to the next event in minutes
%5 = extended information in the modem connect string (/ARQ, etc)
For the "ExtrnMail" method,
NEW STYLE (v2.50):
EXTMAIL %1 %2 %3 %4 %5 %6
%1 = speed of the computer-to-modem link rate in bps
%2 = caller's connect rate reported by the modem
%3 = the comm port in use
%4 = time to the next event in minutes
%5 = errorlevel exit from the original batch file
%6 = extended information in the modem connect string (/ARQ, etc)
NOTE: If you're locking your FOSSIL driver, the link rate and connect
rate passed by BinkleyTerm will be the same (unless the connect
rate is one of the new HST-reported non-standard rates). Bink
has no way of knowing the port's been locked unless it does
the locking itself via the "Lockbaud" config verb. Please refer
to the detailed link/connect rate table later in this document
for further details.
For instance, if you previously used this line in your BBS batch file:
Opus Bbs -b%1 -p%2 -t%3
Change it to:
Opus Bbs -b%2 -p%3 -t%4
Of course, if you're using the "BBS Exit" method of calling up your BBS,
none of this affects you. What does affect you is Bink's ability to
recognize the new HST connect strings and how they're handled, explained
later.
--- o ---
Why the change to the batch files? There's a high-tech feature offered
by USRobotics' Courier HST, HST Dual Standard and Telebit's T2500 modems
that, used in combination with Bink's "LockBaud" config verb, will give
your callers with high-speed error-correcting modems the speed benefits
of a locked port and others will have the responsiveness of a normal
connection. If you are using one of these modems, the new "LockBaud"
options will allow you to make use of this feature.
NOTE: You can continue to use your current floating or locked port setup
by leaving the "LockBaud" config verb commented out and ignoring
the following.
If your HST or HST/DS is the older version with round LEDs, use your
favorite comm program (or Bink's terminal mode), type in "AT&$<RETURN>",
and see if "&B2" is listed as an option. If it is, you can use
"LockBaud /ARQ". All v.42bis-capable and newer rectangular LED HST &
HST/DS models support the "&B2" command.
If &B2's not listed, try typing in "ATS$<RETURN>", and see if S-Register 27's
bitmap options allow the port to be locked at 19200 and/or 38400 bps. If so,
use the &B0S27=nnn setup listed below, and you'll be able to lock, but only
at connect speeds of 4800 bps or greater, using "LockBaud 4800".
Courier HST and HST Dual Standards manufactured prior to February 1989
(those not supporting the S-register 27 lock options) will not be able to
utilize the new "LockBaud" options.
Here's how to install this new floating/locked setup:
1) DON'T lock your FOSSIL driver.
2) Enable "LockBaud /ARQ" in Binkley.Cfg (newer HST)
"Lockbaud 4800" in Binkley.Cfg (older HST)
-or-
"LockBaud /REL" in Binkley.Cfg (T2500)
3) Store "&A1", "&A2" or "&A3" in non-volatile RAM to
enable the /ARQ extended result strings (HST)
4) Store "&B2" in non-volatile RAM (newer HST)
Store "&B0S27=128" for 19200 locking (older HST)
Store "&B0S27=192" for 38400 locking (older HST)
-or-
Store "S66=2" in non-volatile RAM (T2500)
5) If your BBS software allows you to pass the port rate separately
(as with Maximus v1.02), call up the BBS as follows:
Max Bbs -b%2 -p%3 -t%4 -s%1
(where %1 is the port rate and %2 is the connect rate)
6) If your BBS doesn't allow passing the link (port) speed
separately from the connect speed (as with Opus), you can use
the following kludge in your SPAWNBBS or EXTMAIL batch file
(using X00's XU.EXE or the similar utility included with your
FOSSIL driver):
Rem convert 1-based port from Bink to 0-based for XU
If "%3" == "1" SET PORT=0
If "%3" == "2" SET PORT=1
.
.
Rem it's always OK to lock with XU since unlock follows
XU LOCK:%PORT%:%1
Opus Bbs -b%2 -p%3 -t%4
if ERRORLEVEL . .
.
.
Rem unlock the port
XU LOCK:%PORT%:OFF
Note that Opus uses a 1-based comm port number, but XU & X00
use a 0-based comm port number.
In the docs for Opus 1.72a, this alternative method has been described:
NOTE: This behavior has NOT been verified!
------------------------------------------------------------------------
New command-line parameter: -a[modem string]
This ONLY affects people who are using Binkley 2.5+ and HST/DS
modems and the Dual Standard's &B2 option!
Binkley 2.50 will be sending the modem connect string infor-
mation, the stuff after the baud rate, out as a separate para-
meter. I don't remember exactly the sequence, but for Opus 1.72
there are two ways to handle it:
(Example! I don't know exactly how Binkley is handling this!)
%1 User Baud
%2 Port
%3 Time to next event
%4 Locked Baud
%5 Extended modem information.
From a batch file you would call Opus as:
Opus bbs -b%1 -p%2 -t%3 -a%5
However, Opus will ALSO accept this:
Opus bbs -b%1%5 -p%2 -t%3
Either way Opus will see the /ARQ and know that if &B2 has been
configured that the baud rate is locked, if the /ARQ is not
there, the baud rate will float.
-------------------------------------------------------------------------
With "&B2" or "S66=2" enabled, when an HST or T2500 establishes a connection
with another error-correcting modem (an /ARQ or /REL connect), it will shift
its DTE rate (the speed it uses to talk to your computer) UP to the rate you
stored in its non-volatile ram (NVRAM) when you initially set it up. To
adjust this stored rate, set your favorite comm program (or Bink's terminal
mode) to the desired rate and send the modem an AT<enter> AT&W<enter>. The
modem stores the bps rate of the command in its NVRAM. Each time it makes
an /ARQ or /REL connection, it checks NVRAM for the specified DTE rate, and
sets it accordingly. For non-/ARQ or non-/REL callers, it sets the DTE rate
to the connect rate.
For older HSTs set to &B0S27=nnn, when the connect rate is 4800 bps or
greater, the DTE rate will be set according to the value of S-register 27
(128 for 19200 bps, 192 for 38400 bps).
--- o ---
USRobotics Courier HST and HST Dual Standard modems' new CONNECT 14400,
CONNECT 12000, and CONNECT 7200 modem result codes are now understood.
Bink will pass the new bps rates as the connect rate, but will pass the
link rate as the next highest "legal" link rate.
For example, here's a table showing how Bink reacts to connects with
and without use of the "LockBaud" verb:
%1 %2
Modem Connect String Link Rate Connect Rate
No "LockBaud /ARQ" & "Baud 38400" (or 19200)
CONNECT 14400/ARQ 19200 14400
CONNECT 12000/ARQ 19200 12000
CONNECT 9600 9600 9600
CONNECT 9600/ARQ 9600 9600
CONNECT 7200 9600 7200
CONNECT 7200/ARQ 9600 7200
CONNECT 4800 4800 4800
CONNECT 4800/ARQ 4800 4800
CONNECT 2400 2400 2400
CONNECT 2400/ARQ 2400 2400
Using "LockBaud /ARQ" & "Baud 38400"
CONNECT 14400/ARQ 38400 14400
CONNECT 12000/ARQ 38400 12000
CONNECT 9600 9600 9600
CONNECT 9600/ARQ 38400 9600
CONNECT 7200 9600 7200
CONNECT 7200/ARQ 38400 7200
CONNECT 4800 4800 4800
CONNECT 4800/ARQ 38400 4800
CONNECT 2400 2400 2400
CONNECT 2400/ARQ 38400 2400
Using "LockBaud /ARQ" & "Baud 19200"
CONNECT 14400/ARQ 19200 14400
CONNECT 12000/ARQ 19200 12000
CONNECT 9600 9600 9600
CONNECT 9600/ARQ 19200 9600
CONNECT 7200 9600 7200
CONNECT 7200/ARQ 19200 7200
CONNECT 4800 4800 4800
CONNECT 4800/ARQ 19200 4800
CONNECT 2400 2400 2400
CONNECT 2400/ARQ 19200 2400
--- o ---
CHANGES TO THE CONFIGURATION FILE:
Lockbaud <string>
Jeff Nonken's Lockbaud ARQ idea has been implemented. The
<string> should be that part of the connect string from the
modem that identifies an error-free connection. The FOSSIL
should NOT be locked if this option is used.
For example:
Using an HST modem:
Baud 38400
Autobaud
LockBaud /ARQ
With the modem set to &B2, [&A1, &A2 or &A3] (and bps rate 38400
saved in non-volatile RAM) both Bink and the modem are set to
38400 bps on any error-free connection. This allows maximum
throughput on MNP5 or v.42bis connections where data compression
is used, while non-ARQ sessions enjoy improved interactive
performance.
On a Telebit T2500:
Baud 19200
Autobaud
LockBaud /REL
With modem register S66 set to 2, the same feature is enabled
on the T2500 modem.
If you have a modem with more than one response code which
indicates an error-free connection, you can use multiple
"LockBaud" lines (up to 16).
Privatenet <fakenet>
If this line is commented out, BinkleyTerm 2.50 offers
full 5-D addressing for points. For example, if you are point 5
off my system, your address would be "1:106/2000.5@fidonet.org",
expressed in 5-D notation. In other words, the five dimensions
are: "zone:net/node.point@domain".
Here are the details of how it's implemented:
In your private nodelist segment, include points as follows (be
SURE that you EXACTLY duplicate the information in the
distributed nodelist for your net host and your node):
Host,106,Houston_Area,Houston_TX,Allan_Madar,etc,etc,etc
,2000,COMM_Port_One,Houston_TX,Bob_Juge,etc,etc,etc
Point,1,Point_1,Houston_TX,John_Smith,etc,etc,etc
Point,2,Point_2,Houston_TX,Mike_Jones,etc,etc,etc
.
.
etc
Run a nodelist processor which can generate points in V6, V5, or
V7 formats, such as Xlaxnode v2.52.
What the generated nodelist looks like:
NODELIST.IDX (V6) File:
Points will be listed as -1/pointnumber in entries following the
bossnode. To find a point, you locate an entry for the boss,
then search for subsequent -1/??? entries for a match or
pointnumber.
Because pointnets are now and probably will continue to be
inserted only via private lists, you must continue this process
until you either find the point or can't find another entry that
matches the bossnode.
.
.
netnum/0
.
.
netnum/nodenum
-1/pointnum
-1/pointnum
-1/pointnum
.
.
NODELIST.SYS (V5) file:
In point entries, net is -1, node is the point number
NODELIST.DAT (V6) file:
In point entries, node flag bit 12 (hex 1000) will be set to
indicate that this entry is a point, and the hub node field will
contain the point number instead of a hub.
Where is the outbound area for points? Let's say you are storing
mail for points off of Vince's system (1:132/491). You would do so
by creating a directory 008401EB.PNT in your Zone 1 Fidonet outbound
directory.
(the hex representation of "132" is "84", "491" translates to hex
"1EB", so "008401EB" represents 132/491 in hexadecimal)
If you were in Zone 1 of Fidonet, a crash packet to Vince's point 12
("12" is "C" in hex) would be something like:
C:\BINKLEY\OUTBOUND\008401EB.PNT\0000000C.CUT
* IMPORTANT NOTE: If you're satisfied with the current fakenet method
* or just want to wait until other tools are available to manage this
* new capability, just leave "PrivateNet" as it is in your config file.
Version6
Version 6 nodelist operation. The previous "NewNodeList" verb
is also recognized for Version 6 nodelist operation by Bink 2.50
but will NOT be supported in future versions of BinkleyTerm.
Version7
Enables support for the new Version 7 compiled nodelist format
developed by Doug Boone for Opus 1.70. This format offers a 40%
savings in file size compared to Version 6. XlaxNode 2.52 and
newer versions of ParseLst can be used to generate Version 7
nodelist files. For comparison, here are the sizes of compiled
nodelist files for the full Fidonet Nodelist (Day 221) in
Version 6 & Version 7 format:
Version 6
NODELIST.DAT 1605248 bytes
NODELIST.IDX 50164 bytes
FIDOUSER.LST 638786 bytes
_______
2294198 bytes
Version 7
NODEX.DAT 794595 bytes
NODEX.NDX 191488 bytes
SYSOP.NDX 247296 bytes
______
1233379 bytes
1060819 byte savings
NOTE: The "sysop name lookup" feature with Version7 uses the
"SYSOP.NDX" file, not the Version6 "FIDOUSER.LST" file.
Be sure to use Version7 compiler keywords "Userlist"
or "Interlist" if you want this feature supported.
BlankWait <number>
Sets the number of seconds Binkley will wait before blanking the
screen when the "ScreenBlank" config verb is uncommented.
StartBlkLen <number>
Allows adjustment of the starting Zmodem session block size from
a value of 64 bytes to 1024 bytes. Communications on noisy lines
often benefit from use of a smaller initial block size. If this
verb is commented out, behavior is identical to 2.40.
MaxTime <number>
Specifies the maximum cumulative time allowed for file request
sessions in minutes. This verb can be used in combination with
the file request size limiters (MaxBytes, KnownMaxBytes,
ProtMaxBytes) as well as the file request quantity limiters
(MaxReq, KnownMaxReq, ProtMaxReq).
KnownMaxTime <number>
See MaxTime above.
ProtMaxTime <number>
See MaxTime above.
RingTries <number>
Limits the <number> of unanswered rings Bink detects before
it hangs up on an outbound call. Your modem must be able to
identify and report "RINGING" for this feature to work. Bink
defaults to 4 where this parameter is not otherwise set.
(Thanks to Henry Clark and Ron Bemis for this idea).
NoSharing
Disables file sharing calls in networked environments.
NoSize
Disables Bink's calculation and display of queued file sizes
for the pending outbound window display. If you see a big
performance problem associated with this feature, try uncommenting
this verb. When in force, the "Q=nnn" schedule flag is also
disabled.
Serial <number>
Bink now defaults to "UNREGISTERED" operation. To disable it
now and forever, uncomment the verb "Serial" followed by a
<number> of your choice. Vince intends to ALWAYS run the
UNREGISTERED version -- proudly.
WinSlice
Uses Windows' timeslice rather than the MSDOS (int 28)
timeslice. Use of a Windows-specific FOSSIL is required
to prevent loss of characters, however.
--- o ---
SCHEDULING EVENTS CHANGES AND ADDITIONS
<flags/options>
H
"High-Priority Crash" - Binkley will send Crash flavored
mail IMMEDIATELY, no matter what the cost. All other
mail flavors are sent according to cost or other
constraints imposed by the current event. This behavior
mirrors that of Crashmail under Opus 1.1x+ with one
exception - Crashmail call(s) are made at normal intervals
during an H event, rather than forcing a repetitive poll
as with Alt-M.
Q=nnn
Inhibits Bink from calling out with less than nnn bytes
of data for a node (?LO + ?UT sizes). You should probably
have at least one event with Q=0 (the default if none is
specified) in order to get the mail out. (Henry Clark
gets credit for this idea)
OTHER CHANGES AND TWEAKS
--- o ---
BinkleyTerm now works internally with function codes, rather than
scan codes. This means that ALL keyboard behavior can be modified
in the ENGLISH.TXT file. Examples are included in that file to
illustrate how this is accomplished. Any key combination you wish
remapped should have the original and remapped scan codes preceded
by the capital letter "U" for Unattended mode, "T" for Terminal mode,
or "A" for Ansi escape sequences. The file should then be recompiled
into a language file using BTLNG.EXE in the following manner:
BTLNG english.txt binkley.lng
Replace the original BINKLEY.LNG file with your newly compiled
revision, and your keyboard remappings will take effect.
--- o ---
A new operating-system conditional switch has been added to
BTLNG.EXE, the language file compiler:
?DOS at the beginning of a line will tell BTLNG to
compile the line if it's being run under DOS
?OS2 at the beginning of a line will tell BTLNG to
compile the line if it's being run under OS/2
--- o ---
"Doorway" mode is now supported in Bink's Terminal package. When in
this mode, all keystrokes are sent out the modem as entered (except
for the command used to toggle the mode on & off). If a function
key is used, a zero followed by the scan code is sent. The default
command to toggle "Doorway" mode on and off is "Alt =" (it can be
remapped the same as other Binkley functions).
--- o ---
An upload/download capability has been added to scripts. It's
invoked as follows:
Upload x filespec
Download x
where x is the protocol selection:
Z for Zmodem
S for SEAlink
--- o ---
The escape character "\" can be used in a phone number to escape
subsequent characters that otherwise would be interpreted by Bink's
dialer. To send the "\" backslash character itself, use "\\".
--- o ---
Incoming call collision response has been improved. If Bink
receives a NO DIAL TONE message from the modem when attempting to
dial out, it will now attempt to answer. This new behavior does
not apply during the first minute after startup or unbusying,
to avoid misinterpreting central-office dead lines (caused by
keeping the line off-hook for extended periods to give callers a
busy signal).
--- o ---
.BSY protection has been extended over the entire session.
Two points to be aware of, however:
Inbound FTS-0001 sessions will have to accept a packet before the
flag can be test/set.
If an outbound area for the calling domain+zone doesn't exist,
Bink will attempt to create the flagfile in the flags directory
- if you have one defined. This allows Bink to accept all
mail, but for ongoing mail operations a separate outbound
directory should be created for the zone/domain in question.
--- o ---
Bink now attempts a DietIfna session ONLY with a remote that
indicates the ability to do so based on the capability bit
in the system's packet.
--- o ---
In fullscreen mode, the pending event display area at the
bottom of the screen will notify the sysop that there is unread
netmail pending. This feature only works on systems that use
the fidonet one-file-per-message *.MSG structure.
--- o ---
An XON (Ctrl-Q) is sent at the start of session whack logic to
unstick systems that may have run afoul of "noise" from MNP
negotiations between error-correcting modems. What's happening?
Occasionally, an XOFF (Ctrl-S) is received during the initial
synchronization between modems. This effectively stops
communications until an XON is sent in response. In theory, this
shouldn't happen, but it sometimes does. The XON is sent as
"preventive medicine" to avoid this problem.
--- o ---
The cost and duration of a call is logged at the end of an
outbound session in the format:
Session with zone:net/node Time: xx:xx:xx Cost: $xx.xx
--- o ---
The low-level FOSSIL write routines now have a 1-minute timeout.
That is, in the event your modem goes out to lunch on you (it
drops the CTS clear to send flow control line and keeps it down
for 1 minute or more), Bink should hang up and recover.
--- o ---
Outdialing begins less than 10 seconds after startup, to help get
calls done in high traffic situations.
--- o ---
While waiting for a call in fullscreen mode under a multitasker,
the bottom line of the "Current Settings" window identifies the
multitasking software in use. This line changes to an elapsed
time indicator during a call, and changes back when the session
is concluded. The line was redisplaying the multitasker only
after a session concluded with an exit.
--- o ---
Hitting Alt-A in unattended mode will send the answer string to
the modem.
--- o ---
Bink is more responsive to the <ESC> key for cancelling
operations during session startup and elsewhere.
--- o ---
The use of <ESC> for shelling to the local command interpreter
has been disabled. ALT-J will still perform a "jump to DOS".
--- o ---
In fullscreen mode Bink displays the amount of mail queued
for each node.
--- o ---
File sharing is supported in DOS versions greater than 2. Most
files are opened in "deny-write" mode.
This support is fully implemented in the MSC 6.00A version,
approximately 90% in the BorlandC version, and probably 50% in
the Watcom and Zortech versions.
--- o ---
A check is made to make sure there's mail to send to a node
before actually dialing out. If not (like maybe it disappeared
in a multitasking environment), the entry for that node will
disappear.
--- o ---
Logic was added to ensure a periodic rescan of the outbound area.
--- o ---
Support is removed for V5, SEAdog and QuickBBS nodelists
in distributed .EXE files; however, the source files have a
conditional compile switch to generate executables with these
features supported.
--- o ---
Finally threw out the old swapper code and replaced it with
Thomas Wagner's excellent public domain code. This gives
Bink XMS or EMS swapping by default and swapping to a file
if XMS or EMS is not available (or insufficient). It also
uses the create-temp-file function in DOS if available, which
should make housekeeping a breeze.
--- o ---
Cleaned up code and MAKEs to allow DOS compilation using NDMAKE
and NMAKE with MSC 6.00a (Large model), DOS using BCX (Large
model), DOS using WATCOM and WMAKE (Large model), OS/2 using
NMAKE with MSC 6.00a (Large model), and OS/2 using WATCOM and
WMAKE (Large model). Zortech C DOS (Virtual Memory model) is
also supported.
--- o ---
The FTSC Product Code lookup table has been moved from the
executable to ENGLISH.TXT, so that any ongoing changes or
additions to these codes (new products between releases) can be
made by the user. Simply insert a line beginning with "P" and
the product code number, followed by a space and product description.
This table controls recognition of what product is calling - Bink's
own Product Code passed in the initial YooHoo packet is NOT affected.
Comments
Post a Comment