Category : BBS Programs+Doors
Archive   : FXB31.ZIP
Filename : FX-BBS.ASC

Output of file : FX-BBS.ASC contained in archive : FXB31.ZIP

FX-BBS Bulletin Board System

Installation and User's Guide

For Version 3.1B

1 May, 1990

By Kenneth R. Roach
PO Box 2271
Manteca, Ca. 95336

(C) Copyright 1987, 1990.
All Rights Reserved.





FX-BBS Installation and User's Guide


Description: Page Number:

Copyright Notices and Program License . . . . . . . . . . . : 5
Introduction . . . . . . . . . . . . . . . . . . . . . . . : 9
Hardware and System Requirements . . . . . . . . . . . . . : 11
System Setup . . . . . . . . . . . . . . . . . . . . . . . : 17
The FXBSETUP Program . . . . . . . . . . . . . . . . . . . : 20
Screen A - Modem Parameters, Initialization Information : 23
Communications Port - Modem Initialization
Onhook/Offhook Commands - Minimum Baud Rate
Maximum Baud Rate - Auto Baud Rate Detection
Maximum Idle Time - Printer On Default
SYSOP Available Default - Command Logging Default
Goodbye String
Screen B - Caller Access Levels . . . . . . . . . . . . : 29
Discussion of Privileges for Each Level
Time Limits - Upload/Download Ratio
Maximum Downloads Per Day - Maximum Calls Per Day
New Caller Access Level - 300 Baud Time Limit
Closed System Option - Subscription Parameters
Screen C - Paths to BBS Files . . . . . . . . . . . . . : 33
Paths to Download Files - Upload File Path
Message Section Path - Text File (Menu) Path
ANSI Text File Path - Text File Naming Convention
Help File Path - BBS Operating Path
Screen D, Screen E - Mail System Parameters . . . . . . : 39
Maximum Messages Allowed - Number of Mail Sections
Maximum Message Size - Names of Message Sections
Reserving Message Deletion Privileges
Screen F - Echo Mail Destination Net/Nodes . . . . . . . : 43
Screen G - Conference Parameters . . . . . . . . . . . . : 46
Maximum Conferences - Private Conferences
Conference Directories - Conference Mail Sections
Screen H - Door Parameters . . . . . . . . . . . . . . . : 50
Maximum Number of Doors - Door Passwords
Door Invocation Commands - Door File Formats
Screen I - External Protocol Parameters . . . . . . . . : 58
Definition of External Protocol
Maximum External Protocols- Protocol Names
Download Commands - Upload Commands
Screen J - Local and Caller Color Parameters . . . . . . : 62
Local Screen Color Definition
ANSI Graphics Color Definition

- 2 -

FX-BBS Installation and User's Guide


Description: Page Number:

Screen K - Illegal Caller Inputs . . . . . . . . . . . . : 66
Illegal File Name Extensions
Illegal Logon Names
Screen L - Miscellaneous Parameters Screen 1 . . . . . . : 67
User ID file Name - Function Key Programs
Function Key Passwords - Name Of BBS
Direct Screen Writes - Upload Bonus Time
Printer Number - Auto Exit Time
Transfer Wait Time - Multitasking Optimization
Main Menu Command Line Definition
Screen M - Miscellaneous Parameters Screen 2 . . . . . . : 72
SYSOP's Name - Front-End Flag
SYSOP Avail - Minimum Access Level
Message Repacking - Allow Comments
Net/Node Number - Origin Line
Screen N - System Parameters . . . . . . . . . . . . . . : 75
Caller Statistics - Memory Allocation
Screen O - Function Key Assignments . . . . . . . . . . : 86
Starting FX-BBS . . . . . . . . . . . . . . . . . . . . . . : 88
The Primary Display . . . . . . . . . . . . . . . . . . . . : 88
Function Key Descriptions . . . . . . . . . . . . . . . . . : 90
Logging On . . . . . . . . . . . . . . . . . . . . . . . . : 94
Caller Main Menu Commands . . . . . . . . . . . . . . . . . : 95
Statistics . . . . . . . . . . . . . . . . . . . . . . . : 95
Status . . . . . . . . . . . . . . . . . . . . . . . . . : 96
Password . . . . . . . . . . . . . . . . . . . . . . . . : 96
Install . . . . . . . . . . . . . . . . . . . . . . . . : 96
List Compressed File Contents. . . . . . . . . . . . . . : 96
Re-display News Files . . . . . . . . . . . . . . . . . : 96
Whereis . . . . . . . . . . . . . . . . . . . . . . . . : 96
Files . . . . . . . . . . . . . . . . . . . . . . . . . : 97
Upload . . . . . . . . . . . . . . . . . . . . . . . . . : 97
Download . . . . . . . . . . . . . . . . . . . . . . . . : 97
Answer Questionnaire . . . . . . . . . . . . . . . . . . : 99
Bulletin Section . . . . . . . . . . . . . . . . . . . . : 99
Chat . . . . . . . . . . . . . . . . . . . . . . . . . . : 100
Enter a Message . . . . . . . . . . . . . . . . . . . . : 100
Goodbye . . . . . . . . . . . . . . . . . . . . . . . . : 102
Help . . . . . . . . . . . . . . . . . . . . . . . . . . : 102
Killing a Message . . . . . . . . . . . . . . . . . . . : 102
Graphics Mode Toggle . . . . . . . . . . . . . . . . . . : 102
Read New Messages . . . . . . . . . . . . . . . . . . . : 102
Open a Door . . . . . . . . . . . . . . . . . . . . . . : 103
Read Messages . . . . . . . . . . . . . . . . . . . . . : 103
Scan Messages . . . . . . . . . . . . . . . . . . . . . : 104
Expert Mode Toggle . . . . . . . . . . . . . . . . . . . : 104
Read Your Personal Mail . . . . . . . . . . . . . . . . : 104
Join a Conference . . . . . . . . . . . . . . . . . . . : 105
Quit a Conference . . . . . . . . . . . . . . . . . . . : 105

- 3 -

FX-BBS Installation and User's Guide


Description: Page Number:

"Zippy" Message Scan . . . . . . . . . . . . . . . . . . : 105
Inter-Node Chat . . . . . . . . . . . . . . . . . . . . : 105
List New Files . . . . . . . . . . . . . . . . . . . . . : 107
SYSOP Main Menu Functions . . . . . . . . . . . . . . . : 108
Terminal Mode Functions . . . . . . . . . . . . . . . . . . : 111
Creating Questionnaires . . . . . . . . . . . . . . . . . . : 115
Mail System Notes . . . . . . . . . . . . . . . . . . . . . : 116
The FXREPACK Program . . . . . . . . . . . . . . . . . . : 118
The FXMAIL Program . . . . . . . . . . . . . . . . . . . : 119
Unpacking Echo Mail . . . . . . . . . . . . . . . . . . : 121
Packing Echo Mail . . . . . . . . . . . . . . . . . . . : 123
Polling Other Systems . . . . . . . . . . . . . . . . . : 124
Changing the Status of Outbound Mail . . . . . . . . . . : 125
File Requests and Attaches . . . . . . . . . . . . . . . : 126
TIC File Processing . . . . . . . . . . . . . . . . . . : 127
Front End Programs . . . . . . . . . . . . . . . . . . . : 130

Message File Formats . . . . . . . . . . . . . . . . . . . : 132
User Id File Record Format . . . . . . . . . . . . . . . . : 134
Notes on Multitasking . . . . . . . . . . . . . . . . . . . : 135
Speed Considerations . . . . . . . . . . . . . . . . . . . : 140
Notes on Networking . . . . . . . . . . . . . . . . . . . . : 146
The EDITUSER Program . . . . . . . . . . . . . . . . . . . : 151
Building Your Directory Files . . . . . . . . . . . . . . . : 153
The SYSOP Install Function . . . . . . . . . . . . . . . . : 154
The FXDCHECK Program . . . . . . . . . . . . . . . . . . . : 157
The FXFILCVT Program . . . . . . . . . . . . . . . . . . . : 160
Assigning IRQs, I/O Addresses and Other Hassles . . . . . . : 166
Security Issues . . . . . . . . . . . . . . . . . . . . . . : 173
Business Considerations . . . . . . . . . . . . . . . . . . : 174
Utility Programs . . . . . . . . . . . . . . . . . . . . . : 177
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . : 182
Restrictions and Known Bugs . . . . . . . . . . . . . . . . : 183
The Program Configuration File on a Line-by-Line Basis . . : 190
Registration Forms . . . . . . . . . . . . . . . . . . . . : 209

- 4 -

FX-BBS Installation and User's Guide

Program License:

FX-BBS is copyrighted, and is made available to the public
through the "shareware" concept. You may freely copy and
distribute unregistered versions of the program for the 8088
processor, provided they are unmodified. Versions of the program
which employ the 80186, 80286 or 80386 instruction set, or which
employ overlays, are available only to registered users.
Registered versions of the program may not be distributed.

A variety of different compression programs exist at the present
time, and I cannot tell the operator of a particular BBS or
shareware distribution system to use one instead of another. I
can say however, that the contents of the distributed files are
not to be modified, and indeed, if the installation program is to
operate properly, ZIP files must be used.

Ownership of all copies of the different versions of FX-BBS
remains with me, the author. Upon registration, you and you
alone are granted the right to use the registered version(s) of
the program. You may not transfer the right to use a registered
copy of FX-BBS to any other persons or companies.

Dealers who might distribute FX-BBS and companion programs are
required to charge not more than $10.00 for any copy of the
program. This cost is to cover distribution of the complete
program, and must include documentation and all utility programs
as well.

As the author, I receive no payment from such distributors. If
you decide to use the FX-BBS program to operate a bulletin board
system, you must register your copy with me.

What Registration Provides You With:

The registration fee is presently $85.00, really a bargain for
what you get. Note that this registration fee does not include
registration of external programs which you may elect to use with
FX-BBS, which have not been written by myself. These include
most notably, external file transfer programs along with "door"
programs. These programs must be registered or not as required
by the authors, separately from FX-BBS.

- 5 -

FX-BBS Installation and User's Guide

While the distributed shareware version of the program is
complete, with no features omitted, there are definite advantages
provided for registering users. In addition to getting rid of
the (relatively minor annoyance of the) non-registered start-up
screen and initial delay, registration will provide you with:

Support: Online support for the program through BerthaBoard BBS
at (209) 239-9853 (2400,8,N,1), as well as voice support as

Different Versions of the Program: Registering users will
receive three versions of the program. The first is compiled to
use the 8088/8086 processors and is the latest version of the
distributable shareware package. The second is compiled to use
the 80186/80286 instruction set. The third is compiled to use
the 80186/80286 instruction set as well as program overlays to
reduce memory consumption during execution. THE 186/286 AND
primary advantage offered by these versions of the program are 1)
increased speed due to the superior instruction set; 2) reduced
memory consumption, due to both the improved instruction set and
the use of overlays. The 8088 version of FX-BBS presently
requires approximately 238Kbytes of memory in which to operate,
in addition to whatever memory might be required by door or other
external programs. The 186/286 version generally requires 5 to
6Kbytes less memory. The overlay version of the program
presently requires about 110Kbytes of memory. These versions of
FX-BBS require you to have an Intel 80186/80286 or 80386
processor, or an NEC V20 processor, which is compatible with the
80186. NEC V20 processors can be purchased for between $10 and
$30, depending on the clock speed required, and are pin
compatible with 8088 cpus. Installation consists of carefully
removing the existing 8088 cpu and even more carefully inserting
the V20 into the same socket. On most clone systems, this will
take about five minutes. If you're using an 8088, you'll find
the NEC V20 will provide a performance increase of about 5-10%,
not terribly noticeable but worth the small cost. For XT class
computers, replacement of the 8088 cpu with the NEC V20 is
required in order to use the overlaid or 186/286 versions of the

Unlimited updates: The latest versions of the program will be
supplied via mail, along with the registration program, which
eliminates the initial start-up screen and delay. Note that when
you register, the fee paid applies to ALL future updates to the
program. That is, any and all program updates can be downloaded
by you from BerthaBoard without the requirement to reregister.
The registration fee is a one-time fee only (substantially
different versions of the program which might be developed and
offered separately might not be included in this category, at my

- 6 -

FX-BBS Installation and User's Guide

Site License: Non-business users of the various versions of FX-
BBS may use any number of copies of the program on any number of
systems at a particular (single) location. Commercial users and
businesses however must register each copy of FX-BBS in use. An
additional fee of $25.00 per copy in use is required.

Source Code: The source code is made available at an additional
cost. The purpose of the additional cost is for the most part,
to keep the casual hacker out of the program. Cost of the source
code is $150, expensive enough to deter most casual examination,
but still affordable. Source code is made available only to
registered users of the program.

Profit sharing: New noncommercial and non-business users who
register and mention the name of a previously registered
individual as the person providing them with their copy of FX-BBS
will cause the referring person to receive $15.00 for the
referral, subject to the conditions outlined in this paragraph.
Note that this applies to each new person registering, but ONLY
to registering or registered users who have submitted the
required $85.00 registration fee. Unregistered users, along with
commercial or business users, listed as a referral will NOT
receive any referral fees. Business or commercial users of the
program are excluded from participation in this offer. That is,
business users of the program do not receive the $15.00 referral
fee. The program is available for normal marketing should a
business wish to do so.

You must complete the form(s) at the end of this documentation
appropriately when ordering FX-BBS.

- 7 -

FX-BBS Installation and User's Guide

Other Copyrights, Trademarks, etc:

Several programs or products referenced herein are copyrighted by
other authors or companies:

The BinkleyTerm program is copyrighted by Robert Hartman and
Vincent Perriello, 1988.

The X00 driver is copyrighted by Raymond L. Gwinn, 1987.

The ConfMail program is copyrighted by Bob Hartman.

The MsgEd program is copyrighted by Jim Nutt, 1988.

The ParseLst program is copyrighted by Bob Hartman.

IBM is a trademark of International Business Machines Corp.

MS-DOS and MASM are trademarks of or copyrighted by Microsoft

DesqView, QRAM and QEMM are copyrighted by Quarterdeck

DoubleDOS is copyrighted by SoftLogic Solutions.

MP325 was a computer model number used by Corona, now doing
business as Cordata.

Turbo-C, Turbo Pascal and TASM are copyrighted by Borland

.RTLink is copyrighted or trademarked by PocketSoft, Inc.

Eco-C is copyrighted by EcoSoft Company.

SeaLink is a file transfer protocol designed by System
Enhancement Associates.

ARC is a trademark of System Enhancement Associates at this

PCBoard is copyrighted, I assume, and I think by Salt Air

- 8 -

FX-BBS Installation and User's Guide


FX-BBS began simply as an effort to provide myself with a
bulletin board program which would be reliable and adequate for
my own needs. An effort was originally made to use several other
programs, but none were found to perform satisfactorily on my own
equipment. The equipment in use was a not 100% compatible,
Corona portable MP325, which employed a rather different memory
layout in an effort to achieve superior (and nonstandard)
graphics. Most bulletin board programs would either lockup
immediately, or enter strange loops which appeared to be doing
something software might want to do, and which I doubt the
authors of the various programs could reproduce.

It seemed to me that if I was going to run a bulletin board (and
there were none in my area at that time), I was going to have to
write the software myself.

While the program was initially developed to support a single
phone line system, with a dedicated computer system running the
BBS, it has evolved over the past few years to be much more
powerful, I suspect one of the most powerful BBS programs around
(though perhaps not perfect). FX-BBS is written in Turbo-C 2.0
and assembly (partly MASM and partly TASM), with many of the
support programs written in Turbo Pascal 5.5 (one user has
written some Microsoft Basic support programs, so there's
something for everyone). The source code for the complete
program is presently hovering around the one megabyte mark and is
beginning to be difficult to keep track of. The documentation
is, well, you have a pretty good idea of how large that is. The
program as of this writing, includes the following primary

Simple, menu-driven installation and setup.

Easy to configure and use menu structure. Almost all caller
selectable functions are selectable from the main menu, making
it usually unnecessary to go through several layers of menus
to get to the desired function. (Exceptions to this include
the on-line SYSOP maintenance functions, the statistical
information area of the program, and some of the door programs
which you might wish to add).

Built-in support of the "core" file transfer protocols,
including ASCII, SeaLink, Xmodem and 1K-Xmodem (sometimes
referred to as Ymodem), along with full support of external
protocol programs, as well as complete support for "door"

Multitasking support. FX-BBS is heavily optimized to run in
the DesqView and DoubleDOS multitasking environments, allowing
two or more telephone lines to be driven by one computer. Up

- 9 -

FX-BBS Installation and User's Guide

to four copies of the program may generally be run on a single
machine (more, depending on hardware and software used), each
providing the ability to chat with other callers. Since
separate copies of the program are run for each line,
processing related to external door and file transfer
programs, as well as mail bundling "front-end" programs is

Compatibility with Local Area Network (LAN) systems, providing
considerable expandability and almost unlimited expansion
capabilities as required when your system grows. Standard PCs
may be added to expand your BBS, without the need to purchase
expensive boxes which are only useful to drive nonstandard
modems. Internode chat functions are provided across the LAN
as well.

Built-in terminal program capabilities, allowing you to call
other systems, enter messages and upload/download files
without the need to load a separate program. Setup parameters
as required and which differ from those contained in the FX-
BBS configuration file, are stored in the dialing directory

Compatibility with FidoNet Echo and NetMail systems when used
with a mail processing program such as BinkleyTerm. Up to 80
message sections can be specified. To prevent excessive usage
of disk space, messages are stored in single, large files for
each different section. Increasing or decreasing disk sector
size has little effect on space required for messages.

Messages of up to 64K are supported (more than most receiving
echomail systems can support), with actual maximum size
configurable by the SYSOP.

Choice of full screen ANSI editor using a subset of the
WordStar command set for terminals, or a standard line editor
when callers are not using ANSI.SYS.

This documentation is organized into 3+ primary areas. The first
is a general discussion of parameters which may be entered using
the FXBSETUP program. This is followed by a sort of a "guided
tour" of the options available when one logs onto FX-BBS and can
be used to help guide you through the various options. Finally,
various areas of technical consideration are discussed, including
how mail processing is handled, setting up and maintaining
downloadable files and their descriptions, user file structure,
security concerns and issues relating to the setting up of one's
downloadable file directory structures.

- 10 -

FX-BBS Installation and User's Guide

Hardware and System Requirements:

FX-BBS was developed to run on a "generic clone". By "generic
clone," I mean a collection of parts purchased at the swap meet,
and assembled without a great deal of care by myself (a nearly
complete hardware idiot).

The computer you use should be an IBM compatible, pre-PS/2. FX-
BBS has not been tested on a PS/2, and no promises are made.
Based upon documentation I have read, it seems safe to say that
FX-BBS will *not* run under OS/2 without major changes. When
OS/2 has completely replaced Dos and the cost has dropped to
something reasonable, perhaps I'll change this.

The machine should have at least 320Kbytes memory for the non-
overlaid versions of the program, and 256Kbytes for the overlaid
version. More if available. A standard XT system can be used to
run one copy of the program. My own BBS system, a 20mHz 386SX
clone, is equipped with 2Mb of memory. I presently run SHARE.EXE
for file sharing, a device driver called GATEWAY (at least two
copies) which allows me to see what's happening inside a door
program on the local screen, device drivers supporting a LAN, and
DesqView to start with. Each partition which is running a copy
of FX-BBS also runs the DVANSI.COM program so that ANSI graphics
are presented properly, and is configured to provide at least
75Kbytes of memory (in some cases more) over and above what FX-
BBS requires to allow door programs and external file transfer
programs such as DSZ to be run. DesqView is run in conjunction
with QEMM such that it will load as much as possible of itself
into extended/expanded memory. Some 250Kbytes of extended memory
is reserved for use as a ram disk, which is used to hold the
overlaid version of the program as it runs. In this case, I have
memory enough to run three copies of FX-BBS in different ways,
along with about 200Kbytes left free, in which I can access the
system for copying files, looking at directories, editing menus
and so on. This particular system does nothing except run the
BBS. If I wished, I could trim memory requirements sufficiently
to run perhaps, six copies of FX-BBS on this system without great

You should of course, have a hard disk or two if you're serious
about running a BBS, though the program (non-overlaid version)
might be used with floppies for a very few users. A monitor is
generally helpful, since it's nice to see what you and the
callers are doing. You should also have a clock/calendar
capability. FX-BBS must be kept informed of the current date and
time. If running two copies, two monitors can be especially
nice, though are clearly not required. If you plan on using
color graphics for ANSI.SYS using callers, then a color, or
perhaps a composite monitor at least, would be nice. Printers
come in handy too.

- 11 -

FX-BBS Installation and User's Guide

Unlike a user's personal system, BBS computers usually perform a
dedicated task. The hardware required is usually rather
specific, but no more hardware than the minimum required need be
provided. You do not need a mouse for example, nor a dedicated
printer. A math processor will not improve the system's
performance, and multiple floppy drives are not required. 256
color, 1024x768 displays are not required either (I've been
running monochrome on my BBS computer for a very long time, with
color menus designed on another system). Much better to spend
any money you have burning a hole in your pocket on hard drives,
better or more modems, and perhaps cpu clock speed.

FX-BBS relies on an external program to perform multitasking
chores (usually DesqView or DoubleDOS), and does not have the
capability built in. Because of this, door processing, external
protocols and front-end programs such as Binkleyterm are easily
used with FX-BBS. The system can also be easily used by yourself
for other purposes as well. If you're going to do multitasking,
that is, run a multiple phone line system, you should have a
moderately fast machine. An AT class machine is strongly
recommended. For two phone lines, you should have a clock rate
of at least 8 mhz and no wait states. You should also have at
least one hard disk with an access time of 39ms or better. This
drive would be the one used for mail messages, BBS displayable
text files and the caller ID file. Callers will generally be
unaware of one another if you've set all parameters optimally,
with the exception of when multiple callers might be searching
mail areas at the same time, and perhaps when used with certain
external programs which are not designed for use in a
multitasking environment. The degree to which callers notice one
another here will directly relate to the speed of your disk
drives. A slower drive then, might turn out to be a disservice
to your callers.

For three phone lines, a clock rate of not less than 12mhz is
recommended, and a drive with an access time of better than 39ms
should be considered as well. DoubleDOS, which supports only two
partitions, is no longer an option and you must use the DesqView
program. At this point too, you may also have to add an expanded
memory board unless you are using an 80386 system or an
aftermarket board providing memory management functions. Such
systems may be used with a device driver to configure its memory
to emulate expanded memory vs. extended memory, as required by
DesqView. Memory on the motherboard is preferred over memory
boards plugged into the I/O bus, since motherboard memory is
usually capable of much greater speed. When it is necessary to
add an expanded memory board, the AST Rampage/286 and Rampage/286
Plus are recommended. These boards are among the more expensive
available. However, they are presently configurable as either
Expanded or Extended memory, and so may be of more use if/when
OS/2 becomes popular. Also, various benchmark programs indicate
that these boards are among the fastest available. Some other
expanded memory boards are apparently older EMS designs, cobbled

- 12 -

FX-BBS Installation and User's Guide

up somehow to run under the LIM 4.0 standard. While these boards
can be purchased for as little as $85, they may prove
unacceptably slow in a multitasking environment, or incapable of
performing the tasks you wish when using the DesqView program.

For four phone lines, greater speed should be provided for both
the computer itself and at least one disk drive (the drives on
the 386SX system I use for the BBS total approximately 350Mb, are
RLL and so have a transfer rate of 750Kbps, 50% faster than
standard MFM drives; the seek times of the drives are 19ms and
39ms). A 16mhz or better 80286 system is recommended at a
minimum, but a 80386 system seems preferable due to its superior
task switching and memory management capabilities. Cost of such
systems is dropping rapidly. More than four lines might require
a faster 386 still, if you use several high speed (9600 baud)
modems, or run slow door programs. When considering standard
2400 baud modems, a 25mHz 386 system has been demonstrated to
support six lines adequately (eight would likely be fine, but
could not be tested due to insufficient resources at the time).
FX-BBS may be optimized for a multitasking environment, but many
programs are not and there's nothing I can do about those. Great
care should be taken in choosing the equipment you'll use, since
too little power may prove unacceptable.

While fast hard disks and a fast system are of real value, disk
and memory caching are less so. Consider that on many BBSs,
literally thousands of files exist. Hundreds of messages may be
read, forward and backward, with echomail and door programs run
as well. For a disk caching program to be of any benefit at all,
it would have to be a very intelligent program in order to see

those few repeating sectors worth hanging onto out of the
thousands being accessed. I suspect that ram devoted to caching
would be of better use when employed as a ram disk. Memory
caching, that is, the use of hardware to compensate for memory
which is too slow to keep up with the cpu or to otherwise improve
performance, is also of questionable value. For a normal Dos
system, caching can provide a noticeable improvement. But for a
multitasking system, it is possible that it might actually have a
negative impact on performance depending on its design. As
DesqView switches tasks, it must continuously access different
areas of memory. When this is done, the memory cache must flush
any changes it has made into real memory and then load the new
area being accessed into the cache. DesqView in and of itself is
capable of doing this perhaps 18.2 times per second. The FX-BBS
program, with multitasking optimization enabled, will often cause
this to occur even more rapidly. Small caches especially would
seem of questionable value. Again, spend the money on more disk
space. Or more or better memory, or a faster processor.

- 13 -

FX-BBS Installation and User's Guide

Be aware that a portion of video ram may be used by the program
in a multitasking environment for intertask communication. This
will be compatible with video adapters such as CGA, EGA, VGA
(when used in 25 line mode) or Hercules monochrome compatible
adapters. Older true blue IBM monochrome adapters do not have
memory left over and so will not allow intertask communication in
and of themselves. Also, depending on how you've configured
DesqView, problems may arise as a result of this if you are using
an EGA or VGA monitor. When using such monitors, or when using
an older IBM monochrome monitor, or if your CGA monitor exhibits
snow problems, you may wish to use the FXCOMM TSR program. This
program provides an alternative intertask communications area,
but requires an additional 2Kbytes or so of memory (different
versions of the FXCOMM TSR are available; more memory will be
used for the LAN support versions).

The modem you use must be a Hayes compatible (that is, it must
use some version of the Hayes command syntax). It is very
unlikely that the program will function using modems which are
not Hayes compatible, though this may be possible. Support is
also provided for faster modems, specifically, US Robotics HST
modems. While the program has not been tested with the fast
Telebit modems and others, it should work. It is doubtful that
it will work with some of the cheap 9600 baud modems being
offered by mail order firms lately. Since these particular cheap
modems are often only compatible with themselves, they are rather
undesirable in any case. I've heard some are actually fax
machine modems... Beware.

The modem you use also has an effect on FX-BBS's ability to
operate adequately in a multitasking environment. Communications
processing may be optimized by setting the appropriate parameter
using the FXBSETUP program, provided your modem allows such.
Optimization values range from 0 to 6, with 0 representing no
optimization. In this case, each byte to be transmitted is
simply stuffed into the appropriate register of the modem, with a
delay as required if clear to send is not set. Values from 1 to
4 each cause transmit interrupts to be used instead of the brute
force method. Each larger value increases the size of the
transmit ring buffer. A value of 1 indicates that transmit
interrupts are to be used with a ring buffer size of 512 bytes.
The ring buffer is not allowed to become very full at all
however. Other values allow the ring buffer to become nearly
full before waiting for it to empty. A value of 2 selects a ring
buffer size of 512 bytes, 3 selects a size of 1024 bytes, 4 a
size of 2048 bytes, 5 a size of 4096 bytes, and 6 a size of 8192
bytes, the largest available. When transmit interrupts are used,
FX-BBS will operate as fast as possible to fill the transmit
buffer. When this has been done, in a system configured to
perform multitasking optimization, a given copy of FX-BBS will
"shut down," and give all cpu time to any other tasks which may
be running. The effect is a substantial performance increase for
other tasks which may be running, either BBS programs or not.

- 14 -

FX-BBS Installation and User's Guide

Given this rather verbose explanation, I can now say that it
seems not all modems allow transmit interrupts. At least two
brands of modems refused to support transmit interrupts at all.
I don't know why, but suspect the modems to be of low quality
(though not all inexpensive modems exhibit this problem). It's
also possible that something about how the system is configured
is causing the problem. If you plan on running a multiline
system, you should test any modem you might want to purchase to
determine if optimization functions properly.

Most "cheap" modems will work without problem and will support
transmit interrupts. They're often quite compatible. On the
other hand, modems supporting MNP-4 or MNP-5 often exhibit
compatibility problems. The MNP protocol requires tighter
tolerances perhaps, and in return provides greater throughput and
error correction. An MNP-5 modem operating at 2400 bps will
often provide a throughput of 4800 bps. The HST modem I use has
a maximum rate of 14,400 bps, and with MNP-5, can hit close to
25,000 bps (HSTs presently are NOT 19200 bps modems. While they
may communicate with your computer at this rate or higher, they
communicate with callers (presently) at 14,400 bps at most, in
spite of what your friend down the street may say). Getting back
to the original subject, the less expensive modems can at times
refuse to talk with the MNP-5 modems, and I think personally that
more folks who call are compatible with my "cheap" modem than
with any of the more expensive MNP-5 modems I have. It's also
the case that if an MNP-5 modem can drive the caller's screen at
4800 bps or so, it will take more of your resources to feed that
amount of data to that modem. All food for thought. No
guarantees can be made with regard to any particular modem.

It should be mentioned that the computers I use have always been
clones, NOT real IBMs. I started with XT class equipment, then
went to "Turbo" XT systems, followed by a 286 system and a 286
accelerator card, and presently have two 386 systems. Probably
could have saved some money by getting the 386s to begin with...
Similarly, the modems I use, two EasyData 2400 baud internals, a
Micom, an Everex 2400 baud internal, and an HST are NOT real
Hayes modems. I mention this, because I've written software for
PCs before which, while working on clones, did NOT work on a real
IBM, due to hardware differences. While testing indicates
acceptable performance on a "true blue" system, these have thus
far not been the typical systems used to run FX-BBS.

The program has been tested on a variety of other machines,
mostly clones again, ranging from XTs to AT clones and
inexpensive 386 systems. On some XT class systems, the program
fails for some as yet undetermined reason or another (it does NOT
fail on any XTs I have access to, so it will take a while to fix
this problem it seems). In the past, it has been tested with a
Hayes Smart Modem (external, 1200 baud), two Everex 1200 baud
modems and several other brand X types. Problems have been

- 15 -

FX-BBS Installation and User's Guide

encountered with a Racal Vadic Maxwell 2400V modem. It is only
sort of Hayes compatible. Their technicians advised me not to
use that particular modem for running a BBS, and suggested other
modems they manufacture as substitutes. In addition, the
particular modem in question may have had a problem. While a
Racal Vadic will work, the Maxwell 2400V it seems, is not the
best choice. The US Robotics HST modem was particularly
troublesome to set up, though once properly configured, it
generally functioned well. The Micom modem I have is somewhat
troublesome when used with DesqView. Not otherwise.

When running multiple telephone lines, it is necessary to
configure each line to use a different IRQ, and each UART must be
located at a unique port address. Many modems support only COM1
or COM2. Some allege support of COM3 and COM4, but in fact
cannot properly do so because either the IRQ or the UART port
address conflicts with those used for COM1 and/or COM2. Most
modems and serial adapter boards will support COM1 through COM4
properly, but caution should be used. However, very few boards
will support more than COM1 through COM4, a distinct problem when
attempting to run more than four telephone lines from a single
system. The Qua Tech company makes excellent serial cards, and
have one in particular for AT class systems which supports two
ports using NS16550 UARTs, any IRQ from 3 through 15, and
allowing the UART port address to be placed at any address.
These cards are NOT inexpensive however. Should you wish to
obtain such a board and cannot find it locally, please contact me
and I'll make one available at a reasonable cost. You must use
external modems with this particular board.

- 16 -

FX-BBS Installation and User's Guide

Setting up FX-BBS:

A batch file is provided with the distributed version of the
program to perform most of the decompression and setup chores for
FX-BBS, and greatly simplifies the process. While this batch
file (and the PKUNZIP program) performs most setup chores, it is
possible that problems can be encountered. This document
describes the process without the assumption of that batch file.

It is assumed that you will be installing the BBS onto a hard
disk, and drive C is used in the example here. You may use any
directory structure you wish, though the one shown here will work
and is in fact, the default directory structure assumed by the
BBS (refer to the FXBSETUP program). In any case, the
configuration file generated by FXBSETUP must agree with the
directory structure you provide.

A sample directory structure then might be as follows:


In this example, it is assumed that C:\FX-BBS will be the primary
operating path for the BBS. The programs FX-BBS.EXE,
with the FX-BBS.CFG file(s), should be placed into this
directory. As the FX-BBS program runs, other files will appear
here, including COMLOGnn.BBS (a different file for each copy of
the program running), which contains the inputs made by callers
when logging is turned on, FX-BBS.LOG, which will contain a
history of all callers, UPLOADS.DSC, which will contain
descriptions of any recently uploaded files, HISTORY.DNL, which
describes how many times particular files have been downloaded,
STATS.BBS, which contains statistical information about the
program's operation and is updated after each call, and your user
password file.

- 17 -

FX-BBS Installation and User's Guide

In this example, help files should be stored into the C:\FX-
BBS\HELP directory. As callers leave messages, they will be
placed, in this example, into the C:\FX-BBS\MESSAGES directory.
Finally, any text files you may require (menus, directory
listings, etc) should be placed into the C:\FX-BBS\TEXT
directory. If you wish to support ANSI.SYS graphics, then text
files with the same names as those in the C:\FX-BBS\TEXT
directory should also be placed into the C:\FX-BBS\GRAPH
directory. These duplicate files may contain special ANSI.SYS
graphics as you wish. The exact files to be found in both of
these directories are listed in the FXBSETUP program description
later in this document, under the subject of Caller Accessible

At least two other directories must also be specified, these
being the directory (or directories) from which downloadable
files are to be retrieved, and the directory into which uploaded
files are to be placed. These should be separate in name at
least, to allow for ease of maintenance of directory description
files. Examples for these are


You may create as many subdirectories under the C:\FILES
directory as you wish. C:\FILES is the *root* search directory
FX-BBS will search for downloadable files. All subdirectories
beneath the one specified are also searched until the file in
question is found. Since in this example, the UPLOADS directory
is a directory under C:\FILES, new uploads will be downloadable.
If you do not wish this, the uploads directory should not be made
a subdirectory of C:\FILES. Rather, it might be called

The FXBSETUP program allows for the specification of up to six
different root directories as containing downloadable files. You
could for example, have C:\FILES, D:\FILES, E:\FILES, F:\FILES,
G:\FILES and H:\FILES subdirectories, should you have that many
drives. A seventh drive/directory may be specified for use as
the uploads directory if necessary, and separate drives and paths
may be specified for each conference area (up to 20). While
smaller drives (under 32MB) are frequently preferable to keep
file fragmentation lower, some upper limit on the number of
different drives to search is necessary. To support a greater
number of drives than allowed by FX-BBS or very large drives, it
is recommended that the SpeedStore or VFeature programs be used.
These programs overcome the Dos limitation of 32MB per drive.
The Dos JOIN program might also be employed. Experiments with
early versions of Dos 4.0 were less than pleasant and I have not
tried it with newer versions. Compaq's MS-DOS 3.3 supports drive
partitions as large as you might wish, so you might want to look
at getting a copy of that. You do NOT necessarily need a Compaq
system to run Compaq's MS-DOS. The 350Mb of disk space on my

- 18 -

FX-BBS Installation and User's Guide

system is structured into a 20Mb partition for Dos related files,
a 32Mb partition for the BBS, door programs and mail related
files and programs, and then 91Mb and 210Mb partitions for
download areas.

Note that the names used for these directories are completely
arbitrary and can be anything you wish. The names used herein
are only examples. The complete example directory structure as
described here would be:

C:\FX-BBS\ - main working directory
C:\FX-BBS\HELP\ - help files directory
C:\FX-BBS\TEXT\ - non-graphics text files
C:\FX-BBS\GRAPH\ - ANSI.SYS graphics text files, as generated
by THEDRAW or other ANSI draw programs.
C:\FX-BBS\MESSAGES\ - all messages (also subdirectories)
C:\FILES\ - root directory 1 for downloadable files
C:\FILES\UPLOADS\ - directory for new upload files
D:\FILES\ - root directory 2 for downloadable files
E:\FILES\ - root directory 3 for downloadable files
F:\FILES\ - root directory 4 for downloadable files
G:\FILES\ - root directory 5 for downloadable files
H:\FILES\ - root directory 6 for downloadable files

Finally, remember that when you run the FXBSETUP program and tell
it what path names it is to use, you *must* enter a final
backslash after the directory name.

- 19 -

FX-BBS Installation and User's Guide

The FXBSETUP Program:

The program "FXBSETUP" is used to create, update or list the
configuration file required by FX-BBS. This configuration file
is an ASCII text file, read once at the start of FX-BBS. Since
the program may support multiple phone lines and be used on a
Local Area Network, the configuration file is stored separately
from the main executable program. Because it is an ASCII text
file, it is possible to edit it with a standard text editor (not
Wordstar), though this is NOT recommended. Each line contains an
ASCII string. This string should NEVER exceed 35 characters of
significant information. A line by line description of the
configuration file appears at the end of this document.

Starting FXBSETUP:

FXBSETUP is invoked with either three or four command line
options, with the syntax of "FXBSETUP option filename [ND]",
where "option" is either "CREATE", "UPDATE" or "LIST", "filename"
is the name of the configuration file to be used, and the
optional argument "ND" may be specified to prevent the program
from using direct screen writes (the bios is used instead). Your
first setup command then might be "FXBSETUP CREATE FX-BBS.CFG".
When you later wish to make changes to this file, you would enter

The "CREATE" option will first test to be sure the filename
specified does not exist, and if not, will proceed to allow you
to create a new configuration file. ***Default values exist for
most of the parameters required, though not all. The user ID
filename FX-BBS is to use MUST be specified***, and most other
parameters should at least be verified by you, particularly the
communications port and associated information the program is to
use, and the modem initialization string. The "UPDATE" and
"LIST" options require that a file exist before the program will

Two files are actually used by the FXBSETUP program. The primary
file is the one specified by you on the command line. The second
file is one called "STATS.BBS". This is a small file,
continuously used by FX-BBS as it runs, which contains the total
number of callers, and the total number of calls at each baud
rate (300, 1200, 2400, 4800 and 9600), along with a list of
several of the most recent callers. Generally, the values

contained in this file should not be changed by you, though some
are presented by FXBSETUP and may be, if for example, you are
converting from another BBS package and wish to keep the old
program's values.

- 20 -

FX-BBS Installation and User's Guide

While a path may be specified for the primary file FXBSETUP is to
operate on, FXBSETUP assumes the STATS.BBS file to be located in
the current directory. It is therefore recommended that you only
run the FXBSETUP program from the BBS directory.

FXBSETUP first presents you with a list of fifteen sub-screens
which organize the information appropriately and may be selected
for editing. This screen appears roughly as follows:

FX-BBS Configuration File Editor

A. Initialization Parameters
B. Caller Access Levels
C. Paths to BBS Files
D. Mail System Parameters Screen 1
E. Mail System Parameters Screen 2
F. Mail System Parameters Screen 3
G. Conference Parameters
H. Door Parameters
I. External Protocol Parameters
J. Color Parameters
K. Illegal Caller Inputs
L. Miscellaneous Parameters 1
M. Miscellaneous Parameters 2
N. System Parameters
O. Function Key Assignments

Enter Number of Screen to View: _

to Terminate


A sub-screen may be selected for viewing by entering the screen
designator, A through O. To move around each of the sub-screens,
use the cursor up and cursor down keys. To leave any screen,
depress the Escape key. The sub-screens are described on the
next several pages.

- 21 -

FX-BBS Installation and User's Guide

FXBSETUP Editing functions:

Limited error checking is provided by FXBSETUP. I'll say that
again: the error checking is LIMITED, and it is very possible to
enter invalid parameters in many fields, so use care.

"Insert" mode is nominally selected for each field, and may be
toggled with the insert key.

The DEL and backspace keys function as expected.

The "CTRL-A" key combination clears the field to the right of the
current cursor position, including the current cursor position.

The CTRL-X combination clears the entire field.

Many ASCII fields may be entered in upper and lower case. The
Y/N fields will force upper case. While not forced, the modem
output strings should also be entered in upper case only, since
some modems require these fields to be upper case. Some modems
also have a restriction relating to mixing upper and lower case
letters in command strings.

- 22 -

FX-BBS Installation and User's Guide

Screen A. Modem Parameters

This screen and the default values appear as follows:

Initialization Information

Modem Port Number: 2
I/O Reg Address: 0x02f8
Interrupt Vector: 0x0b
Interrupt Mask: 0xf7
IRQ Number: 3
Internal Comm (Y/N)? Y
Modem Initialization String: AT&FS0=1S2=255V1X1&D2&C1&T5E1Q0
Modem Off Hook String: ATH1S0=0M
Modem On Hook String: ATHS0=0M
Minimum Baud Rate Allowed: 300 RECOMMENDED MODEM PARAMETERS:
Maximum Baud Rate: 2400 (* - See Documentation)
Auto Baud Rate Detect (Y/N)? Y I/O: IRQS: MASKS:
Maximum Idle Time in Seconds:180 (Com1:) 0x03f8 4 0xef 0x0c
Printer On Default (Y/N)? N (Com2:) 0x02f8 3 0xf7 0x0b
Sysop In Default (Y/N)? N * 5 0xdf 0x0d
Log File On Default (Y/N)? Y (XT only) * 2 0xfb 0x0a
(AT only) * 9 0xfd 0x71

String to Display at Log Off: Leave Comment for the SYSOP (Y/N)?

Depress Cursor Up, Cursor Down, or Escape for Previous Screen


The default COM port number is selected as 2, since many users
will be using COM1 for other purposes. A value from 1 to 8 may
be specified. The COM port number is in fact, largely unused by
FX-BBS for actual communications setup, though it is used to a
limited degree and so should be accurate. The next four
parameters are what really govern communications setup.

Generally, the I/O Register Address used for COM1 is 0x03f8, and
that used for COM2 is 0x02f8. For COM3, address 0x03e8 is often
used and for COM4, address 0x02e8. Refer to your modem's
documentation to clarify which com port you should specify.
There is also a special section at the end of this document which
discusses these parameters in more detail than you probably want.
Refer to that section when installing more than two modems in a
particular system, or when necessary to deviate from the little
chart displayed on this setup screen in the area under the

- 23 -

FX-BBS Installation and User's Guide

FX-BBS does not generally use DOS support for communications
processing. Dos does not support transmission rates above 9600
baud, nor does it support more than two COM ports typically.
FX-BBS does support both of these, with baud rates up to 38400
and an unknown upper limit on the number of modems (this number
is governed primarily by the number of available IRQs, and
whether or not your communications hardware can support them).
The interrupt vector, IRQ number and Interrupt mask should be set
appropriately to the values displayed under the title
"RECOMMENDED SETTINGS". If you have unique requirements, these
values may be overridden as required, though this is not
generally recommended. Again, see the special section devoted to
discussing this matter later in this document.

I said above that FX-BBS does not generally use DOS support for
communications, but under some circumstances, it will. When the
COM port number to be used is either 1 or 2, and when ALL
parameters associated with that COM port are set to the default
(normal DOS) values described on the setup screen, and when the
maximum baud rate is set to 9600 or less, and finally, when
Communications Optimization (described on Screen L) is set to
zero (off), FX-BBS will use DOS to initialize the COM port. This
is done to help assure compatibility with some older XT systems.
Deviating from these settings in any way will, however, cause
FX-BBS to NOT use DOS to initialize the COM port.

Much experimentation has been made with the modem initialization
string. The default string presented is the result, and
represents a complete re-initialization of the modem after each
call. For those of you with manuals that do not describe the
complete set of Hayes parameters, "&F" directs the modem to re-
load the factory operational profile; "S0=1" tells it to answer
on the first ring; "S2=255" changes the modem escape character
from "+" to something more difficult to come by; "V1" tells the
modem to send back "verbose" results; "X1" also relates to having
the modem send back "verbose" results; "&D2" indicates that the
modem is to track DTR and disconnect and disable auto answer when
loss of DTR is detected; "&C1" indicates that the modem is to
track the state of the remote modem and turn the DCD signal
on/off accordingly; "&T5" tells the modem not to accept commands
from the remote modem; "E1" requests the modem echo back command
characters; and finally "Q0" requests the modem send back result

- 24 -

FX-BBS Installation and User's Guide

Many Hayes and Hayes compatible modems do not support the "&xx"
set of commands. The "&xx" commands were added by Hayes some
time back and take the place of the external dip switches. In
this way, they are under software control. Switches on the Hayes
1200 baud external modem should be set to 1 - Up, 2 - Up, 3 -
Down, 4 - Down, 5 - Down, 6 - Up, 7 - Up, 8 - Down.
Specifically, DTR must *not* be forced on, nor should CTS be. If
your manual does not list the "&xx" commands, you should not use
them. This may reduce the chances of FX-BBS functioning with
your modem, though there should be no problem if you configure
the dip switches appropriately. Experimentation on your part
here, may be required. If your modem supports hardware flow
control, this would best be enabled, and is required by most
modems operating at 9600 baud or above, or that support MNP-5.

Many modems have some of these settings as defaults. My own
experience indicates that I should not always trust this, hence
the complete re-initialization of the modem. (If you do not use
the modem for more than one purpose, you might instead save modem
initialization information in nonvolatile ram if your modem has
such. In this case, the modem initialization string can be
simply "ATZ".)

Note too, that no more than 35 characters may be specified on the
modem initialization line. Upper case only is recommended. The
Everex modems seem to require upper case only. If more than 35
characters are necessary, you may break them up and enter
selected parts with the modem onhook string. This string is
always output prior to the modem initialization string. When
testing with an Everex internal 2400 baud modem on a particular
generic clone, we found it necessary to configure the modem on-
hook string to be "AT&FS0=0M0H0" and the modem initialization
string to be "ATS0=1S2=255V1X4&D2&C1E1Q0". Note that spaces are
not required. I do not recall exactly why this was the
configuration we went with... Most likely, we approached a
recalcitrant modem much as you would: Work with it and work with
it, until it starts working. Then leave the thing alone!

Control characters, such as a carriage return, may be imbedded in
the control string by first entering the "^" character, and then
entering the letter of the alphabet corresponding to the code
desired. A carriage return is a decimal byte value of 13, which
corresponds to the letter "M". To enter a return then, you would
type "^M". Note that this is not required at the end of the
line. A return is automatically sent at that point.

- 25 -

FX-BBS Installation and User's Guide

For HST modems, it seems better to use a terminal program to
initialize the modem's settings and save them in NRAM. In this
case, no modem initialization string should be specified, the
modem onhook string (output before the modem initialization
string) should be set to ATHS0=1^MATZ, and the modem offhook
string to ATH1M.

The modem on hook and off hook strings are used when you log onto
the BBS from the local keyboard, or when you invoke another
program using the ALT-F1 or ALT-F2 keys and no caller is online.
Typically, "H1" takes the phone off hook, and "H" places it back
on hook. The "M" turns the speaker on and off. Should usage of
these functions prove to be a problem, the strings may be
replaced with the word "NONE", which must be capitalized. Note
that the modem onhook string is always output prior to the modem
initialization string. This means that, should you wish, you can
put modem initialization information in the onhook string, should
you have more to specify than will fit into the modem
initialization string.

Minimum Baud Rate Allowed: This flag indicates the minimum baud
rates accepted by your system for new callers. Note that this
parameter effects only *new* callers. In a pinch, existing users
might be able to use lower baud rates if necessary. Only callers
whose names are not in the user file will be precluded. These
will be politely disconnected. Note that 300 baud callers can
effectively be excluded completely by setting the 300 baud time
limit to 1 (see the next setup screen).

The maximum baud rate field should be set to the highest baud
rate your modem allows. If you are "locking" your baud rate at
either 19200 or 38400, you should enter that value. Five baud
rates are reported by FX-BBS presently, 300, 1200, 2400, 4800 and
9600. Most modems supporting baud rates of greater than 9600
(well, the HST at least) report 9600 regardless of what the
higher rate might be. (The Courier HST can communicate with
callers at bit rates of up to 14,400 bps. With their data
compression, this sometimes can hit as high as 25,000 bps, more
with the recently introduced V.42bis capability. The HST can be
configured to "lock" the baud rate at 19,200 or 38,400 bps,
however, these faster rates refer to the speed at which the modem
talks to the computer it is being used on, *not* to the speed the
caller is connected at. All calls at 9600 bps or greater are
reported by the HST as 9600 baud calls.)

- 26 -

FX-BBS Installation and User's Guide

The Auto Baud Rate Detect field should be set to "Y" when the
default modem init string is used. This will cause the program
to look for the strings, "CONNECT", "CONNECT 1200", "CONNECT
2400", "CONNECT 4800" and "CONNECT 9600" to be returned from
your modem, and when one of these is found (or something close),
FX-BBS will immediately begin conversing with the caller. If for
some reason this does not function well with your system, you may
set this field to "N". When this is done, the modem
initialization parameter "X1" should be changed to "X0", "V1"
should be changed to "V0", and "Q0" should be changed to "Q1".
In this case, the caller will be required to depress return a few
times at log on for FX-BBS to determine the caller's baud rate.

The Maximum Idle Time is the number of seconds the program should
wait for a caller to do something before disconnecting the
caller. A value of 180 then is three minutes. After this amount
of time, the program will output a message to the caller telling
them that they are being disconnected due to inactivity on their

The printer may be turned on/off as FX-BBS is in operation, by
using the ALT-P key combination. When the printer is on, *all*
BBS activity will be echoed to the printer. This is not
generally a good idea, since it can go through an awful lot of
paper, and when the printer buffer or spooler is backed up, the
BBS will begin operating in a somewhat jerky manner as the
program waits for the printer to be ready. The default value for
this should then be off, though you can turn it on if desired.
To output a "Top of Form" to the printer when the printer is on,
type a CTRL-L (hold down the CTRL key and depress the letter

Similarly, the availability of the SYSOP for chats may be toggled
as the program operates by using the ALT-S key combination. You
may however, default the SYSOP available flag to on or off.

The ALT-L key combination may be used during the BBS's operation
to turn on/off logging of caller's inputs to the file
"COMLOGxx.BBS" (where "xx" refers to the system number). This
file contains a summary of the time and input made by each
caller, and includes the numbers of bulletins the caller read,
files uploaded/downloaded, etc. I generally run with the log
file on, hence the default for this field is "Y". If you too run
with this file on, keep an eye on it. Over a week or two, it can
grow quite a bit, though never larger than 64K. FX-BBS watches
the file and will drop the oldest data when the file becomes too
large. For reasons of speed and space however, users attempting
to run the BBS from floppy only should not run with this option

- 27 -

FX-BBS Installation and User's Guide

Finally, the "String to Display at Log Off" will be displayed
after a caller enters "g" for goodbye, and before soliciting a
comment from said caller. It may be specified here so that you
can customize it. Primarily, you would replace the word SYSOP
with your own name. You could of course, put an entirely new
string here, such as "Did you have a good time? Leave a comment".
Anything you want...

- 28 -

FX-BBS Installation and User's Guide

Screen B. Caller Access Levels

This screen and its default values appear as follows:

Access Level and Caller Information

Access Time Limits Upload/Dnload Max Dnload Max Calls
Level: in Minutes: Ratio: KB Per Day: Per Day:

* 1: 45 0 0 1
2: 75 15 500 3
3: 90 20 1000 5
4: 120 30 5000 99
5: 150 40 9999 99
6: 180 50 9999 99
7: 210 999 9999 99
8: 240 999 9999 99
** 9: 240 999 9999 99
***10: 280 999 9999 99

Time Limit for 300 Baud Callers: 0 (0 = N/A)

Access Level for New Callers: 1

Closed BBS (Y/N)? N

Subscription BBS (Y/N)? N Drop Level: 1

* = New Caller Level,** = Assistant SYSOP Level,*** = SYSOP Level

Depress Cursor Up,Cursor Down, or Escape for Previous Screen


Eleven access levels are available for assignment to callers.
The access level is generally modifiable from the SYSOP menu of
the BBS, or via the EDITUSER program. Callers with access level
1 cannot download, upload, enter or kill messages, nor can they
look at the BBS statistical information. Generally, this access
level is reserved for new callers in a BBS that would require
callers to register (leave name, address, phone number, money,
etc). For BBSs allowing an immediate access level of 2 or
higher, an access level of 1 can still be given to folks to limit
their access if necessary. Callers with access level 1 are
presented with a file called "LEVEL1.TXT" if it exists. The only
other access levels I generally assign callers are 2 (regular
users), 3 (users who've made substantial uploads), 4 (users who
have contributed money for the phone bill, etc) and 8 (other
SYSOPs). Note too that callers assigned access levels 5 and
above are unaffected by any specified upload to download ratio.

- 29 -

FX-BBS Installation and User's Guide

Access level 10 is reserved for the SYSOP. ANY CALLER WITH
BBS! Use extreme care in assigning other callers an access level
of 10! Callers with access level 10 who log on under a name
other than that specified for the SYSOP, can view comments,
change access levels, add files, etc. They cannot delete files
however, nor can they execute Dos commands (such as dir, copy,
erase and so on). Many functions are reserved only for the SYSOP
when that person has logged on under the correct name and has the
correct access level. Other functions can be performed only by
the master SYSOP in local mode (not from remote at all). The
intent is not to make the SYSOP's life hard, so much as to
prevent the possibility that the SYSOP's hard disk might
accidentally be reformatted in the middle of the night (it has
been known to happen with some BBS programs).

Access level 9 is for any assistant SYSOPs you may have. Persons
with this access level can read comments, add files to the upload
directory, "show" private files, read private messages, add
callers to private conferences, and change caller access levels
in the range of 1 or 2. While they can change the access level
of any person regardless of their previous access level, they
cannot delete users or files, nor can they see any passwords.
They also cannot execute Dos commands from remote. If you desire
to give others such access to your system, you may set up a door

Access level 11 is reserved for banned users. Anyone calling who
has this access level will be notified immediately that they have
been denied access, and then will be disconnected.

Access level 11 should not be used without thought. Once you get
into a contest with a caller, other problems can arise. The
caller in question can always start making up names and logging
on. How would you like to have 400 new users one morning? Or
you may begin getting calls in the middle of the night on your
voice line, from anonymous modems, as I did. Of course, I knew
who was doing it, and threatened to have the police discuss the
matter with that person's parents. If I had not required user
registration at that time, I might have been a bit further up the

- 30 -

FX-BBS Installation and User's Guide

Should you wish *not* to require caller registration, you may
specify an access level of other than 1 for new callers. New
callers will then have complete access to your BBS. Why require
users to register? We all know what a pain it can be when a BBS
imposes this requirement. I have done it in the past, for two
reasons. Often, the BBS phone lines I have are continuously
busy. Some callers complain that they can't get through very
often. Requiring registration then, acts as a governor of sorts
in that it helps limit the number of callers. Secondly, by
requiring the names, addresses and phone numbers of callers, I
feel that trojans are much less likely to be uploaded. You'll
note that when new files are uploaded, the name of the
contributor is listed along with the file name, so everyone will
know where the file came from. This too, helps prevent at least
deliberate trojans, and also I think, gives the person who
uploaded the file a nice feeling. Recently, I dropped
registration requirements from BerthaBoard for several months,
with few ill effects. However, after a time, I did begin getting
lots of callers logging on under several different names (you can
usually tell when this is going on... caller's who've never
logged on before for example, suddenly call and download the
exact file the previous caller couldn't due to insufficient time,
without first looking for it). When one particular caller became
abusive, telling me I wasn't doing enough for him and demanding I
do more (I do not charge a fee to access my system), I decided it
was time to go back to a registration scheme (though the
registration scheme I introduced is a mere formality). I prefer
callers use their real names. Often it seems, callers do not
want to do this on a system that does not require registration.
Another minor problem is that folks will sometimes logon with a
second name when their time has run out.

Downloads can be restricted in a manner in addition to the
upload/download ratio. A maximum number of kilobytes
downloadable in a given 24 hour period must be specified for each
access level. This parameter has a range of from zero to 99999
(almost 100 Mb). This parameter *must* be specified for each
access level! That is, there is no way to disable it.

Specifying a nonzero value for the Time Limit for 300 Baud
Callers field will override any other time limit a caller might
be given, when that caller calls at 300 baud, and the caller is
not the SYSOP. For example, if this field were set to 30 and a
caller with access level 3 calls at 300 baud who would normally
be allowed 180 minutes, he will instead, be given 30 minutes. If
this field were set to zero, he would still be given 180 minutes.
If he calls back at a faster baud rate, the 300 baud time limit
would no longer be in effect. Note too, that in the event of
uploads, 300 baud callers will still be credited any bonus time

- 31 -

FX-BBS Installation and User's Guide

Answering "Y" to the "Closed BBS" question causes the BBS not to
accept any new users, that is, users not already in the user
list. In this situation, only the SYSOP may add callers to the
access list by using the EDITUSER program.

The final parameters on this screen relate to using the program
to support a subscription BBS. When you answer "Y", callers
logging on are checked to see if they have subscribed. If they
have and their subscription has expired, they are notified of
this fact (the caller's record in the user file must contain the
date of the subscription expiration. This can be entered using
the EDITUSER program described elsewhere).

If a caller's subscription has expired, their access level is set
to that specified in the last parameter, the "Drop Level".

- 32 -

FX-BBS Installation and User's Guide

Screen C. Paths to BBS Files

This screen appears as follows:

Caller Accessible Paths

Download File Path 1: C:\FILES\
Download File Path 2: D:\FILES\
Download File Path 3: NONE
Download File Path 4: NONE
Download File Path 5: NONE
Download File Path 6: NONE
Upload File Path: D:\FILES\UPLOADS\
Message Section Path: C:\FX-BBS\MSGS\
New Uploads Public (Y/N)? Y
Number of Directory Files: 18

Bulletin Board System Paths

Normal Text File Path: C:\FX-BBS\TEXT\
Graphics Text File Path: C:\FX-BBS\GRAPH\
Help File Path: C:\FX-BBS\HELP\
BBS Operating Path: C:\FX-BBS\

Depress Cursor Up, Cursor Down, Return/Escape for Previous Screen

Note that in each of the above cases, the specified paths begin
with a drive letter, which is followed by a colon and a
backslash. Each path also ends with a backslash. Each of these
is absolutely required!

Up to six download file paths may be specified. These paths are
the *root* directories FX-BBS will search when a caller issues
the "Upload", "Download", "Whereis" and "NewFiles" commands.
Note that not only will these six paths be searched, all sub-
directories within these paths will be searched as well. For
example, if under the directory C:\FILES\ there were sub-
directories called GAMES, COMM, UTILS and PROGRMNG, then *all* of
these directories will be searched when looking for a given file.
Use care with the number of directories you create below a root
search directory, since this can have some effect on the speed of
the file searches. Note too that for Upload and Download
functions, the search stops as soon as any one matching file is
located (including when wild-cards are used).

- 33 -

FX-BBS Installation and User's Guide

By providing six such download file paths, up to six devices may
be specified as containing files which are public (more are
possible by employing conferences... refer to the appropriate
setup screen). If you require fewer than six, you must fill the
unused paths with the capitalized word, "NONE". Unused paths
containing this word will be ignored. If for some reason, you
require more than six devices to support downloadable files, you
might implement this feature using the MS-DOS "join" command, or
investigate the SpeedStore or VFeature programs, which support
devices larger than 32MB, as dos Compaq's MS-DOS 3.31 and generic
MS-DOS 4.01 (this latter product still exhibits a few problems
here and there however). It is generally recommended that no
more than one download accessible path be provided per device.
Note too that the Upload File Path can be set to a seventh root
directory, and that up to 20 additional root search directories
may be specified through the use of conferences.

Usage of floppies for downloadable file storage is NOT
recommended, since if you should forget to close the floppy drive
door, it can result in the message, "ABORT, RETRY, IGNORE?".
None-the-less, it would be possible to define paths of
"C:\FILES\", "D:\FILES\", "A:\" and "B:\", in which case the
floppy drives would also be searched for downloadable files.

Note that FX-BBS will search the paths specified in the order
listed. First path 1, then path 2, then path 3, path 4, path 5,
and finally path 6. However, if any conference paths are
specified on the conference screen, those will be searched first,
on the assumption that conference areas will contain fewer files
and subdirectories than the others.

The Upload File Path is where FX-BBS will place all newly
uploaded files. This path may be a subdirectory contained in one
of the download accessible paths, in which case callers will be
able to download the files contained therein. Alternatively, if
this path is *not* within one of the download file paths, callers
will not be able to download recently uploaded files. See also
the Public Uploads flag on screen A.

The Message section path will also be accessible by callers, in
the sense that all message files will be stored here. This
should generally be a separate path from any others. Up to 80
message files may be found here, one for each message section
implemented. These files are named SEC01 through SEC80, as
required. The FXREPACK program also creates temporary files
here, with the same name as the message section file, plus an
extension of ".TMP". Should any of these files be left on your
disk by accident, they may be deleted.

- 34 -

FX-BBS Installation and User's Guide

Newly uploaded files may be made public or not. Two parameters
relate to this. This flag essentially tells the program whether
or not to show callers data contained in the upload directory
area. However, the upload file path, described above, *must* be
within one of the download file paths in order to be accessible.
Conversely, if the upload directory *is* within a download file
path, files therein *will* be downloadable, whether this flag is
set to "Y" or "N".

The initial value of the Number of Directories field is an
accident at 18. This parameter perhaps would be better placed on
one of the other screens, or even deleted.

The remaining paths on this screen are generally accessed by the
BBS to support callers.

The Normal Text File Path contains all standard text files used
by the program. By standard text files, I mean those which do
not include ANSI.SYS type command strings. ANSI.SYS files should
be stored in the Graphics Text File Path. At logon, the user is
asked whether graphics are desired. If yes, FX-BBS will use
files stored in the Graphics text file path. If no, the Normal
text file path will be expected to contain the necessary files.
If you do not wish to supply special and separate ANSI graphics
files, you may enter the same path for both the Normal and
Graphics text file path parameters.

When these files are output, they are simply "typed" to the
caller's screen. Files are read into an internal buffer in
8Kbytes chunks, and then output a character at a time. As little
processing as possible is performed, but efforts at detecting
ANSI escape sequences which might be present are made to help
prevent at least serious problems on the local screen. Note too
that the program watches for a reserved character string,
"//PAUSE". When this string is encountered, it is not displayed.
Instead, the system will pause output and ask the caller whether
they wish to continue (a Y/N/C sort of prompt).

If you set both paths to the same subdirectory, the same files
will be used, and graphics will effectively be disabled. The
following files must be contained in the Normal Text File Path,
and if graphics are used, should be duplicated (in name at least)
in the Graphics Text File Path (sample files are provided in the
shareware distribution package):

- 35 -

FX-BBS Installation and User's Guide

WELCOME.TXT - This file is displayed to callers after they've
answered the question regarding whether they want graphics.
It is the first file displayed and must be present.

LEVELx.TXT - These files will be displayed at logon to any
caller if found to exist. The lower case x in the file name
corresponds to the caller's access level, and ranges from a
"1" to a "10". These files should indicate the caller's
access level, time limit, any upload or download ratios in
effect and so on. The file "LEVEL1.TXT" should also explain
what callers with an access level of 1 must do to gain system
access. Requirements for different access levels, etc. might
also be specified here. The "LEVELx.TXT" file is the first
displayed after WELCOME.TXT. Callers cannot abort the
output of LEVELx.TXT files by entering CTRL-C.

NEWS.003 - News text files will be displayed for the caller
whenever a file's date is found to be newer than the date the
caller last called (provided the file exists). These files
are displayed following display of the appropriate LEVELx.TXT
file. Up to 20 such files may be provided as required, with
names ranging from NEWS.001 to NEWS.020. Callers cannot
abort output of the files at this point by entering
a CTRL-C. These files are also viewable from the main menu
by entering the "!" command. When viewed from the main menu,
callers can enter CTRL-C to abort their output.

NOTICE.TXT - Another news sort of file, this one though will
always be displayed if found to exist. This file is
displayed following output of the NEWS.TXT file. It cannot
be aborted by the caller via CTRL-C. - Bulletin processing is performed following
output of the NOTICE.TXT file, or when the caller selects the
bulletin function from the main menu. The file
"BULLETIN.000" is required to contain a list of all other
bulletins available for caller selection, and is output
whenever the caller wishes to list the available bulletins.
When the caller enters "1", the file "BULLETIN.001" will be
displayed. When the caller enters "8", the file
"BULLETIN.008" will be output and so on. Up to 99 bulletin
files may be provided.

- 36 -

FX-BBS Installation and User's Guide

NEWMENU.TXT - These are all main menu files. All options
available are to be described herein. It will be output
repeatedly, followed by the main command line, and is output
after bulletin processing is completed at caller logon. The
file, "SYSOP.TXT" is also the main menu, and is displayed
when the caller has an access level of 9 or 10. In addition
to the standard functions available, it should should also
list the functions available to the SYSOP. The file
"NEWMENU.TXT" will be output when the caller has an access
level of one. It is provided so that those functions which
are not available to callers with this access level can be
omitted from the menu.

SYSOP7.TXT - This is an optional menu which if present, will
be displayed when the SYSOP enters the BBS maintenance area
by selecting "7" from the main menu. If not found, a built-
in list describing options available will be output.

CONF.TXT - This is the primary conference description file,
and should list the conferences available, along with some
indication of whether they're private.

CONF20.TXT - Text files describing each of the

DIR0 - This file should describe all subdirectories available
on the BBS. It will be output when the caller enters "F"
from the main command line, to view the files.

DIR1, DIR2, DIR3, DIRx - After FX-BBS has displayed DIR0,
it will ask the caller to enter the directory number to
view. If 1 is selected, FX-BBS will present the caller with
the file called DIR1. If 2 is entered, the file DIR2 will
be displayed, and so on. Up to 98 DIRxx files may be
offered. DIR99 (or the last dir, be it 19 or 45 or 77) is
reserved for recent uploads. In fact, the recent uploads
directory will be output any time a caller enters the number
of a nonexistent directory file, or when they enter the
number of a directory file belonging to a conference which
they are not a member of.

- 37 -

FX-BBS Installation and User's Guide

DOOR.TXT - This is a text file describing any doors you may
have available.

GOODBYE.TXT - An optional file, if present, will be displayed
when the caller logs off.

Two other paths remain to be described. The Help File Path
contains more standard ASCII text files (without graphics).
Lastly, the BBS Operating Path is used to contain the files
UPLOADS.DSC (upload description file), FX-BBS.LOG, which lists
the date, time and caller name and is processed by the
statistical sub-function, the STATS.BBS file, files called
COMLOGxx.BBS, which list all inputs made by a caller when call
logging is turned on (xx refers to the system number. A
different COMLOGxx.BBS file is maintained for each copy of the
program running), and the file containing the caller names and
passwords. This last file must be named by you. It is not hard-
coded, in the interest of security. There once was (or still is)
a program running around called "DROIDS.ARC". This program
purports to be a game, and gives the appearance of almost
functioning. If run on a PCBoard BBS system, it copies the user
password filename to a file which can then be downloaded. Not
very nice, huh? This is the type of problem we're trying to
avoid here. Also to be found here are files named QUESTION.BBS
and QUESTx.BBS. Up to 6 questionnaire files can be provided, and
each can contain up to 25 questions. The "x" in the filename
must be one of the letters "A" through "F". The questionnaires
are listed for the callers in the file QUESTION.BBS.

- 38 -

FX-BBS Installation and User's Guide

Screen D. Mail System Parameters Screen 1
Screen E. Mail System Parameters Screen 2

The first Mail System screen and default parameters appear more
or less as follows:

Mail Section Information Part 1
Number of Mail Sects (1-80): 1 SYSOP Only to Delete Msgs (Y/N)? N
Section Name: Echo Flag (L/E/N): Section Name: Echo Flag (L/E/N):
Sec 01: General Mail L Sec 21: NONE L
Sec 02: NONE L Sec 22: NONE L
Sec 03: NONE L Sec 23: NONE L
Sec 04: NONE L Sec 24: NONE L
Sec 05: NONE L Sec 25: NONE L
Sec 06: NONE L Sec 26: NONE L
Sec 07: NONE L Sec 27: NONE L
Sec 08: NONE L Sec 28: NONE L
Sec 09: NONE L Sec 29: NONE L
Sec 10: NONE L Sec 30: NONE L
Sec 11: NONE L Sec 31: NONE L
Sec 12: NONE L Sec 32: NONE L
Sec 13: NONE L Sec 33: NONE L
Sec 14: NONE L Sec 34: NONE L
Sec 15: NONE L Sec 35: NONE L
Sec 16: NONE L Sec 36: NONE L
Sec 17: NONE L Sec 37: NONE L
Sec 18: NONE L Sec 38: NONE L
Sec 19: NONE L Sec 39: NONE L
Sec 20: NONE L Sec 40: NONE L
Depress Cursor Up, Cursor Down, or Escape for Previous Screen

- 39 -

FX-BBS Installation and User's Guide

The second Mail System screen differs only slightly:

Mail Section Information Part 2
Max Lines per Message (1-798): 99
Section Name: Echo Flag (L/E/N): Section Name: Echo Flag (L/E/N):
Sec 41: NONE L Sec 61: NONE L
Sec 42: NONE L Sec 62: NONE L
Sec 43: NONE L Sec 63: NONE L
Sec 44: NONE L Sec 64: NONE L
Sec 45: NONE L Sec 65: NONE L
Sec 46: NONE L Sec 66: NONE L
Sec 47: NONE L Sec 67: NONE L
Sec 48: NONE L Sec 68: NONE L
Sec 49: NONE L Sec 69: NONE L
Sec 50: NONE L Sec 70: NONE L
Sec 51: NONE L Sec 71: NONE L
Sec 52: NONE L Sec 72: NONE L
Sec 53: NONE L Sec 73: NONE L
Sec 54: NONE L Sec 74: NONE L
Sec 55: NONE L Sec 75: NONE L
Sec 56: NONE L Sec 76: NONE L
Sec 57: NONE L Sec 77: NONE L
Sec 58: NONE L Sec 78: NONE L
Sec 59: NONE L Sec 79: NONE L
Sec 60: NONE L Sec 80: NONE L
Depress Cursor Up, Cursor Down, or Escape for Previous Screen

These two screens will be discussed together here. Each message
may be up to 798 lines long, as specified on screen 2 above. I
generally allow 200 lines, though as few as 20-30 is fine, and as
many as 798 may be allowed (64Kbytes messages). This option then
helps limit the amount of space used to house these files, which
might be desired on systems with smaller amounts of disk space.
One reason not to allow them to be too large relates to echomail:
many systems running other BBS programs cannot handle messages
greater than about 10 - 16Kbytes in size.

The default message input buffer is used for many other purposes,
including uploads and downloads, and has a minimum size of
approximately 8,500 bytes. When you indicate a maximum message
size of less than 99 lines, it has no effect on memory
consumption: not less than 8,500 bytes will be reserved, again
because the buffer is used for other purposes. However, when you
specify a maximum number of lines greater than 99, greater
amounts of memory will be required (but see the next paragraph).
The size of this buffer will be equal to the number of lines
specified times 82, the number of characters FX-BBS allows for
processing each message line. Specifying 798 lines causes almost

- 40 -

FX-BBS Installation and User's Guide

64Kbytes additional memory to be required for FX-BBS to run. A
value of 600 lines requires some 49Kbytes, and a value of 300
lines needs about 24Kbytes. If this much memory cannot be
allocated, the program displays an alarm and terminates.

Note that the memory used for message processing is released
prior to processing door programs or external file transfer
programs. That is, for the purpose of determining memory
available for doors and external transfer programs, add to the
amount of memory displayed in the status area a value equal to
the number of message lines times 82.

Up to 80 mail sections are allowed. The name of each section is
specified here, with the number of sections described here
telling FX-BBS how many of the names are valid for non-conference
members (conference area message sections are not restricted to
the number specified here). The default values for example,
provide 11 names, and indicate 11 sections. The first 40 names
are displayed on Mail System Screen 1, and the second 40 on Mail
System Screen 2.

The names of the sections are generally somewhat arbitrary. The
exceptions for this are for EchoMail and NetMail message sections
(when you are processing EchoMail that is). The NetMail message
section must be named simply "NetMail" (note that there is no
space; NetMail is *one* word). EchoMail section names must begin
with the "AREA:" parameter of the particular echo in question.
If the echo is called "HUMOR", then that must be the first word
appearing in the message section name. If it's the "C_ECHO" then
that phrase must be the first appearing in the section name.
Note that the message section name need not be capitalized, and
that words may appear after the AREA specification. For example,
the AREA: parameter for the "Doctor Debug" echo is "DR_DEBUG".
For FX-BBS, the first phrase must be that. It may however be
mixed case, and have words following, such as "Dr_Debug Echo".

The echo flag provided on these screens should have one of six
values: "L" indicates to the program that the message section is
a local message section only. It is used only on your particular
BBS. "E" indicates the message section contains echo messages,
and "N" indicates that the message section in question is the one
used for Net Mail. There should not be more than one NetMail
section, and when running a system capable of echomail, there
*must* be a NetMail section! This is required since FXMAIL will
place any incoming messages which have "AREA:" specifications it
cannot find into the NetMail section.

- 41 -

FX-BBS Installation and User's Guide

The remaining three parameters are lower case versions of the
first three ("l", "e" and "n"). The effect of entering the flag
in lower case is to cause the message section to become private
to the SYSOP and any persons with Assistant SYSOP privileges.
Often, echoes are available which are reserved for SYSOPs only.
Using lower case letters to indicate a private message section
isn't the clearest way of dealing with this, but does serve to
keep the size of the configuration file (already quite large)

CONFERENCE (presumably, these conference members will have paid
for the privilege of sending NetMail messages).

The last parameter to discuss on these screens is the flag,
"Allow SYSOP Only to Delete Messages (Y/N)?". If this is set to
"Y", then a caller's attempt to delete a message will simply set
a flag indicating that an attempt has been made to delete the
message. The SYSOP must then delete the message manually later,
or wait for FXREPACK to purge the message. If this flag is set
to "N", then when a caller tries to delete a message, the message
*will* be deleted.

- 42 -

FX-BBS Installation and User's Guide

Screen F. Echo Mail Destination Nets/Nodes

The Echo Mail Destinations screen and default parameters appear
more or less as follows:

Echo Mail Destination Nets/Nodes, Purge Levels
Sections 01-20: ³ Sections 21-40: ³ Sections 41-60: ³ Sections 61-80:
Net Node Fl Prg ³Net Node Fl Prg ³Net Node Fl Prg ³Net Node Fl Prg
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50 ³ 0 0 DC 50
Depress Cursor Up, Cursor Down, or Escape for Previous Screen

Apologies for creating such a horribly cluttered screen. This is
another screen where there are too many parameters (320) to allow
much in the way of clarifying comments. The parameters are
arranged in groups of four. The first four horizontal parameters
relate to message section 1. The four beneath that relate to
message section 2, the four beneath that to section 3 and so on.
The screen is organized into four columns, with the first column
relating to message sections 1 through 20, the second column to
sections 21 through 40 and so on (as described on the second line
of the screen). You'll likely have to do some counting to
properly determine which line you wish to modify. For message
section 55 for example, this would be 15th set of parameters in
column 3. Geez... I'll have to do something about this screen
sooner or later. Sorry again. I would not normally design a
screen such as this. The FXBSETUP program as presently designed,
however, is "against the wall" for memory. Correcting this
problem will not be trivial.

- 43 -

FX-BBS Installation and User's Guide

There are a total of 80 message sections possible, and this
screen is used to specify where each of them originates from
and/or has output sent to. That is, the system which is your
source for the echo. Not all message sections will likely be
echo mail message sections. Presumably, at least one message
section will be reserved for netmail, and a few will be reserved
for local processing only.

FX-BBS does not assume that all echoes necessarily originate from
the same net/node, though this will often be the case. For each
echo mail section, you must specify an origination net/node. The
FXMAIL program will use the flags listed on this screen to
determine where new messages originating on your system are to be
sent for subsequent distribution.

The flow control flags are used when FXMAIL builds the control
file used to determine what packets and files are sent where, and
how they are handled. FX-BBS provides the option to either
DELETE compressed mail files and packets after transmitting them,
or of KEEPing them. Some programs support an option to truncate
a file to zero length after it is sent. This particular function
is not supported by FX-BBS.

Three additional flags are provided to determine how the message
is to be transmitted by the particular front-end program you are
using to process mail. I have not personally used the "F" option
and cannot really discuss it in any detail. Refer to the FTSC001
documentation for more detail on this one. The "H" option
specifies that a packet is to be held for pickup after it is
built. In this instance, it is assumed that someone else will
poll your system looking for mail to pick up and the compressed
message files will be transmitted by your front-end program at
that time.

The "C" option indicates "crash" mail. All this really means is
that your system is capable of receiving and sending messages at
any time of day, and does not necessarily have to wait until a
certain time to process mail. Should your system call another
system and it is found that you have a crash mail packet laying
around destined for that system, it will be sent at that time.

When entering flow parameters on this screen, it is necessary to
enter a combination of two, in any order. You *must* enter
either "D" for DELETE or "K" for KEEP, and you *must* enter
either "F", "C" (CRASH) or "H" (HOLD), for each echo mail
section. These flags are not required for the NetMail and local
mail sections. Refer to the part of the documentation discussing
mail processing for additional information.

- 44 -

FX-BBS Installation and User's Guide

The "Prg" parameter is a recent addition, provided to help with
echo mail processing. It represents a separate purge level for
each message section, to be used by FXREPACK when deleting old
mail. FXREPACK will attempt to delete old mail when more
messages are found in a given message section than specified by
this parameter. FXREPACK however, will not delete messages which
are not at least one day old.

The justification for separate purge levels is based on differing
amounts of mail traffic in different echoes. The C language and
Open_Bible echoes for example, often produce 70 or so new
messages each night. The Prgmr echo has much less traffic, on
the order of five or fewer messages each evening, while the
ECONET echo presently generates less than five messages per
month. For echo areas with heavy traffic, I specify a large
purge level. For areas with little traffic, a small purge level
can be entered with messages as old as one month being retained.
The smaller the message area, the more quickly FX-BBS can get
through it when searching for new messages. I also organize mail
sections roughly by size as well, with smaller and local only
message having lower numbers than larger echo mail sections, and
private sections having very high numbers.

- 45 -

FX-BBS Installation and User's Guide

Screen G. Conference Parameters

The Conference setup screen appears more or less as follows:

Conference Information
Nbr of Conferences:
Conference Private Directory Mail Section
Path: (Y/N) Number Number
1: NONE N 0 0
2: NONE N 0 0
3: NONE N 0 0
4: NONE N 0 0
5: NONE N 0 0
6: NONE N 0 0
7: NONE N 0 0
8: NONE N 0 0
9: NONE N 0 0
10: NONE N 0 0
11: NONE N 0 0
12: NONE N 0 0
13: NONE N 0 0
14: NONE N 0 0
15: NONE N 0 0
16: NONE N 0 0
17: NONE N 0 0
18: NONE N 0 0
19: NONE N 0 0
20: NONE N 0 0

Depress Cursor Up, Cursor Down, or Escape for Previous Screen

No default conferences are provided. The main menu functions "J"
and "Q" will therefore not function. Instead, if these two
parameters remain in the main menu command line (see Screen M),
the caller is presented with a message stating that conferences
are not supported.

Up to 20 conferences may be specified (as of version 3.1A;
previous versions of FX-BBS provided support for only six
conferences). This is felt to be an adequate number, with more
than this perhaps less than desirable from a maintenance and
participation standpoint. Increasing the number of conferences
supported is a future possibility however.

When conferences are available, the main menu "J" command will
cause the file CONF.TXT to be output. This text file should be
located in the normal and graphics text paths as required. Refer
to the Path setup menu for a further discussion of this.

- 46 -

FX-BBS Installation and User's Guide

Each conference established must have associated with it on this
screen, a directory and mail section number. You must also
provide a conference description file, which must also be located
in both the normal and graphics text file paths. The names to use
for the conference description files are CONF1.TXT, CONF2.TXT,
CONF3.TXT, and so on through CONF20.TXT.

A conference files path is provided for each conference. As with
other path specifications, those entered here should begin with
the drive letter followed by a colon and a backslash, and should
end with a backslash. Conference paths may be placed within the
normal FX-BBS root file search paths, and when this is done, the
files contained in this directory are accessible by all.
Conference paths may also be completely separate from the normal
caller accessible paths providing complete privacy for those

Each conference may also be made private. One private conference
I used to provide contained "adult" files, read mac pictures, sex
related things, etc. The last thing I wanted was for little
Johnny or Susie to download something a little R or X-rated and
show it to mommy and daddy. This conference has since been
terminated and I no longer post such files on the BBS. The space
was needed for other things. Some callers, notably women, find
such files offensive. You too, should not post such files
without a bit of thought. Do you want your BBS to appeal to
intelligent sorts, regardless of sex, or primarily to the 14 (or
64) year old letch down the street who shouldn't look at such
things anyway? Remember too, that the FBI is alleged to be
convinced that child pornographers are furthering their interests
through BBS systems. You can read about such sometimes in
newspapers. I didn't say the FBI was an intelligent lot, or that
they actually snoop about on BBS systems, only that such reports
have been printed. The effect of such reports will also likely
differ depending on the size of your town. A town with a
population of 15,000 might believe such reports and attempt to
take action, before the population of a city with 500,000 persons
might. I'll leave it for you to determine the facts on this one.
Presently, the only private conferences used on my own BBS are
the FX-BBS support conference and a general sysop conference
being established as I write this.

When a conference is private, you should indicate in the
CONFx.TXT file, the requirements to join. After this file is
displayed to the caller, he will be asked to leave a comment
describing the necessary information. Until the caller is added
to a private conference, this is all he/she will see when J is
entered at the main menu. Once you have added that person to the
conference in question, or if the conference is not a private
one, the caller will be told the directory number and mail
section number for that conference.

- 47 -

FX-BBS Installation and User's Guide

Once a member of a conference, a caller remains a member until
they choose to quit that conference. They do not need to rejoin
the conference each time they call. If that were a requirement,
there could not be private conferences.

The conference directory number and name may or may not be
displayed in the DIR0 file at your discretion. Conference
directory numbers will in any case be summarized separately for
conference members when the [F]iles function is selected from the
main menu, prior to the display of the DIR0 file. Callers may
"rejoin" the conference from the main menu if they wish without
penalty (it does not effect whether they are currently a member
of that conference, nor are any additional comments solicited for
a private conference). This allows callers to review the mail
and directory numbers specified for the conference should they

The conference mail section name and number will be one of the up
to 80 listed on the mail section screens. These mail sections
should be ABOVE the number of mail sections you otherwise
provide. For example, at this writing, I have 27 nominal
sections as described in the default mail section setup menu. I
also have five other mail sections for private, SYSOP only echoes
(and an additional one for conference support), which were
omitted from the default setup menus. The mail sections used for
the private areas are 35, 36, 37, 38, 39 and 40, above the 27 I
specified on the setup menu.

Conferences, while to some degree integrated with other
functions, remain separate. Non-members of a conference are
never presented with mail for that conference, nor the mail
section name. Nor can they enter mail in that conference's
section. Similarly, members of a conference can list the
directory of that conference, but non-members cannot. I have 48
nominal directories, and then additional conference directories,
61 and 62. Non-members cannot list these directories. Should
they attempt to do so, the recent upload directory will be
displayed in its place, if recent uploads are public.

When an upload is being requested, members of a conference are
asked if the file belongs to a conference, and if so, are allowed
to specify which one, provided they belong to it. Non-members
are not asked this.

- 48 -

FX-BBS Installation and User's Guide

For systems equipped with Local Area Networks, a "network chat"
option is provided allowing "group chats". A main LAN chat
conference is provided, along with one for each of the first six
conferences. LAN support for all 20 conferences is not provided
due to the memory overhead and coordination problems that this
would introduce. A Conference NEWS type of file will be added in
the future, along with perhaps the ability to associate a door
with a given conference. At some point, I plan to have some of
the possible doors assignable as conference only doors, but this
has not yet been done. As always, I'm open to suggestions.

Users of versions of FX-BBS prior to version 3.1A should note
that the user record has been changed to support 20 conferences,
and that some adjustments may be required on their part.
Previously, membership in the six conferences was indicated by
byte sized flags in the user record. The flags indicating
membership are now bit sized. If you had set up conferences
before, you will likely need to reset the membership flags.

Final note: A truly private conference might *not* be described
in the CONF.TXT file...

- 49 -

FX-BBS Installation and User's Guide

Screen H. Door Parameters

The door screen appears as follows:

Door Information
Nbr of Doors: 0
Key: Door Program: Password: Exit: Key: Door Program: Password: Exit:
Depress Cursor Up, Cursor Down, or Escape for Previous Screen

"Door" programs as considered here are simply programs which are
external to FX-BBS which you the sysop, have decided to make
accessible to callers. These can include game programs, database
programs and so on, but must be of a class of programs designed
to generate output to a COM port, and accept input from the same
COM port. Up to 40 doors may be specified for FX-BBS, with the
default being no doors. The screen depicted above for specifying
the door parameters is a bit cluttered. As a result, some
"guidance" sorts of information are omitted from it (there just
isn't room). Each entry for a door consists of four parameters:
a "Key" value, the command to be executed to invoke the door
(this is the "door program" field), any password associated with
the door, and lastly, whether FX-BBS is to exit to the door
(remove itself from memory while the door runs, and then reload
itself), or "spawn" the door (in this case, FX-BBS remains in
memory; doors so invoked must usually be smaller door programs).
On the screen above, these parameters are organized in groups of

- 50 -

FX-BBS Installation and User's Guide

The first four horizontal parameters correspond to door number
one, the four below that to door number two, and so on. At the
start of the right half of the screen, the first four parameters
correspond to door number 21. The last four parameters on the
bottom of the right side of the screen correspond to door number

Additional doors can be provided by using batch files or
subprograms ("door monitors") to control them. In this case, you
might tell FX-BBS that door number 1 is "Games", with a batch
file or door monitor providing control of several games when 1 is
selected by a caller.

For each active door, a "key value" of other than "0" must be
specified. Different key values are processed in different ways.
The key value is the input a caller must make in order to invoke
the particular door program.

The specific [O]pen door main menu command is limited to
processing doors with keys of "A" through "Z", such that only 26
doors may be selected through the [O]pen door logic (callers
would select the [O]pen Door command from the main menu, and then
select door "A" through "Z", as you've specified on this screen).
Callers attempting to access these doors must have an access
level greater than 1.

Doors with key values of "1" through "6" are processed directly
from the main menu. In this case, callers need not select the
[O]pen Door command, but simply enter a value from "1" through
"6" at the main menu prompt. Door key values greater than "100"
indicate that the particular door is to be selected from the
[F]iles menu. In this case, it is assumed that you might have
standard directories DIR0 through DIR98, the upload directory as
DIR99, and then (perhaps) door programs listed in the DIR0 file,
selected when a caller enters a value greater than 100. Callers
may run these doors regardless of their access level.

Finally, door key values of "+" and "-" allow you to add doors to
the logon ("+") and logoff ("-") sequence of events. Callers do
not select these doors for running. Rather, they are run
automatically, regardless of the caller's access level. For a
logon door, it will be executed after the bulletin and news files
have been processed, and before the program outputs the message
"Initializing Messages". The logoff door will be executed after
the system asks the caller if they wish to leave a comment for
the sysop, and before the output of the GOODBYE.TXT file.

- 51 -

FX-BBS Installation and User's Guide

If you specify 0 for the number of doors, when a caller asks to
[O]pen a door from the main menu, FX-BBS will inform the caller
that all doors are closed. If the number of doors is greater
than 0, FX-BBS will display the text file DOORS.TXT, which should
explain to the caller which door does what, and then ask the
caller which door they wish to open. If the caller for example,
selects door B, and if this door is specified as available, FX-
BBS will check for a password. If the password for door B is
other than "NONE", FX-BBS will ask the caller to enter a (non-
case sensitive) password. If the password matches the one
specified here, or if the password listed here is "NONE", FX-BBS
will attempt to execute whatever Dos command is specified to
invoke door B.

An example: Specify one door, with a password of maybe,

Specify as the command to execute,
where COMx: is either COM1: or COM2:, (I do not think Dos
supports COM5: through COM8:, and Dos support for COM3: and COM4:
is highly questionable) as required for your system (it may be
necessary to place these commands into a batch file and tell FX-
BBS to invoke that batch file).

When this door is opened, the caller will be required to enter a
password of "RUASYSOP?". The effect of the command above would
of course, be to execute COMMAND.COM with all input and output
redirected to the COM port. This example door then, would allow
anyone who entered the password to have complete access to your
system. They can copy files, delete files, dump files, rename
files, whatever they wish.

It might be unwise to provide such a door for more than one or
two people, if at all. If you allow too many people access to
your system, you will be unable to determine who did what when a
file comes up missing or your disks get formatted... On the
other hand, proper backups would help alleviate some of this

Another door example might be the DSZ Zmodem transfer program.
This one might require a front-end batch file to solicit
parameters, etc. You might also be able to write a batch file to
front-end the PKXARC or ARC52x programs, allowing for example,
files to be extracted to the console (or COM port through I/O
redirection) so that callers may view these. One door I've seen
about is for the Kermit file transfer protocol, also front-ended
by a very large batch file. Of course, file transfer programs
are best added to FX-BBS using the built-in support for such

- 52 -

FX-BBS Installation and User's Guide

Door programs may be exited or not as you see fit. When Exit is
not specified, FX-BBS "spawns" the door (FX-BBS does not leave
memory). Logon and Logoff doors should likely be limited to
those which may be spawned. If Exit is specified FX-BBS
terminates with an errorlevel equal to 100 + (the modem port
number in use - 1) * 40 + the door number requested. Door
errorlevel values for COM1 then will be in the range of 101 to
140; for COM3, in the range of 181 to 220, and so on. For ports
COM5 through COM8, the errorlevel values are repeated; that is,
errorlevel values for COM1 and COM5 are the same, as are
errorlevel values for COM2 and COM6, and so on. This is because
Dos does not support errorlevel values greater than 255. Another
result of this limitation is that COM4 and COM8 are limited to
errorlevel values of 221 through 255.

When a door is exited to, a batch file must examine the value of
errorlevel and invoke the door appropriately. That is, FX-BBS
itself must have been started from a batch file, which should
examine as required the various meaningful values of errorlevel,
invoke the appropriate door, and then loop back to restart FX-
BBS. If sufficient memory exists for the door to be spawned,
this is the preferred method, since it will be faster. Large
door programs may however, require too much memory for this, so
that FX-BBS must exit. Remember that the message editing buffer
is returned to the system prior to invoking spawned door
programs, so that they have that much more memory available in
which to run. The amount of memory available to spawned doors is
equal to that displayed in the status area of the screen, plus
the number of message lines specified on setup screen E * 82.

- 53 -

FX-BBS Installation and User's Guide

When a door is spawned, several parameters are passed to the door
program or batch file for processing. These are, in the
following order:

Caller's Access Level
Baud Rate
Port Number (1 through 8)
Time Remaining in Seconds
ANSI Graphics Flag ("Y" or "N")
Local/Remote Indicator ("L" = Local, "R" = remote)
Caller's First Name
Caller's Last Name (unless you've logged on under "SYSOP")

These parameters may be processed or not, rearranged or whatever,
as required by a door program or batch file. When a door is
exited to, such parameters are impossible to provide via the
command line. Two door parameter files are also written to disk
each time a door is invoked, regardless of whether the door is
spawned or exited to. The first door parameter file is named
"DOORxx.SYS", where "xx" indicates the FX-BBS system number you
specify on FXBSETUP screen M. This allows different callers to
invoke doors as required without overwriting one another's
parameter files.

The particular format of this file was recommended by someone
named Rick Greer, a door author in Texas, in the doorware
EchoMail area. Other formats exist unfortunately (many others -
there seems to be no real standard and different authors have
differing proprietary formats). While FX-BBS cannot generate
them all, simple programs may be written to convert information
in the FX-BBS door parameter files to the format required by a
particular door program. (Some RBBS doors for example, depend on
data stored in message files in some way or another. I'm not
really that familiar with the data contained there, but can say
that one sysop has written a program which fakes the files
required using data contained in the DOORxx.SYS file. Another
example is included with FX-BBS: the FXUSRINF.EXE program reads
FXINFOxx.INF files and converts information contained therein to
the format required for use with Milton Gameworks door programs).
Naming the parameter file as DOORxx.SYS is a nonstandard
extension of my own. The "xx" in the DOORxx.SYS filename refers
to the system number (copy of FX-BBS running) which generated the
file in question. One thoughtful user asked me why I add this
"xx" value to the filename, since the node number of the
responsible system is contained in the DOOR.SYS file definition.
The primary answer is that a single name of DOOR.SYS would allow
each caller to overwrite another's DOOR.SYS file, chaos in the
extreme. A secondary answer relates to the first: there would be
no way for a door program or batch file to determine the node
number without first reading the file. Naming the files
DOORxx.SYS is intended to circumvent these sorts of problems.

- 54 -

FX-BBS Installation and User's Guide

Additional parameters have been added to the end of the
DOORxx.SYS file which are also nonstandard, but which I feel are
required. The format of the file is as follows, shown with
sample values (each line is ASCII, with a CR/LF at the end; text
between the comment symbols "/* ... */" is not written to the
file, nor are any blank lines; blank lines appear below due to
the need for additional comments):

COM1: /* COM Port - COM0: = LOCAL MODE */
2400 /* Baud Rate - 300 to 38400 */
8 /* Parity - 7 or 8 */
1 /* Node (system) Number - 1 to 99 */
0 /* Baud rate to lock at (9600, 19200, etc) */
Y /* Screen Display - Y=On N=Off (Deflt to Y) */
Y /* Printer Toggle - Y=On N=Off (Deflt to Y) */
Y /* Page Bell - Y=On N=Off (Deflt to Y) */
Y /* Caller Alarm - Y=On N=Off (Deflt to Y) */
First Last /* User Full Name */
MyTown, CA. /* Calling From */
999-999-9999 /* Home Phone (Not supported by FX-BBS) */
999-999-9999 /* Work/Data Phone (Not supported by FX-BBS) */
PASSWORD /* Password */
2 /* Security Level */
1456 /* Total Times On */
03/14/89 /* Last Date Called */
7560 /* Seconds Remaining THIS call */
126 /* Minutes Remaining THIS call */
GR /* Graphics Mode-GR=Color,NG=NoColor,7E=7E1 */
/* CG=Convert to Non-PC (non-standard add) */
23 /* Page Length */
Y /* User Mode - Y = Expert, N = Novice */
123456 /* Conferences/Forums Registered In */
7 /* Conference Exited To DOOR From */
01/01/99 /* User Expiration Date */
1 /* User File's Record Number */
N /* Default Protocol - (Not Supported by FX) */
0 /* Total Uploads */
0 /* Total Downloads */
0 /* Daily Download "K" Total */
999999 /* Daily Download Max. "K" Limit */
/* Following are non-standard additions: */
FX-BBS V3.1B /* BBS program tag */
CONFIG /* FX-BBS configuration file name used */
999 /* Fidonet Net Number */
999 /* Fidonet Node Number */

- 55 -

FX-BBS Installation and User's Guide

The second door parameter file contains less information, but is
in a common format matching that of RBBS door information files
called "DORINFOx.DEF". The name of the file is different again,
due to greater multitasking considerations. It will be
"FXINFOxx.INF", where "xx" is the system number assigned in the
FXBSETUP configuration file. This file will require renaming
before being used by your door programs. Valid names for
"DORINFOx.DEF" files allow "x" to have a value of from "1" to
"9", or the letters "A" through "Z". The format of this file,
again with example values and comments, is as follows:

BERTHABOARD BBS /* Name of Your BBS */
KENNETH /* SYSOP's First Name */
ROACH /* SYSOP's last Name */
COM2 /* Port Caller is Using */
2400 BAUD,N,8,1 /* Modem Parameters in Use */
0 /* Network Type:0=PC/MSDOS,4=DV,6=NetBIOS */
JIM /* Caller's First Name */
JOHNSONIAN /* Caller's Last Name */
MYTOWN,GA /* Caller's City and State */
3 /* Clr's Grphcs Type:1=ASCII,2=IBM Box,3=ANSI */
10 /* Caller's Access Level */
16600 /* Time Remaining in Seconds */

In anticipation of someone asking me why there are leading blanks
on some of the lines in the files above, I'll state simply that
they're there because they were there in sample files examined,
and seem to be a function of the language used (probably Basic).
I've included the blanks then, in an effort to assure

Caution is the watch word with door programs, as problems can
arise when you relinquish control of the system to another
program. For spawned door programs, FX-BBS makes an effort to
terminate an executing program when a caller hangs up, but is not
always successful. Use of doors at all is, of course, entirely
optional... Not having written any door programs, I cannot take
responsibility for their performance or lack thereof.

There are TSR programs about which will watch carrier detect and
reboot the system or close and reopen a DesqView window should
carrier be lost. The rebooting type of programs should *not* be
used when FX-BBS *spawns* a door! There are two problems with
them. First is that in a multi-line system, you really wouldn't
want to reboot if you didn't know whether someone else was on
another phone line. Second is that the ones I've seen seem to be
TSRs, or "terminate and stay resident" type programs. When you
start one of these from within FX-BBS, it will glom onto heap
memory and can never be completely gotten rid of (perhaps some
can, but the one I examined the code for seemingly could not).
FX-BBS doesn't like it much when this happens... These programs

- 56 -

FX-BBS Installation and User's Guide

are also unnecessary, since FX-BBS already performs the
processing provided by these watchdog type programs when doors
are spawned, and does so without rebooting the system.

A superior carrier watching program available for use with doors
that are exited to is called "Watch Cat", or "Watch Kat" (named,
I assume as a successor to the "Watch Dog" program). This
program runs the requested door program(s) and rather than
rebooting the system when carrier is lost, simply shuts down the
door program running and exits to the BBS program. Certainly
rebooting the system in a multiuser environment is undesirable!
A recently posted version of this program goes under the name of
WAKA100.ARC on many BBSs. In the tradition of the names used
above, there is also now a program called "Watch Bird" which,
although I've not tested, have heard good things about. Note too
that RBBS door programs which go through the MONITOR program do
not require an external carrier monitoring program.

When using doors in a multitasking environment such as DoubleDOS
or DesqView, problems can arise if the door programs are not
aware they are running in a multitasking environment. In this
case, these programs can effectively hog the majority of the
cpu's time, slowing down other copies of the BBS drastically.
Little or nothing can be done when this occurs, save configuring
FX-BBS to perform less optimization for the multitasking
environment, which may result in a slight performance
degradation. The "Tame" program might be used with some doors
under DesqView, though this seems doubtful. This is not a
problem when a LAN is in use.

Good housekeeping dictates that the sysop should generate
complete and correct batch files to control external programs.
However, when FX-BBS has completed running a door (or actually,
any spawned external program), it will reset the default
directory and default drive back to those in effect at the time
the program was started.

- 57 -

FX-BBS Installation and User's Guide

Screen I. External Protocol Parameters

The External Protocol Screen appears as follows:
External File Transfer Protocol Information

Number of External Protocols (0 to 6): 0

Name of External Protocol 1: NONE Batch Protocol (Y/N)? N
Protocol 1 Download Command: NONE
Protocol 1 Upload Command: NONE
Name of External Protocol 2: NONE Batch Protocol (Y/N)? N
Protocol 2 Download Command: NONE
Protocol 2 Upload Command: NONE
Name of External Protocol 3: NONE Batch Protocol (Y/N)? N
Protocol 3 Download Command: NONE
Protocol 3 Upload Command: NONE
Name of External Protocol 4: NONE Batch Protocol (Y/N)? N
Protocol 4 Download Command: NONE
Protocol 4 Upload Command: NONE
Name of External Protocol 5: NONE Batch Protocol (Y/N)? N
Protocol 5 Download Command: NONE
Protocol 5 Upload Command: NONE
Name of External Protocol 6: NONE Batch Protocol (Y/N)? N

Protocol 6 Download Command: NONE
Protocol 6 Upload Command: NONE

Depress Cursor Up, Cursor Down, or Escape for Previous Screen

External protocols are really external programs which can be run
by FX-BBS, similar to door programs. Examples of these include
the DSZ Zmodem transfer program, JModem, the PCKermit program,
MegaLink, Puma and Lynx, SuperKermit and so on. Each of these
programs transfer files (uploads and downloads) in a manner
similar to Xmodem or Ymodem. In some cases, the protocol used is
proprietary. FX-BBS supports the core protocols of Xmodem, 1K-
Xmodem, Sealink and ASCII. By using external protocol programs,
several of the newer and different protocols may be added to FX-

Up to six protocols may be specified for use. FX-BBS will not
"exit" to them, but only spawns them. The default value is 0, or
none. Additional external transfer protocol support is not
likely forthcoming. However, as time goes on, I anticipate
adding additional internally supported protocols, such as Zmodem
and Kermit (Sealink was added to version 3.1A), lessening the
need for additional external support. For each protocol to be
used, a name must be specified, along with a command to invoke
the program for downloading and another for uploading.
Typically, these commands will refer to batch files.

- 58 -

FX-BBS Installation and User's Guide

For example, I run the DSZ program from batch files called
DSZSZ.BAT (to send files) and DSZRZ.BAT (to receive files). To
set up DSZ Zmodem then, the name of the protocol would be
"Zmodem", the download command might be DSZSZ.BAT and the upload
command DSZRZ.BAT.

Following the DSZ example further, inside the DSZRZ.BAT file
would be the line, "DSZ CON port %1 sz -r %3". Three parameters
are passed to a protocol program by FX-BBS. The first (%1) is
the port number, the second (%2) is the baud rate, and the last
(%3) is the filename, which will include the drive and any
subdirectories required. The percent signs are available only
from within batch files of course. From the command line, the
normal values would have to be used. The "-r" in the line above
by the way, tells DSZ to try to continue any aborted downloads
always. It does no harm if DSZ is not in fact requested to
continue an aborted download. To finish the example, the
DSZRZ.BAT file contains the line "DSZ CON port %1 rz %3".

DSZ is a pretty good external protocol program at this point.
One of the best in fact. In addition to providing Zmodem
support, it also supports Xmodem and Ymodem, and batch mode for
the latter. Beginning with the version named DSZ0411.ZIP,
multitasking optimization is much better, and support for IRQs up
to seven was added (hopefully, he'll be adding support for more
IRQs as time goes on). Chuck Forsberg used to provide free
registration of the DSZ program to SYSOPS, and probably still
does. It is strongly recommended that you look into this

FX-BBS optionally supports batch downloads with external transfer
programs at the present time (the Sealink protocol as built into
FX-BBS is implemented strictly as a batch download protocol),
provided it is used with external protocol programs which are
capable of dealing with FX-BBS's output in a particular way.
When a caller requests a protocol you have designated as a batch
protocol, FX-BBS will repeatedly ask the caller for the names of
files to be downloaded. After each file name is entered, FX-BBS
will perform a search for the file. When found, the caller will
be notified of the time required for that particular file. If
the time for all files requested thus far exceeds the time the
caller has remaining, the file will be refused. This process
continues until the caller either enters a 'Q', which aborts the
download operation, or depresses enter on an empty line, which
will indicate to the program that the caller has completed
entering all filenames desired. Following this, FX-BBS will
spawn the external protocol program.

Files to be transferred in batch mode by an external program are
listed in a standard text file, and the name of this file is
passed to the external program. The filename is built based upon

- 59 -

FX-BBS Installation and User's Guide

the first letter of the external protocol name you've specified
on the setup screen, followed by the letters "BATCH", followed by
the two digit system number, and an extension of "LST". The name
of the file passed to Zmodem for system number 6 would be

The DSZ program supports such lists of files to be transferred by
use of a command line parameter which starts with the ""
character. Since other programs might differ in the parameter
designating that a file contains a list of other files (as
opposed to being a file that is actually to be transferred
itself) FX-BBS does *not* add the "" character... I get the
feeling I'm using far too many words to describe this. Sorry.
Let's try an example... For DSZ, to send a file in a NON-BATCH
manner, you would use a batch file command of "DSZ CON port %1 sz
%3". To send files in a BATCH manner, you would use "DSZ CON
port 1 sz @%3". From this, you can see that FX-BBS will output
as the third parameter, either the name of a file to be
transferred when the protocol is not batch oriented, or the name
of a file which lists other files to be transferred when a
protocol is batch oriented. Boy, hope that makes sense. If not,
stare at it a little longer.

This takes us back to the restriction a few paragraphs up. The
particular statement in question is: "FX-BBS optionally supports
batch downloads at the present time, provided it is used with
external protocol programs which are capable of dealing with FX-
BBS's output in a particular way." What this meant was that the
external program must be capable of processing a file which lists
other files. For example, while Kermit is known as a batch
processing protocol, most implementations of Kermit are not
compatible with this method. An example of how Kermit deals with
batch transfers would be telling it to send "FX-BBS*.*". That
is, Kermit generally requires wildcards, which I'm sure you can
see would be undesirable in most BBS situations...

Another note: not all external programs support entering a
filename to be received. In these cases, your batch file must
perform additional processing, including the command "ECHO OFF"
to start with, followed by commands to change to the required
drive and/or subdirectory where the file received is to be
placed, invoking the program to receive the file, and then
changing back to the normal drive and subdirectory before
returning to the BBS program.

Many external protocol programs are available and others will not
be described herein. Batch files and front end programs are
available for the DSZ and PCKERMIT programs on Bertha Board and
may be downloaded or not as you wish.

- 60 -

FX-BBS Installation and User's Guide

When using external file transfer protocols in a multitasking
environment such as DesqView or DoubleDOS, problems can arise.
This is simply because the external programs may not be aware of
multitasking systems and can effectively hog the majority of the
cpu's time (This is not a problem when a LAN is being considered,
only for multitasking operating systems).

One not necessarily desirable way to deal with this is to reduce
FX-BBS's optimization for the multitasking environment. This is
not desirable because it can have a negative impact on other
functions, such as inter-node chat. Should you attempt to deal
with the problem in this manner, be certain to configure *all*
copies running for reduced multitasking optimization. I've had
mixed results as well using the shareware program called TAME
(latest commonly available version is called TAME203.ZIP). While
this program is a TSR, it requires only some 2Kb of memory, and
has provisions for de-installing itself. As I used it, it was
run from within the batch file I used for the external protocol
program. For example:

rem load TAME TSR:
DSZ CON port %1 sz @%3
rem remove TAME TSR:

Note that since it is run from within the batch file in this
case, it *must* be de-installed upon exiting the batch file.
When performing a download with such a batch file, I found I was
able to do a "whereis" for "*.*" as well as list the upload
directory nonstop with no serious speed problems.

There is a problem with at least the unregistered version of Tame
however: Following the de-installation of the program, a rather
long delay is invoked while a shareware screen is displayed.
This delay is sufficiently long that it is actually possible for
a caller to hangup and another caller to connect to the system,
*before* FX-BBS is returned to. This has actually happened in at
least one case on another sysop's system, and is no joke! If the
second caller's baud rate matches that of the first caller, they
will find themselves in the previous caller's session. A good
reason to register Tame, if you're going to use it... And
depending on how piggish the external protocol in question is,
you may have to.

- 61 -

FX-BBS Installation and User's Guide

Screen J. Color Parameters

This screen appears as follows:


Local and Caller Screen Color Setting

Local Screen Help Area Color Code: 09
Local Screen Status Area Color Code: 04
Local Screen Recent Callers Color Code: 06

The following lines are for use with ANSI.SYS:

ANSI Bulletin Color String: 36-1
ANSI Main Menu Color String: 31-1
ANSI File Section Color String: 33-1
ANSI Mail Section Color String: 32-1
ANSI Auxiliary Color String 1: 31-1
ANSI Auxiliary Color String 2: 32
ANSI Auxiliary Color String 3: 36

Depress Cursor Up,Cursor Down, or Escape for Previous Screen


Local Screen Color Codes:

These are values processed by Dos, and represent the PC's color
codes. For example, a decimal value of 09 represents high
intensity blue, a value of 04 represents red, and so on. The
codes described herein are different if a monochrome monitor is
used. The value entered is interpreted by Dos in a bitwise
manner. Values described above have been expressed in decimal
(base 10), but can also be entered in hexadecimal (base 16) by
simply starting the input with "0x". A byte is interpreted in
binary as follows:

7 6 5 4 3 2 1 0
2 2 2 2 2 2 2 2

2 1 0
Bits 2 , 2 and 2 have a range of 0 to 7 and make up the
foreground color. A value of 0 is black, 1 is blue, 2 is green,
3 is cyan, 4 is red, 5 is magenta, 6 is brown, and 7 is white.

6 5 4
Bits 2 , 2 and 2 are interpreted in the same way, but specify the
background color.

- 62 -

FX-BBS Installation and User's Guide

Bit 2 selects a high intensity foreground color, and bit 2 is
the blink bit.

I leave the matters of converting from decimal to hexadecimal and
binary to you. If you have difficulty, you should refer to a Dos
manual for further information. If your manual does not describe
these codes, then you might refer to "Programmer's Guide to the
IBM PC", by Peter Norton and published by Microsoft Press, pages
76 through 81 in the copy I have. Or you might just play with
changing the values to see what the results are. As you enter
values for these parameters, the colors on the screen will
change. Note that the values used here are used on the main
menu, status display area, in terminal mode, and in the FXBSETUP
and EDITUSER programs (the EDITUSER program expects color codes
to be in a file called "FX-BBS.CFG" and will not use colors
contained in any other file; if FX-BBS.CFG cannot be found, no
colors will be used). Note too that these codes effect only
LOCAL display of colors, and have nothing to do with ANSI.SYS
color codes, described next.

While the values reflected here are intended for a color monitor,
monochrome monitors will also be effected by these values, though
not in the same manner. Monochrome screen attributes are
interpreted differently by the computer. Again, refer to the
appropriate documentation for your type of monitor (in my own
case, I design color menus on another system for viewing by
callers with color monitors; I use a monochrome monitor for the
BBS system however, which means that the displays often look a
bit bizarre to me).

- 63 -

FX-BBS Installation and User's Guide

ANSI Color Strings:

The color codes described here are used when the caller has
selected graphics mode at logon. These values represent the
color to be displayed when processing is being performed by the
section indicated. These are the DEFAULT colors for messages and
menus output by the different routines. Menu files may contain
any desired color, but the color will be reset to that specified
here after the menu has been displayed. The codes entered here
have the following meanings:

ANSI Color Code Definitions:

0 - All Attributes off.
1 - Bold on.
4 - Underscore on (monochrome monitors only).
5 - Blink on.
7 - Reverse video on.
8 - Concealed on.
30 - Black foreground. 40 - Black background.
31 - Red foreground. 41 - Red background.
32 - Green foreground. 42 - Green background.
33 - Yellow foreground. 43 - Yellow background.
34 - Blue foreground. 44 - Blue background.
35 - Magenta foreground. 45 - Magenta background.
36 - Cyan foreground. 46 - Cyan background.
37 - White foreground. 47 - White background.

Several of these codes may be entered on each of these lines.
For example, to select "blinking red" (ugh!) you would enter
"5-31". FX-BBS expects separate codes to have a dash or minus
sign separating them, NOT the standard semicolon as normally used

These codes do not effect graphics menus except to provide an
initial color. Graphics menus are best designed using a program
specifically designed for that purpose. THEDRAW is a relatively
good shareware program for this, and is currently on various
BBS's under the name of "TDRAW300.ARC". They request a $10
registration fee. (note: after generating ANSI menus, use a
standard text editor and delete the ending ANSI control strings;
they're not required and can sometimes help confuse the local

- 64 -

FX-BBS Installation and User's Guide

For directory listings, the standard DIRxx files may be used in
*both* the Normal and Graphics text file paths. A colon (":") in
the first column of the file will cause auxiliary ANSI colors to
begin being applied to the directory listing. Color codes are
not applied to the files until a colon is encountered. A side
effect of this is that the (first) colon is a reserved symbol in
the FX-BBS directory file listings. See the example directory
files included with this package. Once a colon in the first
column has been found, auxiliary color string 1 will be applied
to the first 15 columns, auxiliary color string 2 will be applied
to columns 16 through 23, and auxiliary color string 3 will be
applied to the remaining columns of each line.

The auxiliary color strings are also used elsewhere in the
program, in an effort to jazz things up. Your callers will of
course, want jazzy things...

A final note: Your directory files should not contain tabs.
Tabs, when mixed with ansi color strings, sometimes has a
confusing effect on text file output.

- 65 -

FX-BBS Installation and User's Guide

Screen K. Illegal Call Inputs

This screen appears as follows:
Illegal Caller Inputs

Enter File Name Extensions Which You Wish to Dis-Allow:

1: NONE 6: NONE 11: NONE 16: NONE
2: NONE 7: NONE 12: NONE 17: NONE
3: NONE 8: NONE 13: NONE 18: NONE
4: NONE 9: NONE 14: NONE 19: NONE
5: NONE 10: NONE 15: NONE 20: NONE

Enter Name Fragments you Wish to Dis-Allow at Logon Time:

1: NONE 11: NONE 21: NONE 31: NONE
2: NONE 12: NONE 22: NONE 32: NONE
3: NONE 13: NONE 23: NONE 33: NONE
4: NONE 14: NONE 24: NONE 34: NONE
5: NONE 15: NONE 25: NONE 35: NONE
6: NONE 16: NONE 26: NONE 36: NONE
7: NONE 17: NONE 27: NONE 37: NONE
8: NONE 18: NONE 28: NONE 38: NONE
9: NONE 19: NONE 29: NONE 39: NONE
10: NONE 20: NONE 30: NONE 40: NONE

Depress Cursor Up, Cursor Down, or Escape for Previous Screen

Two major categories of information appear on this screen. The
first allows you to specify extensions which you wish not to
permit in upload file names. For example, you might want to
exclude EXE and COM uploads. Few uploaded programs require these
(only a few compression programs in distributed form, which you
could post manually). I personally disallow EXE and COM files
based on the belief that these days, no one should have to
execute a program without first being able to decompress it and
examine it. For the most part, files with these extensions
represent uncompressed files. Other similar extensions might be
C, PAS, BAS, ASM and so on, all representing extensions of files
which are not compressed. Upload attempts for files with
extensions listed on this screen are refused. Empty slots should
contain the reserved word, "NONE".

Excluded logon name fragments are provided to allow you to
prevent profanity and/or fictitious logon names as required. You
might exclude DOCTOR, or DEATH, HACKER and so on. Logon attempts
where a match is found for a string listed here, ***anywhere
within the caller's name***, will be immediately terminated. The
caller is afforded the opportunity to leave a comment however, on
the off chance that their name really is Doctor Death...

- 66 -

FX-BBS Installation and User's Guide

Screen L. Miscellaneous Parameters Screen 1

This screen appears as follows:
Bulletin Board System Miscellaneous Parameters 1

User ID File Name: (no default value here)
Path & Name of Program for ALT-F2: C:\COMMAND
Password for ALT-F1 and ALT-F2: PASSWORD
Name of Bulletin Board: FX-BBS Bulletin Board
Use Direct Screen Writes? B (D = DV Bfr S = Screen B = Bios)
If Direct, Check Snow (Y/N)? Y
Bonus Time for Uploads: 50
Line Printer Number (1 or 2): 1
Hour of Auto Exit (0 = N/A): 0
Wait Time for Transfer Starts: 90
Number of Seconds Before Blanking
Screen (0 = N/A): 180
Optimize for DesqView or
DoubleDOS (0=NO/1=YES/2=MAX)? 0
Optimize for Communications
(0=NO/1=MIN/6=MAX)? 0
Command Line Part 1: A,B,C,D,E,F,G,H,I,J,K,L,M,N,O
Command Line Part 2: P,Q,R,S,T,U,V,W,X,Y,#,$,^,&
Allow LAN Chatting (Y/N)? N

Depress Cursor Up,Cursor Down, Return/Escape for Previous Screen

As previously mentioned somewhere, no default value for the user
ID file is specified for security reasons. You must make up a
name for this, and should be creative. It should be a standard
file name, 8 characters, with an optional 1-3 character
extension. How about your mother's maiden name? Or maybe
"RU17.EX4"? Doubt anyone will guess something like that...

FX-BBS will attempt to take the phone off hook (if no one is
online) and then run the FX-Shell maintenance program when ALT-F1
is depressed and no caller is online. If a caller is online, the
phone is not taken off hook. The password specified here will be
fed to the program, which will then lock up until that password
is entered. The FX-Shell program is available separately on
several BBS's. If you have trouble locating it, it's available
on Bertha Board.

For ALT-F2, FX-BBS will perform similarly, but will attempt to
invoke the program you specify here on this menu. The default is
COMMAND.COM, but you may specify any program name. FX-BBS does
not assume COMSPEC points to the desired program. Refer below to
the area discussing security issues for the whys and wherefores
regarding this.

- 67 -

FX-BBS Installation and User's Guide

The name of the bulletin board specified on this screen is
displayed on the local screen only. (Note that the name
displayed on your local screen may at times be replaced with an
error message if appropriate in order to get your attention).

Direct screen write flag: Three values are provided for this
option. If direct screen writes are not desired, enter "B" and
FX-BBS will use the Bios for screen output. If you wish to
output directly to screen ram (the fastest method available),
enter "S". DesqView maintains a separate copy of the screen, and
displays only a portion of that copy of the screen as required in
any window which may be open. If you wish to, you may enter "D"
to tell FX-BBS it should write directly to the DesqView screen
buffer. Proper display and processing of this buffer depends on
various DesqView parameter settings.

Check snow flag: When direct screen writes are being used, some
CGA monitors will flicker if this parameter is set to "N".
Setting this parameter to "Y" will remove the flicker (see also
references to the FXCOMM program for more information regarding

Upload bonus time factor: This is the fraction of the time
required for an upload to reward the uploader with. This time is
saved after the call is terminated, but only for the remainder of
the day. After midnight, it will be reset. Values should range
from 0 to 100. Example: If the value here was 50 and an upload
required 30 minutes, the caller would receive half the upload
time as a bonus, or 15 minutes extra in this example. Following
the upload then, the caller would have 45 minutes of time
remaining. Bonus time accumulates from day to day. That is, it
is not cleared at the start of each new day. It is possible for
callers therefore to earn rather large amounts of time. One of
my callers has more than two days of time available...

Line printer number should be self-explanatory. 1 or 2 may be
entered. 3 *might* work, but has never been tested.

Hour of auto-exit: If this value is 0, the parameter is ignored.
If not zero, it represents the hour at which the BBS should exit.
This might be useful for an automatic tape backup at say 3AM. An
integer must be specified for this field, with a range of 0-12.
Since 0 is ignored, the hour of exit may be from 1AM to 12 Noon.
The program attempts to be polite in how it shuts down, but has
been made a bit more rude as of version 3.1A. Beginning with
that version, FX-BBS watches the clock almost continuously and
will generate a "three minute warning" prior to a forced
shutdown. Following this, it will no longer allow downloads or
uploads to be initiated, and after three minutes, will actually
force the caller off of the system. There remains an exception

- 68 -

FX-BBS Installation and User's Guide

to this however: While a caller is downloading or uploading a
file, the clock is not watched. If you specify an auto-exit time
of 1AM and a caller begins a two hour download at midnight (you
shouldn't allow such a situation to occur in any case), FX-BBS
will not be able to force that caller off. When using this
parameter, be sure your modem on hook string contains "S0=0" to
prevent the modem from answering the phone while the BBS is not

Wait Time for Transfer Starts: Refers to how long the program
should wait for a transfer to actually begin after the caller has
requested a transfer. The default value is 90 seconds, after
which time, the program will return to the main menu if the file
transfer has not started.

Number of Seconds to Wait Before Blanking Screen: Exactly that.
The default value is 180 seconds, or three minutes. When the BBS
has been inactive for that long, the screen will be blanked
(effectively) until either a key is depressed, or a call is
received. At that time, the screen will begin to display
information again. Specifying a value of zero causes screen
blanking to be bypassed. While the screen is blanked, a message
is displayed (and moved about to prevent burn-in) indicating that
the BBS is inactive. This message suggests depressing Enter to
show the display. Note that while Enter works, so do most
keystrokes, and some keystrokes have meaning (such as the space-
bar). Use care in determining the key you wish to depress.

FX-BBS can perform some special processing associated with the
DesqView and DoubleDOS multitasking programs. If you enter "0"
here, no optimization is performed. If you enter "1", FX-BBS
will give up time while performing file I/O (when a file is
opened, when a seek is performed, and during read and write
operations as well) some of the time, and when the keyboard or
modem is idle (no inputs are being made or the transmit ring
buffer is being emptied). If you enter a value of "2", all
previous multitasking optimization will continue to be performed,
with time given up after almost every file I/O operation.

Note that when running a single copy of FX-BBS with other
programs which are disk or cpu intensive, multitasking
optimization might be better disabled or reduced to the 50%
setting. FX-BBS expects the other programs running to give up as
much time as it does itself, and may not function at adequate
speeds if this is not the case. If for example, you bring up a
word processor which is not designed to run optimally in a
multitasking environment, FX-BBS may slow significantly.

- 69 -

FX-BBS Installation and User's Guide

Note too, that no guarantees are made as to whether or not the
processing performed will perform correctly. This depends on the
particular version of the multitasking software you're running.
Should you experience difficulty when running under DesqView or
DoubleDOS, or if you are operating a single phone line system,
turn the optimization off (or try a different version of
DoubleDOS/DesqView). Different versions of the programs also
exist, with some being more capable than others... Multitasking
optimization is also unlikely to recognize other multitasking
environments, such as Windows/386 or PC-MOS for example. I have
nothing against these particular programs. I also do not have
access to these particular programs, which is why FX-BBS doesn't
know much about them.

Specification of a nonzero value for multitasking optimization
is required for the single system method of internode chatting to
function properly.

Optimization of communications can provide significantly better
performance whether or not multitasking is being used. Entering
a value of 0 here (no optimization) causes the program first to
use DOS to initialize the modem (if all parameters are set
appropriately; refer to setup Screen A), and second, to simply
stuff each byte to be sent to the caller into the appropriate
modem register. A delay may occur as required while waiting for
the modem to raise the clear to send signal. This is the brute
force approach, and depending on the modem, may be required...
If possible, it should be avoided since processing time may be a
bit longer (making the system perform less well).

Each of the other options, from 1 to 6, cause transmit interrupts
to be used for sending data to the modem. Additional memory is
used by FX-BBS when a nonzero value is entered here. The minimum
size for the transmit ring buffer is 512 bytes (options 1 and 2).
The difference between options 1 and 2 is the number of bytes
placed into the ring buffer before FX-BBS pauses. A value of 1
enables transmit interrupts, but the buffer is not allowed to
fill very much at all. For values greater than 1, the buffer is
allowed to become nearly full, at which time a given copy of FX-
BBS will stop processing and give all cpu time to any other tasks
which may be running. A value of 3 causes a transmit ring buffer
size of 1024 bytes to be used, a value of 4 causes the size to be
2048, a value of 5 selects a size of 4096 bytes, and a value of 6
selects a size of 8192 bytes. Remember that each larger value
requires more of your system's memory, thus reducing the amount
available for some other things.

- 70 -

FX-BBS Installation and User's Guide

Some side effects occur as a result of using transmit ring
buffers, and these effects may be more pronounced as the size of
the buffer is increased. First, the slower the caller's baud
rate, the longer it takes to empty the ring buffer. Using a 2048
byte buffer, a caller at 300 baud could conceivably require 68
seconds to empty the buffer. During this time, the computer will
appear to be doing *nothing*. If you allow 300 baud callers
then, you should not use such a large ring buffer. A second
effect relates to CTRL-C processing. If a given menu has been
completely placed into the ring buffer and the caller depresses
CTRL-C to abort the menu output, it will have no effect.
Selecting the appropriate optimization value then is a function
of the slowest baud rate you allow, and the number of lines to be
supported. The greater the number of incoming lines or the
higher the baud rate supported, the larger the buffer should be.
The slower the baud rate, the lower the number should be.

The next two lines on this display are joined together when the
program runs and together make up the command line displayed
after the main menu. Should you not wish to offer certain
commands to callers, you may remove them from this menu and
effectively disable those functions. Letters depressed from the
main menu which do not appear on these two lines are ignored
unless the caller is either the SYSOP or an Assistant SYSOP.

The final parameter on this display concerns whether or not
callers will be able to chat with one another via use of a Local
Area Network (NetBIOS) capability. This parameter will have no
effect if the program cannot determine that NetBIOS is installed
and running on the system in question. Refer to the area of the
documentation discussing LAN processing for more information.

- 71 -

FX-BBS Installation and User's Guide

Screen M. Miscellaneous Parameters Screen 2

This screen appears as follows:
Bulletin Board System Miscellaneous Parameters 2

Multi-Line BBS System Number: 01
Run BBS with Front-End
Program (Y/N)? N
Lock Baud Rate (Y/N)? N
Start Time for SYSOP Avail: 1800
Stop Time for SYSOP Avail: 2200
Minimum Access Level Required
for This Node: 1
Auto Message Repack Time: 0 (0 = N/A)
Repack Option: A ('D','A')
Message Repack Purge Level: 1000
Allow Comments (Y/N)? Y
Your Zone Number: 0
Your Net Number: 0
Your Node Number: 0
Host Net Number: 0
Host Node Number: 0
Origin Line (First Half): NONE
Origin Line (Second Half): NONE

Depress Cursor Up, Cursor Down, or Escape for Previous Screen

Multi-line System Number: This parameter can range from 01 to 99
and is used primarily in distinguishing different files from one
another. For example, the COMLOGxx.BBS and DOORxx.SYS files. It
is required, and each copy of the FX-BBS program running must
have a unique number. Beyond this, don't give it much thought.

SYSOP's Name: Your name, as you log onto the BBS. This is the
*same name* you use to log on. By entering that name here, FX-
BBS knows just who the SYSOP really is, and who to give all the
extra permission to.

Run BBS With Front-End Program: If you're setting up an echo
mail compatible system, you'll want to enter a "Y" here. With
this parameter set to an "N", FX-BBS assumes it must initialize
everything, and among other things, places the phone onhook.
Specifying a "Y" here tells FX-BBS that another program has
already answered the phone (your front-end program, for example,
BinkleyTerm), and that it should immediately go to the logon
logic. When the caller terminates the call, it tells FX-BBS that
it should exit as well, returning control to the front-end

- 72 -

FX-BBS Installation and User's Guide

Lock Baud Rate: High speed modems such as the US Robotics
Courier HST often perform best when the baud rate at which they
communicate with the computer is "locked" at a specific rate. In
these cases, the baud rate will usually be locked at 19200 or
38400, with the modem itself changing speeds to communicate with
callers appropriately, while always communicating with the system
at the higher rate. When this option is set to "Y", the modem
baud rate will be set by FX-BBS only once at program start-up, to
the maximum baud rate specified on Screen A.

Start Time for SYSOP Avail, and Stop Time for SYSOP Avail:
These parameters tell FX-BBS that the SYSOP is normally available
for chat requests between certain times of the day. The times
entered here should be "military" times, ranging from 1 to 2359.
A value of zero indicates to FX-BBS that the parameter should be
ignored. These parameters may be used with or without a front-
end program, but were added primarily due to front-end
considerations. It would be a pain indeed, if the SYSOP had to
keep turning on SYSOP available every time the front-end invoked
FX-BBS, or had to leave it on all the time...

Minimum Access Level Required for This Node: In a multi-line
configuration, this parameter allows a SYSOP to reserve a
particular line or lines for callers who have an access level
above a certain level. Presumably, this would allow rewarding
callers who contribute money or a significant number of uploads.

Auto Message Repack Time: FX-BBS will automatically invoke the
FXREPACK program in the wee hours if you wish. Specifying a
value of zero here indicates that FXREPACK is not to be
automatically invoked. If a value of other than zero is desired,
it should range from 0001 to 1159. FXREPACK can not be invoked
after 12 noon. Additionally, FXREPACK cannot be invoked if FX-
BBS is not running obviously. This means that when used with a
front-end program, this particular option will not be able to
work and repacking of messages must be accomplished from the
batch file or manually instead.

Repack Option: When Auto Message Repacking is to be performed
(refer to above parameter), this is the option FX-BBS is to feed
to FXREPACK. Entering a "D" here indicates that messages are to
be deleted if flagged for deletion. Entering an "A" here
indicates that FX-BBS should remove from the message files only
those messages which have been killed dead by the callers, if
they can, or by the SYSOP.

- 73 -

FX-BBS Installation and User's Guide

Message Repack Purge Level: Also used in conjunction with the
above parameters, this specifies the total number of messages
FXREPACK will retain in each message section. If you've entered
200 here, and FXREPACK finds a total of 231 messages in a
particular section, FXREPACK will discard the oldest 31 messages,
such that only 200 remain. Note that this particular parameter
is used in conjunction with those listed on Screen F. When this
parameter is nonzero, the LESSER number of messages will be
retained in each message section. That is, if this parameter is
set to 100, no message section will be permitted to contain more
than 100 messages, regardless of parameters entered on Screen F.
Similarly, if this parameter is set to 100 and the Screen F purge
level specified is 50, only 50 messages will be retained in that
particular section.

Your Zone Number:
Your Net Number:
Your Node Number:
Host Net Number:
Host Node Number: These parameters all relate to the processing
of echo and net mail. When you are assigned your net and node
number, you will want to enter them here, along with the net and
node number of your Host, or Boss system.

Origin Line (First Half) and Origin Line (Second Half): These
lines are joined together at run time by FX-BBS to make a
complete origin line. The first part of the completed origin
line required by FTSC001 is the phrase " * Origin". This part is
supplied by FX-BBS and should not be entered here. Another
portion of the origin line is also built by FX-BBS, namely the
zone, net and node number portion, which is added to the end of
the origin line. This is of the form "(Z:NET/NODE)". For
example, my own would be listed as "(1:208/204)". The origin
parameters solicited here then are simply the comments that you
wish to place into the origin line. Your total origin line
length should be less than 72 characters. My complete origin
line, as appended to echo mail messages, is presently

" * Origin: -=BerthaBoard=- Manteca, Ca. 209-823-0093 [HST] (1:208/204)"

- 74 -

FX-BBS Installation and User's Guide

Screen N. System Parameters

This screen and the default values appear as follows:

Call Statistics

Total Number of Calls: 0
Total Calls at 300 Baud: 0
Total Calls at 1200 Baud: 0
Total Calls at 2400 Baud: 0
Total Calls at 4800 Baud: 0
Total Calls at 9600 Baud: 0

Memory Allocation Parameters:


Address for Array Buffer: 0 (Default Value *IS* 0)
Address for Receive Buffer: 0 (Default Value *IS* 0)
Address for Transmit Buffer: 0 (Default Value *IS* 0)
Address for Message Buffer: 0 (Default Value *IS* 0)

Depress Cursor Up, Down, Return or Escape for Previous Screen

Call Statistics:

The first six parameters on this screen are from the STATS.BBS
file and summarize the history of your BBS with regard to the
number of calls at each of the possible different baud rates as
well as the total number of calls your system has received. Most
of the time, there is only one STATS.BBS file maintained for all
copies of the program running. At least, this will be the case
when all copies of the program are run from the same directory.
If you run a multi-line system with totally separate setups (for
example, if you run one line as a general BBS and another as a
line dedicated to games, with separate doors, menus, downloadable
files and so on), there will be a separate STATS.BBS file for
each of the lines. The fields as presented here will represent
the values contained in the STATS.BBS file located in the
*current* directory. Unlike other files associated with FX-BBS,
this particular file has no path associated with it. This is
done simply because the values in this file are processed by the
FXBSETUP program (while FXBSETUP is made aware of the primary BBS
operating path on the appropriate screen, this variable is under
user control, so FXBSETUP cannot depend on it as the location of
the STATS.BBS file).

- 75 -

FX-BBS Installation and User's Guide

This information is editable for those of you who may be changing
from another BBS program. Generally, these fields should not be
edited. If you do however, note that the total calls at each of
the baud rates represents 100% of the calls received, and should
together, equal the total number of calls... Note too, that
this is not all of the information contained in the STATS.BBS
file. During operation, other information is added to it for
reporting purposes and to communicate with other copies of the
program that may be running. While the FXBSETUP program does
not delete this information deliberately, there is also no
guarantee that it retain this information.

Memory Allocation Parameters:

These parameters might best be left alone... Just be sure
they're all set to zero and forget them. I'm quite serious when
I say that they are tricky to use, and present a potential source
of problems as you later make changes to the system. They are
quite hazardous, and are provided solely for those of you
attempting to place more of a burden on your system than it was
meant to or is really capable of handling. In the hands of a
knowledgeable user, these parameters can have significant value
even if they will represent a source of problems at time. Should
they be set incorrectly however, I exaggerate only slightly by
saying that they can be deadly, indeed.

These parameters allow you to change, in different ways, the
location in memory of data and buffers used by FX-BBS. These
buffers and arrays fall into three different categories. First,
all arrays large enough to have an effect on memory consumption
are contained in a buffer whose location is determined at run
time. Second, the buffers used for transmitting and receiving
data via the com port are allocated at run time. Lastly, the
message and file transfer buffer is also allocated at run time.

The amount of space required for array data items is
approximately 10Kb (actually a little less, but subject to change
by myself... So assume 10Kb is an accurate figure). The async
receive buffer is 1Kb in size, and the transmit buffer is
variable as specified by the communications optimization
parameter listed (and described) on Screen L, from a low of 512
bytes to a high of 8Kb. The message buffer requirement is a
function of the maximum number of lines you wish to allow for
messages (contained and described on the second message parameter
screen, Screen E). It is NEVER less than 8.5Kb, but can be as
large as 64Kb. When you allow messages with greater than 99
lines, you can determine the space required for the message
buffer by multiplying the number of lines you've specified times

- 76 -

FX-BBS Installation and User's Guide

You are given your choice of three different ways of dealing with
selecting memory for each of these items. For EACH of the
categories of data or buffers described above, specifying the
following values has the indicated result:

Value: Action:

0 FX-BBS will allocate normal Dos memory space for the
data or buffer in question, in which case, each
Desqview or DoubleDOS window will hold the data and
buffers and you'll save no memory at all. This is how
it's been all along, and most of you will keep it this
way. It is the *only* option presenting "no hazard."

1 FX-BBS will allocate EMS memory to hold the data item.
Note that the async transmit and receive buffers CANNOT
be placed into EMS memory. If you specify a value of 1
for these two items, they will be allocated in normal
Dos memory. The amount of EMS memory requested to hold
array data is 1 page (16b). The amount requested for
message data is 3 pages (48Kb). The pages in question
are mapped constantly into the page frame any time a
copy of FX-BBS is running.

Greater Specifying a hex value of 0xB000 or above will cause
FX-BBS to assume that the value indicates the segment
address of the buffer to be used, ABOVE SCREEN RAM.
For example, I use a Hercules monochrome monitor on my
system, which is equipped with 32Kb of memory (mostly
for graphics). Only the first 4Kb is used for screen
displays, since I never do graphics on that monitor.
Therefore, I could enter a value of 0xB100 to tell
FX-BBS to place data in the video card's buffer
immediately following the memory used for the display.
If I were using QEMM or QRAM (both of which are
products from Quarterdeck used to move expanded or
extended memory to areas above screen memory), I could
determine where free memory existed and tell FX-BBS to
place its data there.

By supplying these parameters, however dangerous they are, I've
allowed you to free another 6 to 79Kb of memory from Dos's
address space, for EACH copy of the program running. On a system
using the overlay version and running 3 or 4 lines, that's on the
order of 240-300Kb. Perhaps now you can understand why these
parameters are supplied at all. When these parameters are
employed, the overlay version of FX-BBS can be run in as little
as 100-110Kbytes of memory.

- 77 -

FX-BBS Installation and User's Guide

Some things to consider:

A. Remember that presently, FX-BBS will free the message/transfer
buffer before executing any door or external file transfer
programs. If you are running these types of programs in a
SPAWNED manner, placing the message/transfer buffer above address
0xB000 probably isn't worth doing (FX-BBS cannot "free" such a
buffer when it is so located, so that memory will not be made
available for use by other programs).

B. If you specify that EMS memory is to be used for either the
data arrays or the transfer/message buffer, several pages will be
allocated: one page will be allocated for the data array, and
three pages will be allocated for the message/transfer buffer.
When the message buffer is located in EMS memory, it CANNOT be
larger than 49152 bytes. Therefore, your messages cannot be set
to be larger than 599 lines. If you specify larger messages than
this, FX-BBS will reset the maximum number of lines to 599.

C. Again, the async transmit and receive buffers CANNOT be placed
into EMS memory! DesqView will take care of assuring that EMS
memory is properly mapped into place each time each copy of the
BBS program is running. But the async drivers are ALWAYS
running, and therefore ALWAYS have to have access to the transmit
and receive buffers. This is why EMS memory cannot be used for
that purpose.

D. DoubleDOS probably will NOT make sure the right EMS memory is
in place each time tasks are switched. You should therefore not
use EMS memory for more than one copy of the BBS program when you
are using DoubleDOS. This will probably hold true for other
similar multitasking programs. If the documentation does not
clearly indicate that EMS memory pages allocated to a particular
task are mapped in and out with that task, you should NOT use EMS

E. EMS memory is EXPANDED memory. This type of memory is bank
switched into a single 64Kb page frame located somewhere above
location 0xA000:0. Extended memory is a sort of "normal" memory
in that it is linearly mapped into the cpu's address space, but
is usually more difficult to access since it is located above the
address of 0x100000 (above address 1,000,000). FX-BBS CANNOT
386 is capable of making a 386's EXTENDED memory emulate EXPANDED
memory, as well as mapping memory between locations 0xA000:0 and
0xF7FF:F into whatever "holes" exist. Pardon the capitalization
of certain words. I've done this to stress that there is a
difference between these types of memory.

- 78 -

FX-BBS Installation and User's Guide

F. You will need to exercise extreme care in assuring that the
various areas of memory used by FX-BBS not only don't overlap
with one another, but also don't overlap with Dos programs which
might be loaded above screen ram. Each time you change your
system's configuration, you'll need to verify again that there
are no conflicts, or suffer the consequences, which could be
quite severe! Think about the situation where you have file
buffers loaded in high memory, and then change the system such
that they'll overlap with FX-BBS's memory assignments. You might
end up with part of someone's message saved into an uploaded
file, or part of a file being read (passwords?) being placed into
someone's message as they edit it.

G. If you're using your EMS for other purposes, such as a ram
disk or a print spooler, you should not attempt to use EMS with
FX-BBS, or at the very least, should test it quite extensively!
Much preferred would be the use of EXTENDED memory for ram disks,
disk caching, print spoolers and so on. On a 386 using QEMM,
you can specify that a portion of extended memory should be
excluded from being dealt with as expanded memory. On a 286,
well, I don't know what your options on a 286 are. Especially if
you use your system for supporting something other than a BBS,
you should probably NOT use these parameters!

H. FX-BBS will use some force to keep the EMS memory it owns
mapped into its address space. Each time the program does a file
read, it will check for the existence of its EMS memory and if
not currently mapped, will remap it. This means that if another
program or device driver attempts to map its EMS memory into the
page frame, FX-BBS will override it 90% of the time. It's
possible that the program might crash the remaining 10% of the
time, since it can't always trap for mis-mapped memory. Perhaps
you'd like to argue about this. Doesn't matter for now. You've
been warned...

J. Determining what free memory exists above address 0xB000:0
which can be assigned for use by FX-BBS is up to you. QEMM's
LOADHI program reports whose using what, if you type LOADHI with
no other arguments. You should note however, that DesqView likes
to use high memory that other programs are not using. I'm doing
some research to figure out how to prevent DesqView from using
these memory areas, but I've not finished it as yet and it may be
a while (there are other things to do). In the meantime, try
running the LOADHI program in a DesqView window to determine
whether any free exists, and I can say that DesqView will NOT use
the end of screen ram, even if it's not used for other things.

- 79 -

FX-BBS Installation and User's Guide

I. FX-BBS should be able to use any EMS board, whether EMS 3.2,
EMS 4.0 or EEMS. FX-BBS should NOT be used with software
emulating EMS. In general, such emulation software probably
shouldn't be used. To operate, it must allocate a 64Kb area of
memory below screen ram and then move things into and out of this
space from either extended memory or a hard disk. For FX-BBS,
this would clearly gain nothing.

QRAM on a 286 allegedly (I've not yet tested that program) can do
similar things on a 286. That is, QRAM can map EXPANDED memory
into areas above location 0xA000:0. I do not think it can map
EXTENDED memory there however, since the word "EXTENDED" seems to
be missing from all I've read about the program. There is also a
public domain or shareware program running around that is capable
of mapping EEMS memory into the first megabyte of the cpu's
address range, but again, this program cannot apparently deal
with extended memory.

I assume you're all probably blown away and confused horribly by
all this, and are damning me to the ends of the earth, or other
places, for even *thinking* about providing these capabilities,
much less actually doing so. Or at least one or two of you are.
To help you cope (or play a cruel joke, depending on your
perspective), I'll offer a few hypothetical configurations. Note
that in the examples below, complete hex addresses are specified.
When you enter the parameters on Screen N of the setup program,
you must enter only the segment portion. That is, you would omit
the ":0" portion of the address given in the examples. This
means that the ":0" is assumed, and that the addresses you supply
to FX-BBS are by definition, aligned on a paragraph basis
(divisible by a decimal value of 16).

Remember, hex numbers are base 16. The decimal value of 1024 is
equal to 400 in hex. A hex value of 4000 is equal to a decimal
value of 16384. Also, note that when you enter these values on
screen N, you MUST enter the leading "0x" to tell FX-BBS that it
is in fact, a hex number. If you have trouble thinking in
hexadecimal, or converting values to and from hex, you might look
for an inexpensive calculator with hex capabilities. Some TSRs
with pop-up calculators also support this sort of thing.

1: 286 system with 1meg of memory, configured as 640Kb of main
Dos memory, and 384Kb extended. Hercules monochrome monitor.
The QEXT device driver is loaded, using 64Kb of extended
memory. VDisk is used to support a 320Kb ram disk, in which
the FX-BBSOV program is placed. 640Kb of memory exists for
Dos. DesqView reports 495Kb of memory for opening windows.
No EMS memory. The only memory above location 0xA000:0
possible to use starts at address 0xB100:0, the Hercules
screen memory.

- 80 -

FX-BBS Installation and User's Guide

3 DesqView partitions:

Partition 1 is 180Kb and runs BinkleyTerm as a front end to
the overlay version of the BBS program. This is about the
current minimum for the overlay version of BinkleyTerm and
the nodelist information it loads into memory. The OpusCom
device driver is loaded into the partition, not prior to
DesqView, to prevent interference with the third com port.

Starting Addresses:
Async Receive Buffer (1Kb): 0xB100:0
Async Transmit Buffer (2Kb): 0xB140:0
Data Array Memory (10Kb): 0xB1C0:0
Message Buffer: 0
Total High Memory Used: 13Kb

Partition 2 is 170Kb in size and runs FX-BBS directly,
allowing external protocol programs and perhaps doors to be

Starting Addresses:
Data Array Memory (10Kb): 0xB500:0
Async Receive Buffer (1Kb): 0xB771:0
Async Transmit Buffer (2Kb): 0xB7b1:0
Message Buffer: 0
Total High Memory Used: 13Kb

Partition 3 is 140Kb in size. It does NOT support external
transfer programs or doors. All high memory available has
now been used for the other two partitions. This copy of
the program therefore must specify a value of 0 for all
parameters to force FX-BBS to allocate memory from Dos,
within the partition.

Starting Addresses:
Data Array Memory (9Kb): 0
Async Receive Buffer (1Kb): 0
Async Transmit Buffer (2Kb): 0
Message Buffer: 0
Total High Memory Used: 0Kb

2: 286 system with 1meg of memory, configured as 640Kb of
main Dos memory, and 384Kb extended. The QEXT device
driver is loaded, using 64Kb of extended memory. VDisk is
used to support a 320Kb ram disk, in which the FX-BBSOV
program is placed. 640Kb of memory exists for Dos. DesqView
reports 495Kb of memory for opening windows. 2Mb of EMS
memory is available, and the QRAM program has been used to
fill up holes in high dos memory.

- 81 -

FX-BBS Installation and User's Guide

4 DesqView partitions, all equal in size at 123Kb. FX-BBS
only is being run in each window. No external protocols
are available, and the only doors which may be run are
exited to and not spawned:

Partition 1:

Starting Addresses:
Async Receive Buffer (1Kb): 0xF000:0
Async Transmit Buffer (1Kb): 0xF040:0
Data Array Memory (10Kb): 0xF080:0
Message Buffer: 1
Total High Memory Used: 12Kb
Total EMS Memory Used: 48Kb

Partition 2:

Starting Addresses:
Data Array Memory (10Kb): 0xF300:0
Async Receive Buffer (1Kb): 0xF600:0
Async Transmit Buffer (2Kb): 0xF640:0
Message Buffer: 1
Total High Memory Used: 13Kb
Total EMS Memory Used: 48Kb

Partition 3:

Starting Addresses:
Data Array Memory (10Kb): 0xD800:0
Async Receive Buffer (1Kb): 0xD840:0
Async Transmit Buffer (2Kb): 0xD8C0:0
Message Buffer: 1
Total High Memory Used: 13Kb
Total EMS Memory Used: 48Kb

Partition 4:

Starting Addresses:
Data Array Memory (10Kb): 0xDB00:0
Async Receive Buffer (1Kb): 0xDB40:0
Async Transmit Buffer (2Kb): 0xDBC0:0
Message Buffer: 1
Total High Memory Used: 13Kb
Total EMS Memory Used: 48Kb

Again, I am not yet as familiar with QRAM as I might be. I
assume however, that if memory can be mapped in this manner,
that EMS memory can be mapped into locations starting at
0xA000:0, as QEMM supports this on a 386 system. If not,
there's the public domain/shareware program previously
mentioned which can accomplish this when an EEMS board at
least is used. Given this, and use of a CGA monitor, an
additional 96Kb or so of memory should be available to Dos,
meaning that free memory before starting DesqView should be on
the order of 700Kb. If this is in fact the case, the size of

- 82 -

FX-BBS Installation and User's Guide

each partition could be increased to 175Kb. In that
situation, a total of 480Kb of EMS memory would be in use by
FX-BBS and QRAM. Since no other windows could be opened, an
EMS board with 512Kb of memory would be adequate.

3: A 386 system running QEMM, equipped with one megabytes of
memory and a VGA adapter. Some significant amount of code,
drivers and buffers have been "loadHi'ed", so that memory free
after booting is 603Kb. 32Kb has been determined to be free,
and located where the empty basic rom socket is supposed to
live, at address 0xF000:0. Another 16Kb of free memory is
assumed free and located at address 0xDD00:0. The EMS page
frame is around, and though it doesn't matter greatly, we will
assume it to be located at address 0xE000:0. Other programs
are loaded into memory between locations 0xC800:0 and
0xDCFF:0. The hard disk controller takes memory from
0xC000:0 through 0xC7FF:0. Screen ram is located from
0xA000:0 through 0xBFFF:F. Since the VGA is used in 50 or 60
line mode, this memory is not available for our use.

3 DesqView partitions:

Partition 1 is 220Kb and runs BinkleyTerm as a front end to
the BBS program. This is about the current minimum for the
overlay version of BinkleyTerm and the nodelist information
it loads into memory. The OpusCom device driver is loaded
into the partition, not prior to DesqView.

Async Receive Buffer (1Kb): 0xF000:0
Async Transmit Buffer (1Kb): 0xF040:0
Data Array Memory (10Kb): 0xF080:0
Message Buffer: 1
Total High Memory Used: 12Kb
Total EMS Memory Used: 48Kb

Partition 2 is 220Kb in size and runs FX-BBS directly,
allowing external protocol programs and perhaps doors to
be spawned.

Starting Addresses:
Data Array Memory (10Kb): 0xF300:0
Async Receive Buffer (1Kb): 0xF600:0
Async Transmit Buffer (2Kb): 0xF640:0
Message Buffer: 1
Total High Memory Used: 13Kb
Total EMS Memory Used: 48Kb

- 83 -

FX-BBS Installation and User's Guide

Partition 3 is 220Kb in size and runs FX-BBS
directly, allowing external protocol programs and perhaps
doors to be spawned.

Starting Addresses:
Data Array Memory (9Kb): 0xDD00:0
Async Receive Buffer (1Kb): 0xDD40:0
Async Transmit Buffer (2Kb): 0xDDC0:0
Message Buffer: 1
Total High Memory Used: 13Kb
Total EMS Memory Used: 48Kb

You'll note that 3 times 220Kb for each partition is 660Kb,
more than there is of main memory. Well shucks... 386's are
supposed to be able to do this sort of thing, while 286's
can't. In fact, one would be able to open a fourth (and a
fifth and a sixth) 220Mb window, with no ill effects, due to
the virtual 8086 method now employed. I don't trust such to
always run properly however... I have been able to sometimes
crash background communications tasks by heavily loading the
system with other compute intensive tasks. For example, have
Sprint repaginate this document while Turbo-C rebuilds
completely FX-BBS. Both of those tasks are however, very
large windows, at 500Kb each, and are compute intensive,
requiring a significant amount of foreground processing time.
This is not so likely for FX-BBS since it bends over backwards
to cooperate with other programs which might be running, and
since it does not have the data throughput requirements of a
compiler or word processor performing an intensive task. So
while the above rearrangements of memory might not exactly be
required for a 386, they make me feel just a bit better.
Especially if network software is loaded prior to running
DesqView. (on the 386SX used for my own BBS, I have one line
configured to use spare screen ram for the async buffers, the
other uses only normal DOS memory. The windows in use exceed
640Kb, and there are no ill effects resulting from this. The
only problem I've had at all is when I've forgotten screen ram
is in use for something serious and have tried to run a
graphics program...)

4. I'm not going to go into a great deal of detail here, but
for SOME 386's with only 1 meg of memory, it is possible to
use the the configuration described above under example 2
(with the exception of the ram disk). It depends on whether
the bios will force the 384Kb left over to be used as shadow
ram or not. One sysop's 386SX for example, can be used in
this manner. And since he uses a CGA monitor, he could
establish four active partitions each of about 170-175Kb in
size by telling QEMM to map ram between locations 0xA000:0 and
0xB7FF:F. Even should he only run one copy of FX-BBS, it's
possible that by employing these parameters, he might increase
the amount of memory available for use by other programs.

- 84 -

FX-BBS Installation and User's Guide

Other configurations are certainly possible. In example 3 above,
usage of EMS memory might be disregarded, and the data array
memory could be located in each of the DesqView windows, leaving
only the async buffers located high, perhaps all in the same 32Kb
memory range. Remember that the size of the async transmit
buffer is a function of the value you specify for communications
optimization. One might also simply tell QEMM to exclude using
video memory between locations 0xB000:0 and 0xB7FF:F, and then
use this 32Kb to hold data used by FX-BBS.

Using these parameters successfully will probably require
considerable experimentation on your part. You can expect the
system to crash most severely if you should overlap areas of
memory, or specify memory areas where no memory in fact exists.
In these cases, your success will largely be a result of your own
patience. Not having access to your particular system, there is
little I can do to assist, aside from telling you to reset all
the parameters to 0.

If you're at all confused by all this, your best bet is to keep
each of the four different parameters set to 0, so that FX-BBS
will place them all into Dos memory.

- 85 -

FX-BBS Installation and User's Guide

Screen O. Function Key Assignments

The function key assignments screen appears as follows:

Function Key Assignments
Depress Cursor Up, Cursor Down, or Escape for Previous Screen

Screen O is new to FX-BBS as of version 3.1A. In previous
versions of the program, most keyboard inputs such as toggling
the printer on/off, exiting the program and so on, were made via
function key selections. In an effort to improve the
friendliness of the program, especially when used with 100+ key
keyboards, these functions were changed to ALT-?? combinations,
which left the majority of function keys unused. The logical
thing to do with these seemed to be to allow sysops to assign
character strings to them, allowing them to be used as "hot-
keys." The F1/F2 keys and their alt-ed versions are still
reserved for displaying the menu, shelling to Dos, running
external programs and so on.

Function keys F3 through F10 support this option. Function keys
F11 and F12 are not used presently. Under Dos, it is necessary
to add code to the keyboard interrupt handler to recognize and
act upon these two keys. Since not everyone has a keyboard
featuring these keys, and since the added code would consume more
memory, I have elected for the time being to omit acting upon
them, even though FX-BBS has its own built-in keyboard interrupt
handler. Function keys F3 through F10, however, generate
different codes when used in conjunction with the CTRL, ALT and
SHIFT keys, so that a total of 32 strings may be assigned to the
function keys, as depicted on the screen above. Each function
key can have assigned to it a string of up to 25 characters, of
any form. I'd like to say before going any further that YOU

- 86 -

FX-BBS Installation and User's Guide

would be far too easy to depress the wrong key while a caller was
online and disclose this tidbit of information.

Generally, any string you wish can be stuffed into a function
key. It may be fed to the system from any point at which a
keyboard input is legal. It will be fed to the program exactly
as entered in the setup program. No carriage return will be
output unless you've specified one on the setup screen for that
string. This may be done by entering the two character string
"^M" at the point in the string you wish to have a return fed to
the program. For example, entering "STRING 1^MSTRING2" for a
function key would cause "STRING 1" to be output, followed by a
return, followed by "STRING2".

Any CTRL code may be assigned to a function key in this manner.
To output a line feed, you would enter a "^J". To output a page
eject, you would enter a "^L" (though holding down the CTRL key
and depressing the L key seems just as simple). A tab input may
be represented by the "^I" input. The various ALT-?? keystroke
combinations may also be assigned to a function key. These
inputs are composed of a two key code input to the system (as Dos
was designed to generate), the first of which is a value of zero.
A value of zero may be entered for a function key by typing the
two characters "^". A zero value, and any other numeric value,
may also be entered by typing "^", followed by the number you
wish. To enter a value of 48 for example, you could type "^48"
(the decimal value of 48 corresponds to an ASCII value for the
character zero, but is not a byte value of zero). The input
ALT-R is composed of two byte values of first zero (0), and
second, 19. This could be entered as either "^19", or "^0^19".

Function keys may not contain the inputs required to invoke say,
four other function key assignments, at least as a single
assignment. That is, each time a string associated with a
function key is loaded for processing, it will replace any
previous one being processed. Function key assignments may
however, be "chained." That is, one function key can output up
to 21 characters and end with the control sequence of another
function key, which will cause that function key's characters to
be loaded and processed. The second function key string could in
turn, chain to an additional function key string if necessary.

A simple program to show you the byte values generated by the
computer when a given key is depressed is included with the
program now. This program is called KEYCODES.EXE. When run, it
will continue to run until CTRL-C is entered. Each time a key is
depressed, numeric values will be displayed. You may assign a
particular key's code to a function key by entering these numbers
(preceded by the necessary "^" character) in the function key

- 87 -

FX-BBS Installation and User's Guide

Starting FX-BBS:

Enter "FX-BBS". Assuming all required files are where they
should be and you are running with a configuration file called
FX-BBS.CFG, it should fire right up.

You may, however, specify a few command line options for the
program. Primarily, you can specify a different configuration
file for the program to use. Entering "FX-BBS TEST.CFG" for
example will cause the program to attempt to run with the
different configuration file, which might contain different modem
and COM port parameters for example. You may also add other
parameters: When "DEBUG" is entered, the program will not output
to any COM ports and may be run in keyboard mode only. The
message processing logic will display the PATH and SEEN-BY
parameters contained in echo and net mail messages if you run the
program with the parameter "DETAILS". Specifying the parameter
"ND" causes FX-BBS to avoid all use of direct screen writes
regardless. The baud rate or "LOCAL" parameter can be entered
here as well, when running with a "front-end" program, for
example an echo mail type of program. Specifying the "LOCAL"
parameter instead of the baud rate causes the program to assume a
local (keyboard) logon, and is again for use with the front-end
environment. These parameters must start with the SECOND
parameter. That is, to use them, you must always specify the
configuration file to use first. Running with the debug option
also may cause a few other quirky things to occur, namely,
whatever kind of program debug tool I might have left in the
code. So don't be surprised if it acts a bit strangely. It will
run none-the-less.

The Primary Display:

Most information on the primary display is self explanatory. You
should do a print screen of the function key options however. I
find that I get confused easily, owing to so many options.

Recent Callers:

The recent callers area is simply a list of the last 18 or fewer
callers. The most recent caller is displayed at entry 1, with
the oldest displayed at entry 18. Additionally, the system
number (actually, local COM port number) the call was received
through is also displayed.

- 88 -

FX-BBS Installation and User's Guide


The status area is the bottom portion of the screen. Name will
indicate the caller's name, or will say "System Available" if no
one is presently online. Access level is the access level you
have assigned a particular caller. Baud rate, number of uploads
and number of downloads are all associated with a given caller
and are self-explanatory. The Baud Rate field also indicates
what COM port number is in use. This is done in an effort to
indicate which copy of the BBS is which, should you have more
than one running in a multitasking environment. It is about the
only solid indicator of which copy is which (you can help with
this problem however, by using different local colors for
different lines, or by indicating clearly which line is which in
the BBS name on the appropriate setup screen). Time on is the
date and time at which a given call was started. Last on is the
date and time the caller last called. Note that when no caller
is online, these fields will be set to "N/A". If new mail, new
applications or comments have been entered since the last time
the SYSOP has logged on, this will also be indicated here when no
caller is online. Total today is a running count of the time the
caller has used with *all* calls today. Remaining is the time
the caller has remaining. Finally, "# Calls" counts the number
of calls made, since the last time the SYSOP was on the system.
This count is also reset each time the SYSOP logs on.

Much of the information displayed here is taken from the
STATS.BBS file. This file is accessed by one and all copies of
the program being run from a particular directory, with each
increasing the # Calls field and attempting to set and reset the
new mail, comments and answers fields. Generally this all works
just swell, though there is still sometimes a problem, it seems,
with all copies agreeing on whether or not there really is new
mail, comments or answers... Getting up to 100 copies of the
program to agree on the matter can be a bit tricky.

Mixed in with the above information are several other tidbits.
The current date and time is displayed, and is updated once each
minute when no caller is online and screen blanking is not in
effect (all status items are updated irregularly during a call.
They are not updated at all during a file transfer). The amount
of free memory is displayed, in Kbytes (note that the size of the
message buffer is not included here, though the message buffer
memory is usable by other external programs). The space
remaining on the UPLOAD disk drive is also displayed, again in
Kbytes. The fields labeled "Sysop", "Log" and "Printer" will
typically say Yes or No to indicate whether a toggle is on or
off. The Sysop status can take on a third value: when delayed
exit has been requested, "DLX" will be displayed here. The Log
status can also take on a third status, "FIL", which indicates
that the current session is being captured to a data file. When
the program is started, the keyboard is usually "dead" with the

- 89 -

FX-BBS Installation and User's Guide

exception of the home key, ALT key combinations and function
keys. Additionally, CTRL-C has been disabled as a mechanism to
abort the program. To turn the keyboard "on" or "off", depress
the HOME key. The keyboard on/off feature was provided at the
request of a SYSOP with several small children running about. My
favorite (?) thing to do is attempt to log on locally and forget
to "turn on" the keyboard (no problem: just depress the home key
and try again). The keyboard status is also displayed here.

Note that the status area is sometimes effected when a caller is
using ANSI.SYS graphics. This occurs when the file being output
performs a "clear screen" or tries to position the cursor into
the status area. Not to worry. The display will be refreshed as
soon as the program detects that this has occurred, or when the
caller hits the main command line again at the latest. However,
the screen can and will become very confusing to look at when the
caller is using graphics and invoking external file transfer
programs, etc. Just to let you know. There is little that can
be done to protect the display from external programs that write
data anywhere on screen, or from ANSI.SYS when it tries to
position the cursor into the status area.

Function Keys and Control Key Inputs:

Again, most options available are self explanatory, but a few
comments are required. In the comments following, a letter is
often bracketed with <>. In these cases, the letter bracketed in
this manner is the one I thought of for use in conjunction with
the ALT key.

HOME Key: The keyboard is "dead" when you start FX-BBS, with the
exception of the Home key, ALT key combinations and function
keys. Depressing HOME toggles whether the keyboard is "on" or

ALT-F1: Depressing this key combination will invoke the FX-Shell
program. FX-Shell is a separate program unto itself and is
documented separately. It provides many functions which are
quite handy in maintaining a BBS, including a sorted directory
display which can be either condensed or detailed, the ability
to move files, to hide or un-hide them via chmod, etc. FX-Shell
was originally written to provide an (optional) mouse interface
to Dos. It is therefore distributed in a separate compressed
file. The fact that it is so useful in operating FX-BBS is more
an accident than anything else. It's quite capable of running
without FX-BBS, as FX-BBS can run without FX-Shell. If you use
FX-Shell, you should have all files associated with FX-Shell
located in the same directory as FX-BBS in order for FX-BBS to be
able to find them. Failing that, you should be "pathed" to FX-

- 90 -

FX-BBS Installation and User's Guide

Shell. FX-Shell is invoked using the password contained in the
FX-BBS configuration file. The program will therefore require
you to enter the password before proceeding. FX-Shell is a
separate program and requires some memory to execute in. If the
FX-BBS memory display is less than around 70K, it may not run.
This function works when a caller is online, provided sufficient
memory exists for it to use. Note however that invoking FX-Shell
will suspend the caller online! His call will stop until you
exit FX-Shell. Finally, if you run the FX-Shell program when no
caller is online, FX-BBS will attempt to take the phone offhook
while the program runs, and will put the phone back onhook when
you exit FX-Shell, provided a caller is not online.

ALT-F2: This key combination can be used to invoke COMMAND.COM.
FX-BBS does NOT invoke the COMMAND.COM pointed to by comspec. It
is assumed that the standard COMMAND.COM may have been modified.
FX-BBS invokes instead, whatever program you have specified in
the configuration file. It is assumed that this is a good copy
of COMMAND.COM, but it could in fact, be any program. FX-BBS
will again require entry of a password before invoking the
program. And like FX-Shell, a certain amount of memory is
required in which to execute the requested program. As with FX-
Shell, invoking this function when a caller is online will
suspend that person's call until you exit the program you've
invoked. The logic performed by ALT-F1 processing as it relates
to taking the phone offhook and putting it back on also applies.

ALT-S, ALT-P, ALT-L: ysop Available,

rinter On/Off, og
file On/Off. All toggles, either on or off. If you have the
printer on, you'll know it, since you'll go through a lot of
paper. The SYSOP toggle indicates whether you are available for
chatting with the caller (two methods of entering chat mode
exist; you may turn on the keyboard with the HOME key and enter
"C", just as the caller would, or force a chat at most anytime by
using ALT-C).

ALT-C: This key combination "forces" a hat with the caller, if
it can be done. It will have no effect for example, during file
transfers (with the exception of ASCII file transfers). It
interrupts whatever the caller is doing, be it scanning or
entering messages, looking at the main menu, or whatever. The
chat display is divided into two parts, with caller inputs
displayed on the top half of the screen and your inputs on the
bottom half. You exit the forced chat mode in the same manner as
the main menu chat function, by typing "//QUIT". At that point,
the caller is placed back into the function that was interrupted.
The ALT-C function will automatically turn on the keyboard and
SYSOP available flags, and will leave them on when exited.

- 91 -

FX-BBS Installation and User's Guide

ALT-D: elayed exit. This combination will cause the program
to exit to Dos, but to wait until the present call has completed.
When selected, "DLX" will be displayed in the status area.

ALT-X: Eit program. Depressing this combination will cause
the program to terminate immediately, and hang up the phone if a
front-end program is not in use, *regardless* of whether a caller
is online.

ALT-T: This key combination causes FX-BBS to enter erminal
mode. Refer to the section on terminal mode operations for more

ALT-F: Capture to ile. Depressing this combination will
cause FX-BBS to pop open a window, if a caller is online, and
request the name of a file to capture modem and keyboard I/O to.
If the file name specified already exists, you will be given the
option of overwriting it, entering a different file name, or
aborting the request. If no caller is online, depressing ALT-F
will have no effect. While a log file is open, the status area
will say "Printer: FIL" to indicate that you are capturing. To
close the capture file, enter ALT-F a second time. Capture files
are automatically closed when a caller (or yourself, in terminal
mode) disconnects for any reason.

ALT-O: Force ff caller. This key combination is a one shot,
and has an effect only during a given call. Depressing this
combination will cause the "time_used" variable to be set equal
to "max_time". The result is that the caller sees a message
"Time limit exceeded for today" and the program hangs up.

ALT-H: ang up now. A little more drastic than ALT-O,
immediately hangs up the phone.

UpArrow: When a caller is online, depressing cursor up increases
the time they have available by 5 minutes with each depression. A
message is displayed to the caller as well. Applies only to a
given call. The extra time is not carried over to the next call.

DnArrow: Depressing cursor down decreases caller's time left
for this call by 5 minutes. Again does not carry over to next
call. No message is displayed for the caller in this case.

- 92 -

FX-BBS Installation and User's Guide

PgUp: Increases caller's access level by 1. This allows for
online raising of user access level. A message is displayed to
the caller, and the change in level is saved in the caller's user

PgDn: Decreases caller's access level by 1. The change is saved
in the caller's user record. No message is displayed to the

ALT-B: Depressing this combination causes the program to simply
output a message to the caller asking him/her to finish soon. No
letter really comes to mind as justifying this particular
combination... How about eg?

ALT-Z: ero time used. Depressing this key combination will
reset the amount of time a caller has used during a given day.

ALT-N: Sysop ext. This combination is used to force the SYSOP
to be the next caller who logs onto the BBS system. This is
useful when there are a sufficient number of callers to make
logging on from the keyboard difficult.

ALT-R: Causes a eload of the configuration file in use. This
allows the configuration file to be changed and reloaded, even
with a caller on line. However, changes to memory allocation
parameters have no effect on a configuration file reload.

- 93 -

FX-BBS Installation and User's Guide

Logging On:

If screen blanking is enabled, depressing any key, or detection
of an incoming call, will cause the screen to re-display. If an
incoming call is determined not to be a computer (a wrong
number), nothing will happen and the program will go back to
sleep after a short period of time. Receipt of a call from a
modem, or depressing the space-bar when the keyboard is enabled
will cause the screen to refresh and then be cleared. A message
will be displayed indicating either a local or remote logon (once
the baud rate is determined), followed by a brief program version
message, information indicating the registration status of the
program, and a question asking whether the caller wishes ANSI
compatible graphics to be output. The caller can answer "Y" or
"N" for Yes or No, or "C", which causes FX-BBS to convert all
non-ASCII characters (such as IBM's box drawing characters) to
the "!" character. This allows menus to be displayed in a
somewhat reasonable manner on non-IBM compatible computers, such
as Commodores, Ataris and Apples.

Following this, the file WELCOME.TXT is displayed and the caller
is asked to enter their first and last names. Total length of
these parameters cannot exceed 29 characters. The program will
ask the question up to five times before deciding that a joker
may be online and hanging up. Should any illegal name fragments
be encountered (see FXBSETUP screen K), the caller will be
disconnected after soliciting a comment intended to allow them to
explain exactly why their mother named them so bizarrely.

The caller is next asked for a password ranging from 4 to 14
characters in length. If the caller is new to the system, the
password will be requested twice for verification. If a
previously existing caller cannot correctly enter their password,
the program gives up after 4-5 tries and offers the caller the
opportunity to ask your assistance in a comment.

If the caller is new, the caller's location (city/state) will be
solicited next, and they will be afforded the opportunity to
change their default selections as described for main menu
command "I".

Following this, any existing LEVELx.TXT file for their particular
access level will be displayed, along with the NEWS.* files.
Callers cannot CTRL-C during these displays. Bulletins will then
be processed, with a notice of new or changed bulletins displayed
before the primary bulletin file is output. If a logon door has
been provided, it will be executed next.

Once all this is completed, the caller will (finally) be
presented with the main menu.

- 94 -

FX-BBS Installation and User's Guide

Main Menu Options:

Again, most options will be self explanatory, but some
observations are made here. The menu file displayed can be
different if the caller is the SYSOP. Additionally, it may come
from the graphics path, or standard text path. It should
describe all options displayed by the program's command line, but
this is not absolutely necessary.

Statistics: (%) Entering the "%" character from the main menu
causes the statistics sub-menu to be presented to the caller. A
list of eight options is provided. The [C]all Statistics option
causes the program to display the total number of calls received
by the system, and to calculate the percentage of calls received
at 300, 1200, 2400, 4800 and 9600 baud. The program then uses
the FX-BBS.LOG file to determine the number of calls received
during the past week according to time of day received (As with
the COMMENTS.BBS and COMLOGxx.BBS files, the file FX-BBS.LOG is
self regulating in size. If a very large number of calls has
been received in the past week, required data for the earlier
portion of the week may have been disposed of. After some 800 or
so records are entered, the program will drop the oldest records
in order to keep the file from growing too large).

The [R]ecent Caller List option is used to display a list of all
members of the BBS, along with their access level, number of
uploads and downloads, the date and time they last called, and
what conferences, if any, that both the current caller and the
one currently being listed, belong to (this is done to keep
private conferences private). If the caller is the SYSOP,
passwords will also be displayed.

The [L]ist BBS Members option displays a detailed log of the last
several calls received (more than most folks will likely want),
also using the FX-BBS.LOG file.

The [F]ind a Particular BBS Member function uses the same logic
as the List BBS Members option does, but searches for a single
user rather than all.

The [P]opular Downloads option displays a list of the most
popular downloads made, sorted according to frequency of
downloads. Some 40 such titles will be presented, and the
information used to determine the number is obtained from the
file HISTORY.DNL. Should you experience problems with this
function, check for corruption of the HISTORY.DNL file. It is a
standard ASCII text file.

Selecting [T]op Uploaders and Downloaders will cause FX-BBS to
search through the user file and determine the top 20 callers for
the most downloads and uploads, and present this list to the

- 95 -

FX-BBS Installation and User's Guide

The statistics function can be terminated by selecting [Q]uit to
return to the BBS main menu, or [G]oodbye to disconnect.

Status: (#) Displays a few tidbits of status information, such as
the caller number, number of messages, number of downloads and
uploads, etc. Also displays the name of any caller who might be
on other nodes in a multiple phone line BBS, as well as whether
or not the SYSOP is available for chats or help.

Password: (P) Allows caller to change his/her password.

Install: (I) Allows user to change parameters associated with
his/her COM program/computer system, for example terminal screen
length, bell on/off, etc.

List Compressed File: (^) FX-BBS will ask for the name of a
compressed file to list. If the file is found, FX-BBS will
attempt to list the files (and their sizes) contained within the
compressed file. Note that files compressed by PKZIP or PKARC
will be flagged as requiring PKUNZIP or PKXARC, respectively, as
necessary. Presently, the function can accommodate most ARC and
ZIP files, as well as PAK files (the latter by accident of the
PAK program designer it seems). The program also processes LZH
files, but determines that a file was compressed by LHARC solely
by examining the extension (there seems to be no flags imbedded
in these files indicating the program used for compression). ZOO
files are not yet processed, but I anticipate adding this support
at some point or another. New compression methods are constantly
appearing, but I can't say whether a particular one will be added
at any time. Wild cards are not supported by this function.

Re-display News Files: (!) This option allows callers to look
at any existing NEWS.* files. Normally, these files are only
output at the time of logon, and only if the date of the file(s)
is later than the date of the caller's last call. This option
allows the news files to be re-examined in the event the caller
may have missed something important.

Whereis: (W) Asks the caller for a standard Dos file mask, and
then searches for these files. If a match occurs, FX-BBS will
display the file name, date and size. Entering "*.*" as the mask
would cause all downloadable files to be listed. Other wild card
combinations may also be used, such as "*.ARC", "??ARC.*" or
"TC*.*", for example. Note that only file names are displayed,
and not directory names. Following the search for all files
matching the wild card specification, the caller is presented
with the option of searching the directory descriptions for the
descriptions of the files found.

- 96 -

FX-BBS Installation and User's Guide

Files: (F) Causes the main directory text file (DIR0) to be
displayed, after which, the program will ask for a number which
indicates the directory number to next display. There is no real
upper limit on the number of directory files available. When FX-
BBS cannot find a particular directory number entered by a
caller, it will default to displaying the recent uploads
information if such is allowed. You may therefore suggest in
DIR0 that callers may enter any number not in use for another
purpose in order to see the upload directory listing. The recent
uploads information will also be output any time a caller
requests a directory area belonging to a conference the caller is
not a member of. Doors may be configured as selectable from the
files menu if one wishes. Such doors will be selected by
entering a directory number greater than 100 (though this is not
strictly required; that is, a normal directory listing may also
be numbered higher than 100). The "F" option itself provides one
additional option beneath itself, "D", allowing callers to
immediately download without needing to return to the main menu.
Callers who belong to a given conference will be told of the
conference directory number(s) before the main DIR0 file is

Upload/Download: (U/D) Allows user to upload or download files.
For downloads, the caller can enter either the exact file name
desired, or use wild cards to accept the *first* matching file
for download. If the file requested cannot be located, the name
of the file to send will be requested again. For uploads, after
the caller enters the name of the file to be received, a search
of the system is made to determine whether or not that particular
file, or one with a similar name but different extension, already
exists. If an exact match is found, the upload is refused. If a
similar file name is found, the caller is notified of the file's
existence and asked whether or not they wish to proceed.

File descriptions for uploads are solicited prior to the uploads,
so that should the caller walk away from her/his computer during
or following the upload, there won't be a missing description.
This is the primary reason for not allowing batch uploads; there
is presently only one file description buffer, which is memory
resident). Uploaded files may be described using up to 20 lines
of text (in the format required for all file directories), and
the name of the uploader along with upload date and time are
maintained. Files uploaded may be specified as belonging to a
conference or can be made private for the SYSOP. This involves
setting the Dos hidden attribute. Private files ARE available
for all to download, if they are in a normally accessible
directory. The names of these files however, are not displayed
unless the caller is the SYSOP. Files may be hidden or un-hidden
by options on the SYSOP menu, by using the FX-Shell program, or
by using the CHMOD utility program included with FX-BBS. To Un-
Hide all files in upload path C:\UPLOADS, the command would be
"CHMOD C:\UPLOADS\*.* -H". The backslash after the colon is
REQUIRED. Files may also be designated as belonging to a
conference, when the caller is a member of a particular

- 97 -

FX-BBS Installation and User's Guide

conference. While files in conference directories are accessible
only by conference members, files uploaded for a conference are
presently placed into the normal upload directory, so might
possibly be accessed by all callers.

Internally supported protocols presently include ASCII, Sealink,
Xmodem, Xmodem CRC, and YModem - CRC transparent. The version of
Ymodem supported is actually more properly called 1K-Xmodem, and
is so labeled on the upload/download menus. It does NOT support
batch mode transfers, and is therefore not true Ymodem. Sealink
however, as implemented in FX-BBS, does support batch file
downloads. Additional internally supported protocols will be
added later, but perhaps only to the overlay version of the

External file transfer programs are also supported. Refer to the
FXBSETUP program for more information on setting these up. If
external transfer programs are in use, they will be listed as
protocols 4 through 9 when a caller enters U or D, and are
selected as the other protocols are, by entering the first letter
of the protocol desired. Remember that external transfer
programs require memory to run. PCKermit requires about 75K, DSZ
about 66K. Be sure that FX-BBS reports at least the amount of
memory required on the status display for your largest external
program, or that the size of your message buffer (specified on
FXBSETUP Screen D) plus the amount of space shown on the status
display is adequate. Note: Depressing ESCAPE on the local
keyboard at any time aborts a transfer being made with an
*internally* supported file transfer program.

Batch downloads (but not uploads) may be supported via usage of
certain types of external file transfer programs. Refer to the
FXBSETUP screen discussing external transfer programs for more
information. When batch downloads are allowed for a particular
protocol, the user is asked repeatedly for filenames to transfer.
After each filename is entered, the drive(s) are searched for
that file. When found, the total byte count and time to transfer
is reported. If the size is too large to transfer in the time
remaining, or if it would exceed the upload/download ratio
imposed for that caller, the download of that particular file is
not allowed. The caller indicates that the list of files to be
transferred is complete by depressing enter on an empty line.
The caller may also abort the transfer by entering 'Q' instead of
a filename.

- 98 -

FX-BBS Installation and User's Guide

Answer Questionnaire: (A) Allows the caller to select a
questionnaire and answer questions within. Questionnaire files
are named QUESTx.BBS, where "x" is a letter from "A" to "F".
Questionnaires available should be listed in the file

Questionnaire files are simple ASCII text files which have the
reserved character "~" after each question. Questions may be of
any length, and may have paragraphs if necessary. All
information is output until a "~" is encountered. At that point,
an answer is solicited. The "~" may appear in column 50, 63, 1
or wherever required. Wherever the tilde appears, FX-BBS will
stop outputting and solicit an answer at that position on screen.
Answers are one line in length. If the cursor is positioned to
column 1, a relatively long answer can be entered. If positioned
to column 50, the input will of necessity be shorter.

Answers to questionnaires are stored in files named ANSWERSx.BBS
in the usual reverse order. The caller's name and time of the
answer is indicated. The questions themselves are not stored in
the file to save space. Answers are labeled however, with 1, 2,
3 and so on. It is suggested elsewhere that the maximum number
of questionnaires is six, and that no more than 25 questions may
appear in each questionnaire. These limits are not in fact,
hard limits. If I didn't have a lot more work to do on this
version of the docs, I'd go look it up. Instead, I'll cop to
laziness and simply tell you to play with it if you wish to push
the limits in either category. Maybe I'll document it a bit
better next time.


Bulletins: (B) Causes the BULLETIN.000 file to be output,
followed by a request for a bulletin number to view. If a
particular bulletin is found to be newer than when the caller
last called, a message stating that the bulletin is new is
displayed. If 1 is entered, the file called BULLETIN.001 will be
presented. If 2 is entered, BULLETIN.002 will be output, and so
on. Entering "?" causes the BULLETIN.000 file to be redisplayed.

- 99 -

FX-BBS Installation and User's Guide

Chat: (C) If the SYSOP is available (see ALT-S), pages the SYSOP
for a short period of time by beeping. If the SYSOP is not
available, or does not respond after some period of time, tells
the caller this, and then asks whether he/she would like to leave
a comment (provided comments are enabled). Once chat mode is
entered, both the caller and the SYSOP can type whatever they
wish for as long as necessary. The chat screen is divided into
two parts, with caller inputs displayed on the top half and yours
on the bottom half. Both the caller and SYSOP may type at the
same time, provided both are in split screen mode. Each caller's
inputs are displayed in different colors when the caller has
selected ANSI graphics. This is true as well for forced chats
(ALT-C). To exit chat mode, either person may enter "//QUIT".

Enter: (E) Allows callers with access level of two or higher to
enter a message. Note that on multi-line systems, only one
caller may be entering a message or reading messages in a given
section at a time. If a second caller attempts to enter a
message in that section, they will be told that the particular
message section is locked and asked to try again later. Callers
must indicate what message section to use, who the message is to,
the subject matter and so on. For echomail messages, the option
to make the message private is not provided, though it is for
local and NetMail messages.

Two different methods of actually entering a message are offered
callers. The default method involves the use of a line editor
sort of logic. Lines are numbered and editing is accomplished in
relationship to those numbers. Options available following entry
of a message with the line editor logic include listing the
message, editing a line, saving the message and so on. For the
SYSOP, when logged on at the keyboard and entering messages via
the line editor logic, an additional option of [I]mporting a text
file is provided. To accomplish this, you would begin entering a
message normally, then when prompted for message text ("1: "),
simply depress enter. Select 'I', and then tell the program the
name of the file to be "uploaded." Enter the complete name and
path for the file. Following this, the file will be read in and
stored as the message. Be certain the file is correct to begin
with. No editing option is provided after an Import.

The second method of entering a message is via an ANSI.SYS driven
"full screen" editor. The commands supported by the editor
emulate those of the WordStar program for the most part, though
there are differences. When logged on from the keyboard and
entering a message using this editor, a help screen is displayed
for you. This same help screen is displayed for callers, but is
not displayed on the local screen unless logged on locally.

- 100 -

FX-BBS Installation and User's Guide

While the home, cursor up, PgUp keys, etc will work when logged
on from the keyboard, these will often not work for callers. The
primary problem is that many or most terminal programs used by
your callers such as Procomm and Qmodem for example, use these
keys for their own purposes, meaning that they do not transmit
anything to your BBS system. The WordStar CTRL-? key
combinations are therefore provided as substitutes. The specific
inputs provided are as follows:

Remote: Local: Function:
------- ------ ---------
CTRL-E Up Arrow Cursor Up
CTRL-X Down Arrow Cursor Down
CTRL-D Right Arrow Cursor Right
CTRL-S Left Arrow Cursor Left
CTRL-A CTRL-Left Go to Start of Word to Left
CTRL-F CTRL-Right Go to Start of Word to Right
CTRL-QD End Go to End of Line
CTRL-QS Home Go to Start of Line
CTRL-W CTRL-Home Top of Screen
CTRL-Z CTRL-End Bottom of Screen
CTRL-R PgUp Display Previous Screen
CTRL-C PgDn Display Next Screen
CTRL-QR CTRL-PgUp Go to Start of Message Buffer
CTRL-QC CTRL-PgDn Go to End of Message Buffer
CTRL-V INS Insert ONE Space at Current Cursor Pos
CTRL-N CTRL-N Insert One Blank Line Before Current One
CTRL-Y CTRL-Y Delete One Line (Current One)
CTRL-QY CTRL-QY Delete from Current Pos to End of Line
CTRL-KS CTRL-KS Quit Editing and Save Message
CTRL-KQ CTRL-KQ Quit Editing and Abandon Message
CTRL-KB CTRL-KB Mark beginning of block
CTRL-KK CTRL-KK Mark end of block
CTRL-KY CTRL-KY Delete block
CTRL-KR CTRL-KR Reset block markers
CTRL-B CTRL-B 'Reforms' current line with the one
beneath it. Sorta like CTRL-B in
Wordstar, but again, only effects
the line you're on and the following

The block marking options differ from those of WordStar... First,
they mark blocks on a LINE basis. You cannot mark text in the
middle of a line for example. Second, while a brief message is
displayed indicating that a block marker has been set, the block
itself is NOT displayed in reverse colors or such... Rephrased,
the block operators are very simplistic...

Note that most of the CTRL-? functions will also work from the
local keyboard. The local inputs listed above however, will
likely NOT work for a remote caller. Since many com programs use
PgUp and PgDn for accomplishing file transfers, this makes sense,

- 101 -

FX-BBS Installation and User's Guide

I've been requested to add CTRL-T and CTRL-G functions. These
will be added, but have not been as yet, so they may or may not
exist in the version of the program provided with this
documentation. Other changes may be made to this code later as
well, depending on user (your) suggestions.

Goodbye: (G) If the caller is not the SYSOP and comments are
enabled, asks if they would like to leave a comment (actually,
FX-BBS displays the disconnect string provided in the
configuration file). If Y or N is not entered, returns caller to
main menu. If Y is entered, processes a comment up to 15 lines
long. If N is entered, disconnects without getting a comment.

Help: (H) Asks the user which key help is needed for and then
outputs that help file, if found. For example, if the caller
asked for help on the "^" key, the file HELP^ would be output.

Kill: (K) Allows the caller to kill or delete a message. The
message must have either been entered by the caller, or he/she
must be the recipient. If the caller is the SYSOP, any message
may be deleted. A flag may be set in the configuration file
which prevents all callers except SYSOP from deleting any

Mode: (M) Allows the user to toggle between graphics mode and
standard text mode display files. Has no effect if the graphics
path and text path specified in the configuration file are the
same, with the exception that the ANSI color codes entered in the
FXBSETUP operation will be applied to the menus output.

Read New: (N) Checks for messages in all message sections with a
more recent date than when the caller last called, and if found,
displays the message. Dates used for testing whether a message
is new or not actually have two forms. The default form is the
full date and time the caller last logged on, including hour,
minute and second. If a caller overrides the default value, only
the date portion of the search time is solicited with the time
portion being set to zero. When reading new messages, caller
selectable options between messages are fewer than when the
caller selects the simple Read Messages function. Specifically,
the [P]revious and [#] options are not provided in this case.
Refer to the [R] messages description for more information.

- 102 -

FX-BBS Installation and User's Guide

Open a Door: (O) Presents the caller with a list of available
doors (DOORS.TXT) and then asks the caller which door is desired.
The processing performed here relates only to doors you have
assigned key values of "A" through "Z" to. If no doors are
available, the caller is so informed. Otherwise the caller is
asked which door is desired. If the door is password protected,
the caller must also enter the password. If the passwords match,
or if there is no password for the door, the command line
associated with the door is executed.

Read: (R) Allows caller to read messages. The caller must first
specify a message section number to be searched from a list which
is presented. The option is then provided to pause between
messages or not, as the caller requires. Messages within each
section may be searched/retrieved by receiver name, sender name,
subject or individual number. The option to search for only new
messages is also provided, and the caller can also modify the
date which is used to determine which messages are new. If the
caller chooses to search for messages by subject, or to or from
another caller, they will be asked for the message number to
start with. The option to search only new messages is still
provided in this case, by entering "N" instead of a number.

When messages are to be searched by subject, the caller is asked
for a particular subject or subjects to search for. The subject
entered can be of varying length, up to about 60 characters or
so. If desired, the caller can specify multiple subjects by
separating each with the Dos pipe character. This is the broken
vertical bar ("|"). To search for both "Pascal" and "Assembly"
for example, one would enter "Pascal|Assembly". Any spaces
entered will be significant, though the text being searched for
is converted to all upper case prior to performing the search.
FX-BBS does not know how to search for "near misses." If a caller
searches for the phrase "Assembly" then "Assembler" will not be
found. The caller is next asked whether they wish to search for
the subject in message headers only (the default), or to perform
a detailed search as well (search the body of the messages as
well as their headers). The latter type of searches, of course,
takes a bit longer to complete. As the messages are scanned, a
message is output for the caller indicating what message is being
processed. When a matching subject is located, a message
indicating which subject was found is output, followed by the
location the subject was found in. This will either be the
sender's name, receiver's name, message subject line, or the
particular line of text which contains the subject when a
detailed search is being made. This is done because it's not
often obvious when reading a message, what string triggered a
match, especially when word fragments are involved. Following
this, the complete message will be output.

- 103 -

FX-BBS Installation and User's Guide

Following presentation of each message, the caller has the option
of reading the [P]revious message, [N]ext message (default
selection if enter is depressed without making another
selection), selecting a particular message number to read (#),
reading a message [A]gain, [R]eplying to a message, [F]orwarding
a copy of the message to another caller, or [Q]uiting the read.

If the caller is the SYSOP and is logged on at the keyboard (not
remotely), additional options are provided. The [T]ouch option
causes an echo or net mail message to be 'reset' to not sent.
This will in turn cause FXMAIL to repack the message the next
time the program is invoked. This option is provided simply as a
contingency measure against system crashes or simply messages
getting lost in transit, and so on. The [M]ove option allows the
SYSOP to move a message from one message section to another.
This is done by simply copying the message to the new section and
then setting the delete flag on the original.

When the reply option is selected, the caller is offered their
choice of using the line oriented message editor or the ANSI
editor. If the latter is selected, the caller is additionally
asked whether they wish to quote the original message. If they
answer yes, the original message is reformatted and read into the
editing buffer, and then presented to the caller for editing.
Undesired portions of the message should be deleted using the
block operators, CTRL-Y or so on.

When a copy of a message is to be forwarded to another caller,
the copy may be relocated to another message section. Callers,
including the SYSOP, may forward any message that they can read,
regardless of whether it was originally private or not. The
message will however, be tagged with who the original sender and
receiver were, along with the message section it was in and the
original subject.

Scan: (S) Scans messages in a caller specified section starting
at a certain number. Does not provide option to read, but simply
outputs the message's header information. Approximately five
message headers will be displayed per 25 line screen.

Time: (T) Shows the caller the current time.

Expert: (X) When Expert mode is selected, the main menu is not
displayed unless the caller enters "?".

Read Your Personal New Mail: (Y) Selecting the Y option allows
the caller to scan all message sections for new messages
addressed to them. The date used by the program to determine if
a message is "new" is modifiable by the caller.

- 104 -

FX-BBS Installation and User's Guide

Join a Conference: (J) If you have configured FX-BBS to support
conferences, and the caller has an access level of two or higher,
the "J" command will present to the caller the file called
CONF.TXT, and then ask the caller which conference is to be
joined. If that conference is NOT private, the caller will be
added to that conference immediately, and the file directory
number and mail section numbers will be presented. If the
conference is private, the caller will NOT be added to the
conference, but instead, will be asked to enter a comment
indicating what conference they wish to join and why, etc. The
SYSOP can then add the caller if desired, by using the
appropriate function off of the SYSOP maintenance menu (main menu
input "7") or the EDITUSER program. Note that even though you
may have disabled comments from the FXBSETUP program, they will
still be allowed by this function.

Once a caller has joined a conference, they will remain a member
of that conference until they either execute the "Q" main menu
function, or the SYSOP removes them from that conference.

Quit a Conference: (Q) Allows the caller to Quit a conference.
If the conference is a private one, they cannot rejoin it without
the SYSOP performing the add.

Zippy Message Scan (Z): The "zippy" message scan function
differs from the normal message scan primarily in the level of
detail in the information displayed. The normal scan function
displays five lines of information about each message. This scan
function displays only one line for each message, and so each
screen output presents information on many more messages.

Inter-Node Chat Query: (@) In a multi-line BBS environment, this
function will check for a caller on another line. Two types of
inter-node chatting are provided presently. The two methods do
not interact with one another. The first method may be thought
of as a "party line" type of thing. All callers on a single
system can chat with one another when this mode is selected, but
not with callers on other systems in a networked environment.
When selected, if another caller is online, that caller's name
will be displayed along with node number, and an offer will be
made to request a chat if the other caller is not in the process
of entering a message or doing a file transfer. At the next most
opportune time, the other caller will be notified that a chat has
been requested and given the option of entering chat mode,
rejecting the chat request momentarily, or locking out all
further chat requests for the duration of the call. Should the
caller later wish to try chat mode after having locked out
inter-node chat, they may reset the lock out by requesting chat
mode from their side. Once chat mode is engaged, it remains in
effect until someone enter the string, "//QUIT". The inter-node
chat feature functions more or less like a party line. That is,

- 105 -

FX-BBS Installation and User's Guide

all callers who are participating in an inter-node chat session
can talk to one another.

The second method of chatting has only recently been added. This
method uses named datagram processing for communicating across a
LAN to another system. Several different conferences are
provided, including the main FX-BBS conference area and one for
each of the conferences you support. When the "party line" chat
method is selected, all callers "on the party line" can talk with
one another, with all inputs displayed more or less instantly.
For LAN chat mode, the screen is cleared and two input lines are
maintained on screen, one for the caller and one for the SYSOP.
Inputs being made by either person are displayed locally on these
two lines until a return is entered by the person in question.
At that time, their particular input will be broadcast on the
network. Note that the caller controls which conference is
selected, not the SYSOP. Inputs made by the SYSOP will be
broadcast in the conference area the caller has selected and no

There are presently a few restrictions on both forms of chatting.
For the internode "party line" chat functions, you must have
multitasking optimization enabled (refer to screen L of the
FXBSETUP program), and should have DesqView clock ticks set to 1
foreground and 1 background for optimal performance. For the
DoubleDOS program, foreground to background priority should be
set to half.

For LAN chatting, the FXCOMML TSR provided for LAN support must
be used and the FXCNFCFG program must be run prior to running
FX-BBS. These programs were necessitated by the fact that
problems are caused due to the LAN cards not being capable of
multitasking. That is, LAN cards are not prepared for the
possibility of their data buffers being momentarily swapped from
memory by DesqView. The buffers must be (and are) located within
the TSR, which must NOT be loaded within a DesqView window (load
it prior to running DesqView or DoubleDOS). FX-BBS uses NetBIOS
"Datagram" processing to support this function, so chatting is
only possible if you actually have a NetBIOS compatible LAN card
installed in your system, and will also occur only if enabled
(refer to the setup program's Screen M). To minimize the number
of buffers required, FX-BBS further does a datagram receive for
*any and all* datagram traffic on the LAN. This might cause
problems for a LAN used in a business environment. In this case,
LAN chatting should be disabled. Callers cannot as yet determine
who is on the remote systems via LAN query. This problem will be
corrected as soon as possible.

- 106 -

FX-BBS Installation and User's Guide

List new files: (L) When selected, a date is requested at which
to start, or the date the caller last logged on will be used as a
default. Files added to the BBS since that date will be searched
for and listed for the caller, along with the date of the file
and its size. If the file is hidden (the DOS hidden file
attribute is set) and the caller is SYSOP, it will be noted as
hidden. Hidden files are not presented if the caller is not the
SYSOP. Following this, the caller is asked whether or not a
search for detailed file descriptions is to be performed. If the
caller answers yes, the directory files will be searched for file
descriptions. Due to memory limitations, only the first 400
files found will be searched for.

- 107 -

FX-BBS Installation and User's Guide

SYSOP Main Menu Functions:

The following functions are available only when the caller is
SYSOP (an access level of 10) or ASSISTANT SYSOP (access level
9). Note that most of the functions are limited when invoked by
an assistant SYSOP.

Enter SYSOP Maintenance Mode: Selected by entering "7" at the
BBS main menu. A brief menu is built into the program and will
be output for the caller. FX-BBS provides the option however, to
display a SYSOP created menu if found. This menu must be
contained in the text and/or graphics file work paths, and named
"SYSOP7.TXT". The SYSOP maintenance menus provides the SYSOP
with the following sub-functions:

Read Comments: Allows SYSOP to read comment file, and optionally
delete same after reading it (all comments, are simply added
together in this one file. It should be checked often).
Assistant SYSOPs cannot delete comments. Note that comments
contained in this file are stored with the most recent comments
listed first and older comments following. The file is also
"self-regulating" in size. That is, when the file becomes too
large, FX-BBS will delete the oldest 1/3 or so of the file. It
does not therefore, need to be deleted by the SYSOP.

Read Answers to Questionnaires: When selected, asks which set of
answers to questionnaires you would like to view. Note that
these are standard text files and may be viewed off line using a
text editor.

Change User Access Level: Requests name of user and if found,
asks for new access level. Access level 0 may be used to "delete
a user". The slot for that user will be reused for new callers.
The particular slot of a caller in the user id file cannot be
easily changed, since it is closely tied to the mail processing.
That is, the index of the user in the id file is used to
determine who the sender and receiver are. This saves space in
the message files. Assistant SYSOPs may only change access
levels to 1 or 2. They can neither delete a caller, nor provide
them with extensive access. When a caller's access level is set
to 0 (caller is deleted), messages addressed to or entered by
that caller are deleted. Note that this message deletion check
occurs only here and is not part of the EDITUSER program.

Terminate Program: Allows program to be terminated remotely. The
caller (you?) will be disconnected when this occurs.

- 108 -

FX-BBS Installation and User's Guide

Execute Dos Command From Remote: Allows Dos commands to be
executed from remote. FX-BBS will execute the command you
provide blindly. It provides no real positive indication that it
has or has not performed the requested function. The CTTY
function also should not be used, especially under DesqView,
since DesqView does not usually process this as you wish.
Rather, the command string "COMMAND.COM >COMx: executed instead, where "x" is the COM port in question.
Interactive programs generally should not be executed here,
unless they are DESIGNED to operate through the COM ports.
Generally, they should intercept the communications interrupt,
AND restore it upon completion. Not applicable for assistant

Add File: Allows SYSOP to add a file to the recently uploaded
files directory without actually having to upload it (for files
copied in from floppy). The upload description logic does not
indicate that the uploader was the SYSOP in this case. The file
to be added must first be placed into the uploads directory. If
the file cannot be found there by FX-BBS, it will not be added.
The [A]dd a file function provides as well, the option to perform
the [I]nstall a file function, to move the file description into
its permanent directory at the time it is added. When this is
done, the file description is never actually placed into the
UPLOADS.DSC file (the [I]install option is described a few
paragraphs down).

Delete File: Allows SYSOP to delete a file from the recently
uploaded files directory, and optionally, from the disk as well
(provided file is in uploads directory). Not applicable to
assistant SYSOPs.

Show File and Hide File: Allows SYSOP to change the private file
flag for a file in the recently uploaded files directory. Also
changes hidden file attribute on disk to hidden or not hidden as

Install File: This function allows the SYSOP to remove a file
description from the upload description area and add it to a
standard DIR text file. At the same time, the actual data file
will be moved from the upload directory and placed into its
permanent "home" directory. The name and drive of the directory
the file itself is to be moved to is requested first, following
display of the file DIRMAP.BBS, if the file is found. This file
is not displayed to other callers, and can contain whatever you
wish. Its purpose is to aid you in determining where to place
new uploads, so should indicate what directories are located on
what drives and such.

- 109 -

FX-BBS Installation and User's Guide

If the subdirectory name entered matches a valid text directory
file name, FX-BBS will automatically add the file description to
that directory text file. For example, if you indicate that a
file is to be installed in the directory "H:\FILES\DIR22", the
description for that file will automatically be added to the
directory text file "DIR22". If the directory specified does NOT
match a directory text file name, FX-BBS will request the name of
the directory text file the description is to be stored in. Note
that in order for the file to be properly moved, you must have
the FX-BBS support program MOVE.EXE in the FX-BBS path. The MOVE
program is invoked to move the file to the drive and directory
required. When a file is installed into a directory text file,
it is added to the BEGINNING of that text file. Files listed in
such a directory text file then will have a natural order of most
recent first and oldest last.

Add Caller to a Conference: Allows the SYSOP to add callers to
private conferences. Callers may also be forcibly removed from a
conference as well.

Quit to Main Menu: Terminates SYSOP maintenance mode.

Main Menu SYSOP Commands Continued (we've been discussing SYSOP
maintenance menu commands above, remember?):

Toggle Printer: (8) Allows printer output to be turned on/off
from remote.

Toggle SYSOP In: (9) Allows SYSOP in to be toggled from remote.

- 110 -

FX-BBS Installation and User's Guide

Terminal Mode:

FX-BBS provides a built in terminal program capability, much like
any communication program (ie: Procomm, Telix, etc), but with
differences none-the-less.

To begin with, terminal capabilities provided are somewhat
simpler than those of other communications programs. FX-BBS is
first and foremost, a BBS program, not a terminal program. No
emulation of a particular terminal type is provided, nor the
redefinition of received character values for example.

Terminal mode may be selected at any time by entering ALT-T from
BBS mode. Processing encountered at this point differs depending
on whether or not a caller is online. If no caller is online,
the modem will be reset, the phone placed "on-hook," and the
terminal mode initialization command (see below) will be sent.
If a caller is online, none of this will occur. Terminal mode is
exited by entering either ALT-B to return to the BBS, or ALT-X to
shut down the FX-BBS program. When the BBS is returned to, the
system will be reset if no one is online. When a caller is
online, the reset does not occur. Use care in flipping in and
out of terminal mode when a caller is online... It's a bit
hazardous. While processing to be performed is much as described
here, it still may be the case that a caller might be
disconnected should you attempt to enter terminal mode and then
return to the BBS afterwards. There may also be problems should
you call another system and then attempt to enter BBS mode while
connected to it. Terminal mode really wasn't meant to be used in
this way...

Options available from the terminal mode menu are as follows:

F1: Display the terminal mode Help Menu. This is a pop up
window sort of thing. It provides a brief list of the options
described here.

ALT-A: Set Baud Rate. Allows you to set baud rate, parity, and
number of data and stop bits as required.

ALT-B: Return to BBS. Self explanatory.

ALT-C: Clear Screen. Self explanatory.

- 111 -

FX-BBS Installation and User's Guide

ALT-D: Display Dialing Directory. The dialing directory is a
relatively simple window arrangement, but is the heart of
terminal mode operations in many ways. Regardless of the number
of copies of FX-BBS in use, only one dialing directory file is
maintained. Since the file can be modified, it is opened in a
locked manner, meaning that multiple copies of the program
wishing to access the file cannot. This file is stored in the
main bbs working path as described in the main configuration
file, and is called FX-BBS.PHN. In addition to containing the
dialing directory, the FX-BBS.PHN file contains initialization
information for use in terminal mode. Several selections are
available beneath it.

E: Edit entry. When E is selected, you will be asked for the
number of the entry to be edited. Following this, information
about the entry will be displayed and you will be asked for
confirmation regarding the edit. For each entry, the name of
the system may be entered, along with the telephone number of
that system, the baud rate to be used for the call, number of
stop bits, word length and parity. While the name of the BBS
for the entry may be of a fairly decent size, not all
information entered for the system name will necessarily be
displayed on the main dialing directory display. This
"contraction" is necessary in order to fit 30 entries on a
single screen.

D: Dial an entry. You will be asked for the entry number you
wish to dial.

M: Allows "manual" entry of a telephone number to be dialed
(one which is not in your dialing directory).

Escape: Exit the dialing directory window.

PgDn: Page down through the list of entries in the dialing
directory. The dialing directory is of unlimited size. If
you are at the end of the dialing directory and depress the
PgDn key, you will be asked if you wish to expand the dialing
directory. Reply Y or N as required. If you wish to
arbitrarily PgDn 30 times, FX-BBS will quite obligingly create
900 entries for you...

PgUp: Page up through the list of entries in the dialing

- 112 -

FX-BBS Installation and User's Guide

ALT-E: Toggle Echo. By default, characters typed locally are not
displayed by FX-BBS. Instead, it waits for the characters to be
received or echoed back from the modem. ALT-E toggles a flag
causing the characters to be echoed locally as they are typed
without waiting for their echo.

ALT-F: Open a Log File. This is the same logic as provided in
the FX-BBS program for use when a caller is online. A window is
opened and a file name is requested. Should the file be found to
already exist, the option to overwrite it is provided. The log
file will be automatically closed upon loss of carrier (if no
carrier is present, a log file cannot be opened), or when you
depress ALT-F a second time.

ALT-H: Hangup Phone. Drops carrier and resets the modem.

ALT-P: Enter Setup Parameters. Again, terminal mode setup
parameters are stored at the beginning of the FX-BBS dialing
directory file. If the dialing directory file does not exist,

this option is automatically selected when terminal mode is
entered for the first time. The setup parameters available in
FX-BBS terminal mode are as follows:

Terminal Mode Modem Initialization String: This string will
differ from that of the main BBS program in all likelihood.
For one thing, you will want to include "S0=0" to prevent the
phone from being answered. The terminal mode initialization
string should also contain the parameters "&D2 &C1", since in
terminal mode, FX-BBS determines whether or not a connect has
occurred by watching the carrier and not by examining modem
strings or status returned. Terminal mode also will not
change the baud rate in use if a mismatch occurs on a
particular call. The baud rate used is that in the dialing
directory, or what you select manually.

Dialing Prefix: Typically, this is "ATDT". You may wish to
change it to "ATDP" if Touch-tone capabilities are not
available, or optionally include a Sprint or MCI Dialing
access code as required. Call Waiting might also be disabled

Dialing Suffix: Typically empty, but may be required by some
modems. Another opportunity to enter Sprint or MCI access
codes as required.

Delay During Redial: This is the number of seconds to wait
between redial attempts.

- 113 -

FX-BBS Installation and User's Guide

ALT-R: Redial Last Number. Provided a number has been dialed,
this command will cause the number to be dialed repeatedly until
either a key is depressed, or connection is established. A delay
between attempts will occur as specified in the terminal mode
Modem Setup Parameters option.

ALT-S: Toggles Sound On/Off. Terminal mode by default will emit
bells and whistles. ALT-S can be used to turn sound effects on
and off.

ALT-F1: FX-Shell. Performs in the same manner as from the main
FX-BBS menu.

ALT-F2: Invoke User Program. Performs in the same manner as from
the main FX-BBS menu.

ALT-X/ALT-F10: Exit Program. Resets the modem, hangs up the
phone and drops interrupt processing, as occurs in the main FX-
BBS program. ALT-X may be used as well for this function. (It
seems that this is a bug... ALT-F10 should now process function
key assignments. Due to an oversight on my part, in terminal
mode, it will exit the program. This will be corrected as soon
as possible, such that only ALT-X will exit the program.)

PgDn: Download a File:
PgUp: Upload a File: Causes a window to be opened and requests
the type of download you wish to perform. Logic used by this
function is pretty much identical to that used by the main FX-BBS
program. Differences include that you aren't asked by FX-BBS to
enter any file descriptions for newly received files, for
example, and that batch downloads are not supported. All
download and upload options provided your other callers will be
provided to you here. Following selection of a protocol to be
used, a file name is requested. You may enter here any filename,
but must enter the complete path and file name to be used. In
terminal mode, FX-BBS does not search for a file in any
particular directory other than the one you specify here.

- 114 -

FX-BBS Installation and User's Guide

Notes on Constructing Questionnaires:

Questionnaire files are simple ASCII text files, named
"QUESTx.BBS", where "x" is the letter "A" through "F" ("A"
through "F" is the recommended range, but at the present time,
FX-BBS supports questionnaires with any ending letter), and
located in the primary BBS operating path (no ANSI graphics
processing is done). The master list of questionnaires available
to callers is called QUESTION.BBS. Each question contained in
the file has the reserved character "~" placed immediately after
it. Questions may be of any length, and may have paragraphs if
necessary. All information is output until a "~" is encountered.
At that point, an answer is solicited. The "~" may appear in
column 50, 63, 1 or wherever required. Wherever the tilde
appears, FX-BBS will stop outputting and solicit an answer at
that position on screen. Answers may be at most, one line in
length. If the cursor is positioned to column 1, a relatively
long answer can be entered. If positioned to column 50, the
input will of necessity be shorter.

Answers to questionnaires are stored in files named
"ANSWERSx.BBS" in the usual reverse order. The caller's name and
time of the answer is indicated. The questions themselves
however, are not stored in the file in order to save space,
though answers are labeled by question number.


- 115 -

FX-BBS Installation and User's Guide

Notes on Message Processing, EchoMail and NetMail:

Note that you are not required to support echo or netmail!
Supporting echo and netmail is often a quite complex task and
requires an extensive effort to properly configure. Many BBSs
offer local mail only. If this is your plan, ignore the echo and
netmail concerns described here.

FX-BBS supports up to 80 message sections. These sections may be
individually designated as "Local", "EchoMail", or "NetMail".
Local message sections are kept only on the local BBS. They are
not exported to other systems in any way. EchoMail and NetMail
sections are examined frequently for new messages requiring
export to other systems. There is no limit on the number of
EchoMail message sections you may have, save the overall limit of
80 message sections. The same holds true for local message
sections. There should however, be only one NetMail section.
This message section should also be made a Private Message
section, by use of the conferencing capabilities or by entering a
lower case control flag on Screen F. You will want to restrict
access to the NetMail message section, since it might be costly
to do otherwise.

FX-BBS is intended to provide FidoNet mail compatibility at the
FTSC001 level. FidoNet has a "living" standard. That is, it
will change over the years into whatever is required. FX-BBS is
also a "living" program, and continues to evolve in different
directions. It is anticipated that at times, the directions
might diverge a bit, but an effort will be made to maintain

While FX-BBS has the ability to import and export echo and net
mail (every effort has been made to assure it is FTSC001
compatible), it differs a bit from other such systems. Opus for
example (at this writing), creates different message files for
each message, and places them into different directories.
Control information imbedded into the Opus messages is different
from that used by FX-BBS, though there are similar fields here
and there. FX-BBS places all messages for a given message
section into the same file, with new messages added at the end of
the file as required. Each message is preceded by a header area,
and this pattern repeats throughout the file: First a header,
then a message body, followed by another header, and another
message body. Since messages are stored together in individual
files for each message section, the size of the clusters
specified when your hard disk was formatted is relatively
unimportant. (Often, SYSOPs using other BBS programs will format
their hard disk using smaller sector sizes so that the individual
messages will occupy less disk space. Because there are fewer
files involved with FX-BBS, this is not a concern. On my message
disk for example, I use sector sizes of 4096 bytes.)

- 116 -

FX-BBS Installation and User's Guide

FX-BBS has a completely self-contained message environment. The
editor is built-in and cannot be overridden by an external
editor. This is required to assure adequate multiuser
considerations are provided.

For multiuser or LAN environments, when a caller is entering,
reading or scanning a message section file, FX-BBS locks that
message file for the duration (using the DOS SHARE.EXE program).
No other caller can read or enter a message in that particular
section until the first caller is finished. This occurs as well
when the FXMAIL and FXREPACK programs are running. It wouldn't
do to have a file seriously rearranged while a caller was reading
its contents.

Following the entry of a message, FX-BBS will add to it the
origin line and SEEN-BY: lines for echo and netmail sections.

When messages are deleted from a message section, they are not
really removed at that time. Rather, a flag is simply set
telling FX-BBS that the message is deleted, and it no longer
presents the message to any callers. The message will be removed
at a later time by the FXREPACK program (see next section).

The FXMAIL and FXREPACK programs are used to process inbound and
outbound mail, as well as to keep the message section file sizes
under control. These two programs are also multitasking aware,
and will respond accordingly to multitasking optimization flags
in the configuration files specified for use. That is, they make
every effort to be as cooperative as possible with copies of FX-
BBS which may be running and servicing callers. In this case,
both FXREPACK and FXMAIL will take a back-seat and give the
callers the majority of cpu time available. Both FXREPACK and
FXMAIL are also aware of file locking as required. When a
particular message file cannot be opened, the programs will wait
patiently for access. Alternatively, once FXMAIL or FXREPACK has
gained access to a particular file, it will keep the file in
question locked (and unavailable to callers) until it has
finished with it.

- 117 -

FX-BBS Installation and User's Guide

The FXREPACK Program:

The FXREPACK.EXE program must be run separately to delete
messages flagged as having been deleted. This program can be run
manually, or automatically at a given time. Refer to the
FXBSETUP program for a discussion of the automatic running of
FXREPACK. The syntax for the program is:

FXREPACK config_file -option [-Pxxxx]

The program requires two arguments, and optionally, three. The
first parameter is the full path and name of the FX-BBS
configuration file. Following this a flag must be specified
indicating the type of run. The "-D" flag indicates that the
program is to remove only messages which have actually been
deleted. Messages FLAGGED for deletion will remain. The "-I"
flag indicates that the program is to run interactively with the
SYSOP. That is, the program will stop and ASK the SYSOP whether
or not to really delete each message flagged for deletion or not.
The "-A" flag indicates that the program is to automatically
delete any messages flagged for deletion without asking the
SYSOP. Either the "-I" or the "-A" option MUST be specified.

An additional parameter may also be specified, "-Pxxxxx". When
this flag is specified, the total number of messages available in
each section will be truncated to xxxxx messages. If for
example, you specify "-P50" only 50 messages will be retained in
each message file. Older messages and those flagged for deletion
will be deleted first. Note that this parameter is used in
conjunction with purge levels specified on Screen F of the
configuration program. The smaller of the numbers entered will
be applied to each message section. For example, if you specify
-P100 when running FXREPACK, no message section will be allowed
to contain more than 100 messages, regardless of the parameters
specified on Screen F. Alternatively, if all message section
purge levels on Screen F are set to 50, a parameter of -P100 will
have no effect. The lower figure will be used for each message

When the purge option is selected, FXREPACK will not process
messages in sections which have fewer messages than the purge
level specified, nor will FXREPACK purge messages which are not
older than one full day (all echomail messages then will be kept
a minimum of 24 hours). FXREPACK finally verifies the integrity
of each file as it is processed, and when a file is found to be
in error, attempts to correct the problem found by deleting
messages it cannot understand.

- 118 -

FX-BBS Installation and User's Guide

The FXMAIL Program:

The FXMAIL program is used to translate messages between the
formats required for its own internal use and that required for
EchoMail and NetMail processing. FXMAIL is also used to generate
polling packets for other nodes, to place holds on mail destined
for a particular system, and to "unhold" such messages as

The filename portion of compressed echomail files is a bit
"different." While the name will appear a bit bizarre, it none
the less has a pattern. It is calculated by converting the
sender's net/node numbers into four character hexadecimal strings
and then "subtracting" the equivalently converted receiver's
net/node number from it. All values are unsigned, and the result
represents the first eight characters of the filename for both
inbound and outbound files.

While compressed mail files are named in that manner, the flow
files and other outbound files follow a different format. The
names of these files are constructed by converting the
destination net/node number to hexadecimal and using these to
build a file name. The net number is stored in the first four
positions, and the node number is stored in the last four. While
there's nothing at all wrong with these names, and several
advantages are offered by them, I do wish to point out that I am
not the one who invented this standard.

Another file type is the simple message packet. These are the
files which are stored in the incoming or outgoing compressed
echomail files. Such files end with the extension "PKT", and
usually have a file name based on the current date and time.

A file called "FXMAIL.DEF" may or may not be used in conjunction
with FXMAIL. When used, it should be stored in the same
directory as the FXMAIL program (FXMAIL searches for it there).
The format of the portion of the file considered here is as
follows (See the description of TIC file processing for a
complete description of the FXMAIL.DEF file):

Line 1: name of FX-BBS Config file to use.
Line 2: Inbound path name.
Line 3: Outbound path name.
Line 4: Mail Packing compression program name and parameters.
Line 5: ZIP Mail Unpacking program name and parameters.
Line 6: ARC Mail Unpacking program name and parameters.
Line 7: ZOO Mail Unpacking program name and parameters.
Line 8: LZH Mail Unpacking program name and parameters.
Line 9: "Other" Mail Unpacking program name and parameters.

- 119 -

FX-BBS Installation and User's Guide

Note that multiple mail decompression commands may be specified
in the FXMAIL.DEF file. FXMAIL examines the first several bytes
in received files to determine the type of compression used in
their generation and selects the appropriate decompression
program to be run accordingly. Any decompression option you
elect not to use should have the word "NONE" in the corresponding
line. While multiple decompression methods are supported, only
one default compression method is allowed presently.

When the FXMAIL.DEF file is found, the parameters contained in it
are not required on the FXMAIL command line, but instead are
obtained from the FXMAIL.DEF file. If one or more parameters are
provided on the FXMAIL command line, the specified parameters
will override those in the FXMAIL.DEF file. The following
descriptions assume that no FXMAIL.DEF file is in use.

- 120 -

FX-BBS Installation and User's Guide

Unpacking Mail:

To "unpack" incoming mail and "toss" it appropriately, FXMAIL is
invoked as follows (optional parameters are shown in braces):

FXMAIL -U [-D] -Cxxxxxxxx -Ixxxxxxxx -Axxxxxxxxyyzz

where "-U" indicates that messages are to be unpacked, "-D" is an
optional parameter indicating that message archive and *.PKT
files are to be deleted after they have been processed, "-
Cxxxxxxxx" is the fully qualified name and path of the FX-BBS
configuration file to be used, "-Ixxxxxxxx" is the fully
qualified path to the directory containing inbound EchoMail
message archive files, and "-Axxxxxxxxyyzz" is the fully
qualified path and name required to invoke an archive or
decompression program, along with all parameters it requires, to
decompress message archive files contained in the message inbound
directory (note: all arguments following the "-A" flag are
assumed to belong to the decompression program; for this reason,
the "-A" parameter must be the LAST one on the command line). As
far as FXMAIL is concerned, any compression technique for which
you have sufficient memory may be used, including ZIP files, ZOO,
LZH and so on. This should be worked out as required with your
echo feed.

Apologies for the terseness of the program's command line. An
example: On my own system, I use the following to unpack and
toss inbound messages (contained in a batch file):

rem Save a few packets for posterity, just in case of later
rem accidents. As new packets are received, old ones should be
rem deleted.

copy g:\netfiles\*.* \g:\oldnet\*.*

rem unpack and toss the mail


rem If FXMAIL.DEF is in use, the above line could simply be
rem "FXMAIL -U -D"

rem Now repack the message sections as required. Purge more than
rem 250 messages and delete any flagged as deleted.



- 121 -

FX-BBS Installation and User's Guide

Archived files sent and received by most FidoNet mail systems use
slightly simpler compression techniques than some of the newer
archive file processing programs might offer (apparently). For
this reason, it is generally recommended that Vern Buerg's ARCA
and ARCE programs be used, though these programs must be
registered with SEA (poor Vern; and generous Vern).

When the above batch file segment is run, by the time FXMAIL is
encountered, all EchoMail archive files will be contained in the
G:\NETFILES directory. FXMAIL will search for compressed files
in the G:\NETFILES directory and decompress any found. These
files all MUST have an extension of "MO*", "TU*", "WE*", "TH*",
"FR*", "SA*", or "SU*", where the first two letters are intended
to represent the day of the week, and the last character is a
numeric ranging from "0" to "9". The exact combination of
letters encountered will vary from one hub or host system to the
next. Apparently, it can only be determined by Mr. Spock. That
is to say, there is obviously some logic behind the choice of
letters used, but it does not seem to be documented anywhere
well, nor does it always seem to follow any particular pattern.
You might for example, get a "TU*" file on Saturday... It has
been documented at any rate, that the last character of the file
is randomly determined, for whatever that is worth.

Once all compressed files are unpacked, the newly received
compressed file will be deleted if the optional "-D" parameter
was specified. The directory is then searched for files with an
extension of "PKT". Each message in each such file is then
examined for the AREA: parameter. When such is found, FXMAIL
searches through the FX-BBS configuration file for an EchoMail
section with the same string contained in the first part of the
message section name (refer to screens D and E in the FXBSETUP
program). When a match is found, FX-BBS places the new message
into the appropriate message section file. If no match is found,
FXMAIL places the message in question into the FX-BBS designated
NetMail file for examination by the SYSOP. If a problem is found
with a particular message, or if the message received is found to
have originated at your system, the message will be deleted. As
each PACKET file is processed, it is deleted, regardless of the
optional -D FXMAIL parameter. The -D parameter refers only to
the compressed files received.

- 122 -

FX-BBS Installation and User's Guide

Packing Mail:

FXMAIL packs messages in a similar manner. The command line for
this appears as follows:

FXMAIL -P -Cxxxxxxxx -Oxxxxxxxx -Nxxxxxxxx -Axxxxxxxxyyzz

As you can see, the parameters are similar. The differences are
that 1) "-P" has been specified to indicate messages are to be
packed instead of unpacked, and the "-Ixxxxxxxx" parameter has
been replaced with "-Oxxxxxxxx", which is the "outbound"
directory FXMAIL is to place outbound archive files into.

An example, again one I use or at least have used, is as follows:


or if you're using the FXMAIL.DEF file,


As you can see, there is a different outbound directory and the
archive program to use is now ARCA, which adds files (PKT) to
archive files rather than extracts them as ARCE does. The
compression command is again, the last set of arguments to

When this line is executed, FXMAIL will examine echomail message
areas for new messages and when found, will build a packet file
for them. Packet file names generated by FXMAIL are named based
on the current month, day, hour and minute, as in "MODDHHMN.PKT",
when they were created. FXMAIL also examines the FX-BBS
designated NetMail message section file for new messages and if
any are found, builds individual packets for each destination.

Following this, packet files contained in the G:\OUTBOUND
directory are archived together with the filename based on the
sender and receiver net/node numbers as previously described.
FXMAIL generates filenames only with an extension of "MO*", with
the last character ranging from "0" to "9". The next number
FXMAIL is to use is contained in a one byte control file which
resides in the outbound directory. Message packets generated can
be designated as CRASH/CONTINUOUS mail or not as required, and
message archive files may be designated as to be kept after
sending, or deleted as required. Refer to FXBSETUP program
screen F for more information.

Message sections need not be repacked following bundling by
FXMAIL. FXMAIL should be run to pack mail each night before the
National Mail Hour begins, and at any other times in the day when
it is necessary to send messages to another system.

- 123 -

FX-BBS Installation and User's Guide

Polling Other Systems:

FXMAIL is also used to generate polling packets for other
systems. A polling packet is an outbound packet containing 0
bytes and named appropriately for the system to be polled. The
syntax for this function is:

FXMAIL -Cxxxxxxxx -Oxxxxxxxx -Poll net_number node_number

or when using FXMAIL.DEF,

FXMAIL -poll net_number node_number

As before, the -C parameter specifies a configuration file and
the -O parameter specifies the outbound file drive/directory.

To poll my echo feed for example, I would enter

FXMAIL -poll 208 200

This will cause FXMAIL to generate an appropriately named file
with an extension of "CLO" (a crash flow file), and place it into
the outbound area.

- 124 -

FX-BBS Installation and User's Guide

Changing Outbound Mail Status:

Outbound mail packets will generally have the following

.CLO - "Crash" mail outbound flo file. Send the file as soon
as possible.
.DLO - "Direct" outbound flo file. Send the file during
national mail hour.
.HLO - a "Hold" flo file. Files destined for this system are
not sent unless that system calls yours.
.CUT - a "Crash" outbound file. Send the file as soon as
.DUT - A "direct" outbound file. Send the file during
national mail hour.
.HUT - An outbound file placed on "Hold." This file will not
be sent unless the system for which it is destined
calls your own.

FXMAIL allows you to change the status of outbound files on a
system by system basis. To change all messages with the above
extension's to CRASH mail, enter

FXMAIL -Cxxxxxxxx -Oxxxxxxxx -Crash net_number node_number

or if using FXMAIL.DEF,

FXMAIL -Crash net_number node_number

To change mail for my echo feed to crash, I would enter


Changing outbound mail for a particular system to other statuses
is accomplished in a similar manner. To hold all mail for system
111/222, I would enter

FXMAIL -HOLD 111 222

To change all mail destined for system 123/456 to direct, I would


- 125 -

FX-BBS Installation and User's Guide

File Requests and File Attaches:

FXMAIL is once again the program being considered here for these
functions. "File Request" refers to the ability to build special
messages which when transmitted to another echomail system will
cause files on that system to be transmitted to you, usually "on
your dime." "File attaches" are similar, but in this instance,
you wish to transmit a file otherwise unrequested, from your
system to another. Many programs are available to accomplish
these tasks which may be used instead of FXMAIL, but these
functions are included in FXMAIL for the sake of completeness and

Performing these functions on a strictly command line driven
basis would be tedious indeed. As a result, FXMAIL processes
these requests in a prompted manner.

To perform file requests, you would enter

FXMAIL -REQUEST -Cxxxxxxxx -Oxxxxxxxx

or when using the FXMAIL.DEF file,


For file attaches, you would enter

FXMAIL -ATTACH -Cxxxxxxxx -Oxxxxxxxx

or when using the FXMAIL.DEF file,


When FXMAIL begins running, you will be asked for all information
required, including file names and paths, destination net and
node numbers and so on. Multiple files may be sent or requested
as required, and multiple net/node numbers may be processed. The
program will continue to solicit inputs until you indicate you
have finished, and allows for limited error correction as
required. Again, these are not the definitive attach and request
programs, but work reasonably well.

- 126 -

FX-BBS Installation and User's Guide

TIC File Processing:

FXMAIL now processes 'tic' files which have been received. Tic
files are files produced by Barry Geller's TICK program, which
describe other files which may have been sent to your system.
Most often, this is done for files belonging to a sort of
conference. For example, I recently became a member of something
called "DVNet", a collection of systems which exchange files
supporting DesqView. New DesqView related files are received
from time to time, and are accompanied by a tic file which
describes the files received, including where the file came from,
where it originated, the "area" the file belongs to, and an
actual file description in text form. This is different then
from a normal file attach, which would not be accompanied by a
tic file.

For example, someone might send you a file called SAMPLE.ZIP,
accompanied by a tic file. When FXMAIL finds a tic file, it
attempts to read the information in the file. If successful, and
if you've entered the appropriate parameters in the FXMAIL.DEF
file, FXMAIL will take care of moving the file received to any
other area you may have specified (generally a caller accessible
download area), will then extract the file description from the
tic file and place it into the directories you've specified, and
lastly, can leave you a message indicating that this has been
done in the message area you've specified.

- 127 -

FX-BBS Installation and User's Guide

The format of the FXMAIL.DEF file previously described was only
partial and did not include the information required for tic file
processing. The complete format of the FXMAIL.DEF file is as

line 1: FX-BBS configuration file name.
line 2: Drive and directory where incoming mail can be found.
line 3: Drive and directory where outbound mail is to be placed.
line 4: Compression command for use in generating mail packets.
line 5: Decompression command for ZIP mail packets.
line 7: Decompression command for ARC mail packets.
line 8: Decompression command for ZOO mail packets.
line 9: Decompression command for LZH mail packets.
line 10: Decompression command for other mail packets.

(the following lines are optional, and repeat for the number of
areas you've specified for use with tic files, up to 80 sets):

line 11: The word, "AREA"
line 12: "NAME" followed by the name of the area in question as
reported in the tic file.
line 13: "PATH" followed by the fully qualified path name where
the file is to be placed after processing.
line 14: "DIR" followed by the directory file number where the
file description is to be placed.
line 15: "SEC" followed by the message section number where a
message indicating receipt of the file is to be placed.

An example FXMAIL.DEF file follows (comments are included below,
but should NOT be in the actual FXMAIL.DEF file):

d:\fx-bbs\fx-bbs.cfg ; fx-bbs configuration file
f:\binkley\netfiles ; dir where newly received files are
f:\binkley\outbound ; dir where outbound files are be placed
c:\util\pkzip ; primary compression command
c:\util\pkunzip ; ZIP decompression command
c:\util\arce ; ARC decompression command
c:\util\zoo e ; ZOO decompression command
c:\util\lharc e ; LZH decompression command
NONE ; "other" decompression command
AREA ; area label
NAME DVNet ; name of an area
PATH C:\FX-BBS\DVNet ; dir where received files are moved to
DIR 47 ; dir file number file desc is to be put in
SEC 38 ; message area where note is to be left

You should NOT have leading blanks on any line of the FXMAIL.DEF

- 128 -

FX-BBS Installation and User's Guide

FXMAIL does not delete the tic files after they have been
processed. It seems incorrect to deny you later access to these
files in the event of a problem, and so automatic deletion was
omitted. When FXMAIL has completed processing of a tic file
successfully, it renames the file to have an extension of "INS",
as in "installed." You may add a "DEL *.INS" command to your
mail batch file should you wish to do this, or can do it manually
later. Any tic files which remain after FXMAIL has been run
could not be processed for some reason or another.

Neither FX-BBS nor FXMAIL has the ability to generate a tic file.
Should you wish to do this, you should obtain a copy of Mr.
Geller's TICK program. The primary reason FXMAIL now processes
incoming tic files is to allow the file description, etc to be
formatted properly for use with FX-BBS. TICK presently cannot
handle multiline file descriptions, though it is supposed to be
able to at some point or another, I think. FXMAIL however, can
at the present time process multiline file descriptions.

Final notes: The message section you tell FXMAIL to leave its
tic file related messages in should NOT be an echomail or netmail
area! If you do not wish to have messages posted for you telling
you that a tic file has been processed, specify a message section
of 0 for the area in question in the FXMAIL.DEF file.

Note too, that FXMAIL does not perform CRC checks of the files
received, though Mr. Geller's TICK program generates CRCs, and
includes a separate program that verifies things are proper.

FXMAIL moves the file received from the incoming netmail
directory to its final destination using the MOVE program
supplied with FX-BBS. FXMAIL therefore must be able to find the
MOVE program and run it in order to process things correctly.
The move program then, must either be in the current directory,
or must be in one of the directories described in your PATH

FXMAIL is not presently able to recompress files received to be
in a common format. If you prefer ZIP files for example, and
receive an LZH file, you will have to convert the file and modify
the directory file manually.

It's likely the case that you do not need to be concerned with
tic file processing until such time as you become a member of a
group which sends file around in this manner.

- 129 -

FX-BBS Installation and User's Guide

Front End Programs:

A Front End program is an external program that answers the phone
as required, and invokes FX-BBS when necessary. One of the most
often encountered such programs is BinkleyTerm, currently at
version 2.30. BinkleyTerm offers many capabilities, not all of
which will be described here, since it comes with its own 200-300
pages of documentation... Others are available commercially,
including a program called FrontDoor (shareware) and SEADog from
System Enhancement Associates. I have not tested either of these
as yet.

BinkleyTerm provides a terminal interface, the ability to call
other systems, and to answer the phone. When it answers the
phone, it first listens for the other system to indicate whether
or not it is trying to send mail or not. If so, it begins to
receive the incoming file and store it into the designated
inbound directory. BinkleyTerm provides many other features as
well. Callers can request via a sort of mail packet, a list of
files they can download or request from your system, which it
will bundle up and ship out attached as another sort of message.
Certainly all these parameters are configurable.

FX-BBS presently requires such a front end program to interface
with the rest of the world for mail purposes. Owing to the fact
that I only get to work on FX-BBS on weekends, holidays and
sometimes, week nights, as well as to the fact that I've now
reached middle age and still have several things to do to FX-BBS,
it seems unlikely that I'll eliminate the front end requirements
in this lifetime.

When using FX-BBS with a front end program, you *must* let FX-BBS
know of this by setting the appropriate parameter on screen L of
the FXBSETUP program.

An example batch file for use with BinkleyTerm, FXMAIL, FXREPACK
and FX-BBS is distributed with FX-BBS for your examination.
There is an awful lot to echo mail and net mail, and I can't
begin to cover everything here.

- 130 -

FX-BBS Installation and User's Guide

In addition to a front end program such as BinkleyTerm, you'll
require the following other programs/files:

PARSELST.ARC - Contains required software to process the
nodelist. It has its own configuration file for you to
play with. (FX-BBS as yet does not care what format the
nodelist is in. You should configure it as required for use
by Binkleyterm).

EDITNL.ARC - Program to accomplish weekly update of nodelist.

X00.SYS or
OPUS_COM.EXE - These are Fossil drivers used by BinkleyTerm
(and maybe the others) for handling the serial ports. FX-BBS
itself does not require a Fossil driver. This is only
required when you are running a FidoNet system. The OPUS_COM
program may be used instead if you wish.

NODELIST.Axx - So far anyway, the extension's I've seen start
with the letter "A". The person you obtain the nodelist from
can clarify this for you. This is a Nationwide (or
international) list of FidoNet compatible systems, and is
processed by PARSELST. Updates come out weekly, more or less.

No doubt, there are other files/programs you might want to
obtain. I cannot list them all here, and in fact will not so
that echomail related discussions are kept as simple as possible.
As previously mentioned, setting this stuff up is often somewhat
complex and intimidating, and I don't want to overwhelm anyone.

FX-BBS mail processing does not require programs such as MsgEd or
ConfMail. FX-BBS is not compatible with these programs in and of
itself. Should you wish to use these programs (or others whose
purpose is to manipulate mail in some way), some reconfiguration
of your system will be required to allow this. More than likely,
you will be required to maintain your messages in two separate
formats. This can be done by telling FXMAIL not to delete mail
packets after they've been decompressed (but bring more disk
space). You may wish to experiment with these programs at some
point or another, but should probably wait until you've got the
rest of the program(s) set up and functional.

- 131 -

FX-BBS Installation and User's Guide

FX-BBS File Formats:

As previously mentioned, FX-BBS message sections are composed of
first a message header, then a message, and the pair repeats
until the end of the file. This is not strictly correct. The
first eight bytes are used for some control information, with the
first four bytes a long integer indicating the highest message
number contained in the file, and the next four bytes
representing another long integer which indicates the number of
messages in the file. Following this, the first message header
is stored, and then the body of the message itself. It is my
intention to separate the headers from the text portion of the
messages at some point in the future (making two files). I think
message processing could be made a bit faster if this were done.

The total size of the message header appearing before each
message is 256 bytes, with a structure as follows (this is a C
language record definition):

- 132 -

FX-BBS Installation and User's Guide

typedef struct {
long number; /* individual message number */
unsigned int sender; /* index to user file (no */
/* longer used) */
unsigned int recver; /* index to user file (no */
/* longer used) */
char date_posted[28]; /* string - date entered */
/* null terminated */
char private; /* boolean true/false */
long repto; /* message number this is a */
/* reply to */
long reply; /* message number replying */
/* this message */
char recved; /* boolean msg received flag */
long spare1; /* not used */
long spare2; /* not used */
char kill_flag; /* user delete request flag */
char dead_flag; /* message really gone flag */
char subject[72]; /* null terminated string */
char sender_name[36]; /* null terminated string */
char recver_name[36]; /* null terminated string */
unsigned int dest_net; /* destination net (netmail) */
unsigned int dest_node; /* destination node (netmail)*/
long next_index; /* index to next message */
/* contained in file */
long spare3; /* not used */
unsigned int msg_size; /* number of bytes in text */
/* portion of message */
/* following header */
union { /* netmail compatible flags: */
/* there is some overlap with*/
/* other flags usage */
unsigned int private :1, crash :1,
received :1, sent :1,
file_attached :1, in_transit :1,
orphan :1, killsent :1,
local :1, hold_for_pickup:1,
spare :1, file_requested :1,
receipt_requested :1,
is_receipt :1, audit_requested:1,
unsigned int flags;
} f;
unsigned int orig_net; /* your net node number */
unsigned int orig_node; /* your node number */
unsigned int cost; /* not yet fully functional */
/* will indicate cost to send*/
/* a netmail message later */
char date_sent[20]; /* fidonet date from incoming*/
/* packets. null terminated */
char spare4[14]; /* 256 bytes */

- 133 -

FX-BBS Installation and User's Guide

User ID Record Format:

Record Size: 128 Bytes.

The user ID file is *not* sortable! Be certain *not* to try
rearranging the order of caller names in the ID file! Should you
do so, it will irreparably corrupt your message section.

Record structure is as follows::

typedef struct {
char name[29]; /* user's name - null terminated */
char expert; /* expert flag - true/false */
char laston[26]; /* date last on - null terminated*/
char spr1; /* spare byte */
int daily_kb; /* KB downloaded in one day */
char nbr_calls; /* number of calls today */
int lstm; /* index to last message */
char pass[14]; /* password - null terminated */
char acc; /* access level */
char lock; /* prevents user from being del'd*/
int sub_mo; /* expiration mo of subscription */
int sub_day; /* expiration day of subscription*/
int sub_yr; /* expiration yr of subscription */
long bonus_time; /* bonus time earned... */
char screen_len; /* number of lines on screen */
char backspace; /* backspace char code always 8 */
char linefeed; /* linefeeds req'd flag - T/F */
char uppercase; /* uppercase only flag - T/F */
char spr2; /* not used - reserved */
long total_secs; /* time field in seconds - daily */
int uploads; /* files uploaded */
int downloads; /* files downloaded */
char sound; /* prompt bell indicator - T/F */
char city[20]; /* callers' location */
char conferences[6]; /* T/F for each of six confs */

- 134 -

FX-BBS Installation and User's Guide

Multitasking Considerations:

As a rule, I run my BBS under a multitasking package, either
Desqview or DoubleDOS. This allows me to copy files to and from
the BBS system whether or not a caller is logged on, and this is
the primary reason I first used such software. I now run a two
line BBS, with three sometimes used, and so require the services
of DesqView or DoubleDOS, with each offering different
advantages. More than two phone lines requires the use of the
DesqView program, since DoubleDOS cannot run more than two
programs at a time. Other multitasking programs may work
acceptably, or may not. Others have not yet been tested.

Your configuration of DesqView will likely vary depending on your
system type and resources available. I now use a 386SX system
with two megabytes of memory. Previously, I used a 12 mHz 286
system with one megabyte of memory. Configurations for the two
systems are similar on the one hand, but also very different. I
first wrote this documentation with the 12 mHz 286 in mind, and
will discuss matters from that point of view to begin with.

For DesqView on a 12 mhz 286 system, my CONFIG.SYS file included
the following:

FILES = 20

My AUTOEXEC.BAT file was as follows:

rem SHARE.EXE is a program included with DOS 3.X and 4.X

The SHARE program is used to assure there are no file contention
problems, either between multiple copies of the BBS, the Local
Area Network, when used, or my own mucking about among the
various files on different systems. SHARE should be used with
ALL multitasking and LAN configurations. No path statement is
used since the system is a BBS system only (I do not run other
programs on it).

- 135 -

FX-BBS Installation and User's Guide

The DoubleDOS program should be configured for providing equal
time to both partitions. My own configuration file indicates
that the print driver is using the clock interrupt, and that
memory is divided into equal halves. Beyond that, there's not a
great deal to say regarding the program that you can't figure out
yourself. One good DoubleDOS feature is that it supports two
monitors fairly easily. "Autostart" parameters can be specified
in the DDCONFIG.SYS file such that when AUTOEXEC.BAT includes a
start-up of DoubleDOS, the BBS program(s) will start up without
keyboard input (the same can be done for DesqView using the
reserved script name of "!").

For Desqview and with a system dedicated to running FX-BBS, I run
with foreground and background clock ticks set to 1 and 1. You
should generally keep the number of ticks assigned to foreground
and background equal. The number of ticks should not be very
high either, so that DesqView won't develop a bad case of
jerkiness from the caller's point of view. If for example, you
were to give all background tasks 1 tick, and foreground 3, and
then start a large recalculation of a spreadsheet in foreground,
things from the caller's perspective might get very slow indeed.
Memory is adequate on my system, at the moment. Even so, I try
to be somewhat frugal in using it. I use a monochrome monitor,
so don't have to worry about giving up memory to graphics
programs. I allow only 13Kbytes of memory for DesqView's system
stuff, 1K for system stuff in each window, and 0 bytes of script
file area.

DesqView offers many different flags for configuring each
program. I assign each partition 200Kbytes or so (varies with
the size of FX-BBS during development and the number of lines I'm
trying to run). This is sufficient for the main program in each
window as well as about 70-90Kbytes left over for small door and
external protocol programs.

For the 386SX, I've memory to burn (sort of) and have configured
the system somewhat differently. The CONFIG.SYS file used on
this system is as follows:

DEVICE = VDISK.SYS 245 512 64 /E
FILES = 30
and sometimes,
DEVICE = X00.SYS B,1,38400

- 136 -

FX-BBS Installation and User's Guide

The AUTOEXEC.BAT file in use is as follows:


rem load LAN stuff

rem copy program to ram disk

programs and commands are all part of the Quarterdeck QEMM
package. "LOADHI" and "LOADHI.SYS" are tools allowing one to
load device drivers and programs into memory above screen memory
when properly configured. The SMARTDRV.SYS device driver is a
disk caching program which comes with Microsoft Windows. It is
not the fastest disk caching program, and probably is not really
required, but I use it anyway. Disk caching in conjunction with
the QEMM "BUFFERS" program allow me to specify BUFFERS=3 in the

Now pay attention... This is somewhat important if you're using
DesqView. Very often folks have difficulty trying to make
background communications tasks continue to run. This is because
DesqView has several parameters which, while not always clearly
documented as such, effect whether or not a foreground task can
stop a background task. The "Uses its Own Colors" field is one,
and "Share EGA" is another. "Virtual Text/Graphics" is another
which can effect this ability.

On my 286 monochrome system, the flags, "Displays graphics
information," "Writes Directly to screen," "Can be swapped out of
memory," "Close on exit to DOS", "Uses its Own Colors" and "Runs
only in foreground" are all set to "N". The "Allow Close Window"
parameter is set to "Y". Keyboard conflict is set to "0", and
the parameters asking about math coprocessors and floppy disks
are set to "N". The default range of interrupts used is fine
when running up to four copies of FX-BBS, though when running
more than this, I've found it necessary to limit the interrupt
range to from 1 to 52. A full screen window is also for each
copy of FX-BBS running. A script buffer size of 0 is specified
for each program, and 1Kbytes system memory area is specified for
each as well. For newer versions of DesqView, the "Share EGA"
parameter might should be set to "Y".

- 137 -

FX-BBS Installation and User's Guide

On the 386SX, I generally configure windows as follows: "Writes
directly to screen" and "Virtualize text" are "Y" and all other
parameters on the first program setup screen are "N". "Close on
exit" is "N", as is "Uses its own colors" and "Can be swapped
out". "Allow Close Window", "Runs in background", "Share CPU"
and "Share EGA" are all set to "Y". Slightly better task
switching can be had by setting "Virtualize Text" to "N", but
when this is done, windows cannot be zoomed and unzoomed, and
more direct screen write problems are encountered. Finally,
depending on how you set some of these parameters (notably
virtualization of text and direct screen write parameters),
communications can be interfered with. You'll know this is the
problem should you find that only parts of the modem init strings
or other modem outputs are being returned from the modem.

The DesqView manual could use some work it seems (don't get upset
Quarterdeck, this one could too...). It's not always clear where
to find information, information is often scattered everywhere,
and too many "supplemental" manuals have been distributed. A
particularly difficult parameter to find is how to get DesqView
to fire up programs as soon as it's started, to allow programs to
automatically start under DesqView when it's started in the
AUTOEXEC.BAT file. To do this, you must create a script file
with the reserved name of "!". Creation of scripts is described
in the manual, so I won't cover it in detail here. For the most
part, I simply wanted to point out the "!" reserved name. One
other thing deserves mention however. It may be best to insert a
five second or so delay in your start-up script, between
activation of each copy of FX-BBS. This prevents excessive disk
activity as each of the copies tries to access its configuration

Note that to run multiple copies of FX-BBS, you need only one
copy of the FX-BBS.EXE file. Each window of DesqView can execute
the same file, share the user account file, upload and download
file areas and so on. The only file which must be different is
the FX-BBS configuration file used for each of the different
copies of FX-BBS which may be running. This is necessary
primarily to specify the different COM port to be used, interrupt
masks and so on. A bi-product is to allow different
configurations to be specified. For example, due to the HST
locking the baud rate at either 19200 or 38400, I found that I
could not run Kermit and Sealink (CLINK) file transfer programs
on both of my lines, since these programs will not operate above
600 baud. Some programs require more memory than others, and for
a time on the 286 system, Kermit was offered on only one line
(which had had the size of its available memory increased).
Different door programs can be made available on different lines,
as can different conferences. Completely different file areas
can be specified as well. For example, one line might offer
programming files and utility programs, while another might offer
games only.

- 138 -

FX-BBS Installation and User's Guide

My own configuration for each of the two lines I run are rather
different. One line is configured to run FX-BBS directly, which
answers the phone on receiving CONNECT. This line currently
offers an several doors which are generally SPAWNED by FX-BBS,
and the Zmodem, Jmodem and Kermit external file transfer
protocols. The second incoming line is running (presently) the
BinkleyTerm mail handler. This program is the one which requires
X00.SYS in the configuration file (or OPUS_COM in the
AUTOEXEC.BAT file). The ChesLine program is the only available
door on that line, but is EXITED to in this case (not spawned).
Memory is also lower there, so that the only external file
transfer programs currently available are Jmodem and DSZ.

- 139 -

FX-BBS Installation and User's Guide

Speed Considerations:

The first system I used for the BBS was a 4.77mhz system, and
frankly it did not have sufficient power to operate in a
multitasking environment. It ran the software all right, and I
even had some expanded memory for use with it. But everything
went in slow motion most of the time. The next system used was a
4.77/8mhz turbo clone with 640Kbytes of memory and two Seagate
ST238 hard disks. This system also did not have sufficient power
to run a two line system, but was able to run in a multitasking
environment provided I was careful about what I ran in the second
partition and when. It would not really support multiple phone
lines for use by two or more callers. Nor did the 10mhz V20
equipped XT clone. The 8mhz and 10mhz clones would perform
acceptably for callers (on a single line) when the DoubleDOS
software was used. DoubleDOS requires less memory than DesqView,
and performs a bit quicker when only one partition is active.
DesqView will perform a bit slowly, even with only one window
open, on an 8088 equipped clone. DesqView was not considered
acceptable on an 8088 or V20 equipped system due to too much
overhead. It ran nicely, but slowly.

The 12mhz AT clone I next used was equipped with 1MB of zero wait
state memory. The memory was divided into three major sections:
640Kbytes of main memory, 64Kbytes of extended memory used by
DesqView, and a 320Kbytes ram disk used to hold the overlaid
version of the program as it runs. This system was connected via
the Lantastic LAN system to a 25mhz 386 equipped clone. The 386
is used primarily for software development and housekeeping on my
part. The modems available included two EasyData 2400 baud
internals, along with an Everex 2400 baud internal, a Micom 2400
baud external and a US Robotics Courier HST 9600. Which modem
was actually being used where varied. The primary hard disk was
a full height Micropolis 1335 formatted RLL for a total of 108Mb.
The important things about this drive are that 1) it has a 28ms
access time, and 2) it was inexpensive (relatively). The second
hard disk was a Maxtor formatted RLL for another 108Mb. This
particular Maxtor is a bit slower, with an access time clocked at
44ms. These drives are adequate for a two line system, and
probably for a four line system as well. The second system (the
25 mHz 386), connected via LAN, contains another Micropolis 1335
formatted using RLL for 108Mb, and a Hitachi something or other
which yields about 65Mb of space. These drives are as yet, never
used for anything on the BBS, aside from ARC and ZIP file

- 140 -

FX-BBS Installation and User's Guide

On the 386SX system currently used, two megabytes of memory are
available. This system retains the previously described Maxtor
drive, and has as well a Priam 519 which offers 243 or so
megabytes of space, as well as a seek time of 19ms. If that
isn't enough, disk caching and ram disks are also employed on
that system, with sufficient memory remaining for four copies of
FX-BBS to run. The modems in use there are an EasyData 2400 baud
internal, the US Robotics Courier HST, and a Micom 2400 baud
external supporting MNP-4.

Discussing modems brings up another point for consideration...
The faster modem should have the lower IRQ number, since the
lower the number, the higher the interrupt's priority.

When running FX-BBS in a multiuser environment, you may sometimes
feel that it does not perform as well as it does in a single user
environment. However, the issue is not properly defined as
whether or not it might run faster on a single user AT system,
but rather, whether or not it performs fast enough. Certainly, a
computer with four users logged on at the same time can be
expected to respond a bit more slowly than one with only one
user. This would especially be true if for example, all four
callers were searching for new messages at the same time (a
rarely occurring circumstance).

The baseline for deciding whether or not a given telephone line
is performing acceptably should be how it would be expected to
perform on a 4.77mhz XT system and how obvious it is to a given
caller that someone else is logged onto the system. Another
criterion, a bit simpler, is whether or not the program can keep
up with the callers at the required baud rates. A 9600 or 14400
HST will place much greater demands on the system than will a
1200 or 2400 baud modem. A modem configured to communicate with
the computer at 38400 baud would also place heavier (though more
sporadic) demands on the system than one configured to lock at
19200. A National Semiconductor 16550 UART is also strongly
recommended for use on any system with even one high speed modem,
since this system has a built in FIFO buffer. This will help to
prevent lost data in a multiuser system. A 12mhz AT might be
able to handle four 2400 baud modems adequately, but fail to
perform acceptably when two 9600s are used. If callers are
_generally_ unaware that another one, two or three callers are
currently accessing the system in another partition, it is
performing acceptably.

- 141 -

FX-BBS Installation and User's Guide

Most of the time, callers will _not_ be hitting the drives
excessively hard at the same time. While one user record may be
being searched for in the user file, another might be having the
main menu, a bulletin or a message presented to them. These text
files represent a very modest disk activity, as does the user
file, since these are read into memory in 8K chunks. So while
the caller is being searched for in the user list (primarily in
memory), the only activity on the line processing the menu will
also be output from memory to the modem. A third caller might be
involved in downloading a file using Xmodem or Ymodem. While the
process of searching for a given file represents a fair amount of
disk activity, the actual download is very easy on disk accesses
since data from the file being transmitted is read into memory in
1K chunks. Some doors and file transfer programs however, know
nothing about multitasking, and so can represent very heavy loads
on a system.

How well the system performs for you and other callers then, is a
function not only of the number of callers you allow on at a
given time (or the number of other tasks in general), but also of
how much power and speed your system provides, how much data it
is expected to deliver to each COM port, and the kinds of
activity going on in each copy running at a given time. An 8mhz
AT system may be able to operate a two line system, with the
callers not aware of each other *most* of the time. A 10mhz
system with 0 wait states might clear up some of any speed
problems encountered, as might a slightly faster hard disk. Can
a 10mhz system with 0 wait state memory be used for three
callers? I can't really say, never having tried it. My own
12mhz system seemed to be capable of supporting three phone
lines, with its 28 and 44ms hard drives, especially with
communications optimization set to 4.

What is required for more than a four line system? Well, first
of all, a special serial board will be needed, one allowing
almost any interrupt to be used, and which will allow all UART
base addresses to be configured to separate locations. I know of
few such board presently available, and those are manufactured by
a firm called "Qua Tech" in Ohio. Their 8-bit serial boards can
generally be configured to support IRQs up to 7, and their 16-bit
serial boards can support IRQs up to 15. Any port addressed may
be assigned to the UARTS, and the UARTS provided can be either
NS16450 (not recommended) or at an extra cost, NS16550 (the
recommended units). These boards are rather special purpose, and
are not inexpensive (last known list price for a two port board
equipped with NS16550 UARTS was on the order of $215). They are
quite nice however, and in some respects may be the definitive
general purpose serial boards. If you are interested in such a
board and cannot find one in your local area, please let me know.
Primarily, I write software, but sometimes sell hardware,
including these cards since they are a natural for FX-BBS.
Registered users of FX-BBS will be given a price break of course.
Be advised however, that I only offer these boards equipped with

- 142 -

FX-BBS Installation and User's Guide

the NS16550 UARTS. Be advised as well that usage of these boards
is NOT required, unless you are planning to drive more than four
modems, or are simply interested in an excellent serial board
(vs. a Taiwan import for $30-40). Finally, FX-BBS does not
presently support sharing of interrupts. This means that the
even more expensive DigiBoards and such, which offer things like
eight modems running from a single IRQ, are not only not
required, but probably cannot be properly used.

For more than four lines, something faster than a 12mhz, 0 wait
state clone is certainly recommended, especially with high speed
modems (it may be the case that no Dos system is capable of
driving more than two or three modems at high speed). This might
be a 16mhz 80286 system, or better still, an 80386 system of some
sort. The 80386 systems are capable of switching tasks much more
rapidly than most systems using 80286 cpus. Certainly, a very
fast hard drive, would help as well, and ESDI or SCSI drives are
quite nice (fast). If you're independently wealthy, or your
company is, consider the 130 MB CDC drive as used on some Compaq
Deskpros, which has an access time of something like 16ms. If
you're wealthy as well as extravagant, Core offers a 100Mb hard
drive with an access time of only 9ms... Add a caching
controller for more speed.

A brief digression: no doubt, all this sounds horribly expensive,
and perhaps can be (depending on your hardware source). But
driving multiple phone lines will generally be expensive,
regardless of the BBS program's approach to the matter. Another
BBS system for example, employs a special box which serves no
other purpose than to house modem cards. The box and modem cards
are manufactured by the authors of the BBS program it seems, and
can't be used for much other than driving a many line BBS
package. Nothing wrong with this approach, and it may be the one
you prefer ultimately. With FX-BBS however, only standard
modems, systems and LANs are employed. If you decide not to run
a BBS next week then, you can sell your excess hardware to the
business down the street, or donate it to the church and expect
them to be able to really use it. When everything is said and
done, the approach taken with FX-BBS seems as cost effective as
others available. Perhaps more so.

FX-BBS can be completely interrupt driven, with each copy
employing a ring buffer for both transmit and receive (the
receive buffer has a size of 1K, the size of a Ymodem
transmission block, and transmit buffer has a variable size of up
to several Kbytes). When run in a multitasking environment with
multitasking and communications optimization invoked, FX-BBS will
fill its transmit buffer as rapidly as possible. When full, that
particular copy of the program will be "idled". That is, it will
begin giving up *all* its cpu time to the other programs running
until its transmit buffer has been substantially emptied. When
this occurs, update of the local screen effectively stops. This

- 143 -

FX-BBS Installation and User's Guide

is because the transmit buffer is full of data already displayed
locally (or from a file for downloads) and the program must wait
for the caller's system to catch up. It is important for you to
realize that while your local screen may seem paused, data is
continuing to be displayed on the caller's screen as fast as
their modem can pull it in. More importantly, your cpu time is
freed for processing other tasks. As you add more lines to
support, you'll probably want to increase the communications
optimization so that larger buffers are used. The result should
be that a given copy of the program will go idle more often,
leaving more cpu time for other things.

I have used the Microsoft SmartDrv disk caching program and have
observed marginal performance increases for some activities
performed on a regular basis. However due to the number of files
involved in the typical BBS environment, and the frequency with
which different files are opened, I do not feel that disk caching
will often provide much assistance for BBSs (though it may
provide some). Indeed, some of the lesser disk caching programs
might be capable of turning your system into a real nightmare...
The latest version of DesqView is also alleged to have lots of
problems when used with some caching programs. In an either/or
situation, I would recommend that memory available be used for a
ram disk instead of disk caching and that files you know to be
accessed often be placed there.

Memory caching on 386 systems is not *generally* recommended, for
reasons that have been discussed elsewhere (cost versus utility).
Certain cpu speed-up programs can help however, such as the
public domain programs called SPEEDER and CALCQF. These programs
seem capable of providing a performance increase of 3-4% (hardly
noticeable, but every little bit helps) on certain computers by
modifying the system's memory refresh rate.

To run FX-BBS in stand-alone, that is, with NO COM port
available, you should invoke the program with a second command
line argument, "DEBUG". When this is done, no effort to talk
with a COM port will be made. You may notice some "funny" things
going on when DEBUG is invoked. It IS the debug option I use,
after all. It will function none-the-less.

COM ports 1 through 8 are supported by the program presently,
though I'm not certain that there really is such a thing as
"COM8"... What's really being done is that the modem is
supported and configured for at the hardware level, with DOS's
support functions completely bypassed most of the time. FX-BBS
could conceivably support more than 8 ports if the internode
"party line" chat function were disabled. It is this function
that limits the number to 8 ports. On the other hand, there is a
limit to the maximum number of tasks a given system can be
expected to handle without impacting others...

- 144 -

FX-BBS Installation and User's Guide

It is anticipated that only rarely would callers access the same
files at the same time, and most files would not present a
problem. The same file can be referenced for downloading at the
same time without problems for example, and the same file cannot
be uploaded by two callers (unless you specify different upload
directories). When you run both copies on the same cpu, ONLY ONE
one caller creates a file by the upload process, the other will
be told that the file already exists. The only way both could
upload a file with the same name would be if they did so at
exactly the same time.

When running Desqview, be certain that you specify the tasks as
NON-SWAPPABLE! Each copy will intercept the interrupt vector for
the COM port specified. If you swap out the programs, you will
swap out the interrupt handler as well. The result will be a
system crash, or at the very least, an extreme loss of data.
Even on a 386 system, if the system is overloaded, data loss can

- 145 -

FX-BBS Installation and User's Guide

Local Area Network Notes:

FX-BBS depends on standard network file server software and its
redirection for accessing messages and downloadable files
remotely. Adding logic to support this independently would be
too costly at the present time (FX-BBS is large enough as is). A
separate program to accomplish file server functions is being
contemplated however, to allow a "file server" system to better
be able to run DesqView. The FX-BBS file server software would
take the place of the NOS as required, but would be able to run
in a DesqView window.

FX-BBS network specific functions are limited at the present time
to those supporting named datagram processing to accomplish
inter-system chatting among multiple users. FX-BBS uses NetBIOS
support for this processing, so you may want to be sure that
NetBIOS support is available for whatever you end up getting.

Inter-system LAN chatting is selected by setting a parameter on
Screen L and functions as you might expect, though with certain
restrictions at the present time. When LAN chat mode is enabled
and selected, the screen is cleared and two input lines are
presented on screen, one for the SYSOP, the other for the caller.
As each enters a line of text, it is displayed on these input
lines, until a carriage return is entered. At this point, the
line of text is tagged with the name of the person who entered it
and it is broadcast as a datagram to others who might be
listening. The parameter on Screen L is provided in case you
have a LAN card installed in the system, but do not wish to allow
inter-system chatting.

To use the LAN internode chat function, you must first use the
FXCOMML TSR program. This file must be loaded prior to running
any multitasking software you plan to use (DesqView or
DoubleDOS), as should the entire LAN operating system. This is
due to the fact that the LAN buffers cannot be allowed to be
swapped into and out of memory. Following this, the FXCNFCFG
program must be run to configure the LAN software for the
required (shared) datagram support. The datagram sessions are
opened by the FXCNFCFG program, and remain open until FXCNFCFG is
run again to terminate them. Following this, DesqView or
DoubleDOS can be started along with as many copies of the BBS
program as your system supports.

The only Network Operating System (NOS) specifically used with
FX-BBS by myself thus far has been Lantastic, running on both
Artisoft hardware and Ethernet (a user in North Carolina has at
this time, reported success with Novell ELS level II, but I've no
direct experience with this). Lantastic NOS coupled with
Artisoft network cards seems a reasonable enough network system

- 146 -

FX-BBS Installation and User's Guide

and is rather inexpensive. A two system "starter kit" has a
suggested list of $399.95 (may be found for less if you look),
less than some EEMS boards. This includes two LAN cards, each
equipped with their own Z80 cpus and 32Kbytes of memory, as well
as the software required. Lantastic is a fully NetBIOS
compatible LAN, with a throughput speed of 2mbps. More
importantly, Lantastic is a DOS compatible NOS, requiring no
reformatting of your drives into some weird proprietary format.
Performance can be increased or decreased by adjusting buffer
sizes. All required software is included as well, including a
NetBIOS compatible driver, the remote workstation and file server
software. The remote station software requires somewhere on the
order of 7Kbytes of memory, and the file server software as
little as about 40Kbytes of memory (increasing the number of
tasks supported or the size of the buffers will increase this
amount). One drawback to Lantastic is that regardless of the
card used (versions of Lantastic NOS can be purchased which
support Ethernet or Token-Ring), you cannot generally mix and
match cards from various manufacturers. This is because, while
NetBIOS support is generally available from different
manufacturers, the NetBIOS available from Western Digital will
not necessarily communicate with that available from D-Link or
Tiara. That is, the "NetBIOS standard" is less of a standard
than one might hope.

Ethernet is a much faster media, rated at 10mbps. Inexpensive
implementations are becoming more and more available. While not
extensively tested in the Ethernet environment, FX-BBS seems to
function well in the testing that has been performed and I have
complete confidence in the functionality of the setup (at least
when used with Lantastic). Be advised however, that some
Ethernet cards and/or NetBIOS drivers can require a great deal of
your cpu's time, resulting in very degraded performance on
occasion. You may therefore want to seek out network cards with
onboard cpus and/or large onboard transfer buffers, or plan on a
dedicated file server system. The Lantastic cards, while only
rated at 2mbps, have their own cpus. Often, these cards seem to
impact a system's performance less than some of the "faster"
Ethernet cards.

The speed of the systems involved can also have a dramatic effect
on network performance. When transferring data (using the Dos
XCOPY command) between a 25mHz Compaq 386 and an 8mHz AT clone, I
clocked the data rate at roughly 41KBytes per second. When both
systems were 25mHz Compaq 386s, the speed nearly doubled, to
81KBytes per second. The network cards used were Western Digital
Ethernet cards, and the NetBIOS in use was the Lantastic AI-
NetBIOS. The NOS was again, Lantastic.

For Ethernet cards, I would recommend the Western Digital units
as being very reliable, relatively fast and not horribly
expensive. They do not have onboard cpus. The Western Digital

- 147 -

FX-BBS Installation and User's Guide

cards come with NetBIOS drivers (as well as other drivers). The
(very optional) Artisoft NetBIOS driver for Western Digital cards
costs an additional $295 per network, but requires less memory
than the Western Digital driver and may be a bit faster.
Artisoft is located in Tucson, Az. D-Link in Southern California
also makes both 8 and 16 bit Ethernet cards. Their version of
NetBIOS is $100, and an additional copy is supposed to be
purchased for each system which will run it. None of their cards
have onboard cpus at the present time. The Lantastic NOS by
Artisoft can be used with each of these cards provided the *card*
manufacturer's NetBIOS is used.

Another concern regarding Lantastic (and all NOSs, I assume) is
that the file server portion of the NOS is not always able to run
with DesqView on a given system. The file server code used on a
given system is usually multitasking software in and of itself
and so may not be compatible with other multitasking operating
systems. That is, on many systems, the file server software must
be run *instead* of DesqView or DoubleDOS. In these cases,
additional resources are required. Shoot. This isn't coming out
as clearly as I wanted it to. Let me try again...

A hypothetical BBS network involving two systems *might* best
(most cheaply) be configured to run five lines on the
"workstation" system, and two lines plus the file server software
on the other system. If the file server software is not
compatible with DesqView or DoubleDOS however, this cannot be
done. In this case, only one copy of the BBS program could be
used on the system which was acting as a file server for the

On a 386 system, Desqview will often run with the Lantastic NOS,
provided the NOS is loaded first. Such is not guaranteed,
however. On the two 386 systems I have, I can run this way on
one, but not on the other. The last time I spoke with
Quarterdeck about the matter, they informed me that while they
were aware many folks used Lantastic with Desqview, their
programming staff could not determine why it worked at all, and
thought that in fact, it should not. Again, even though they are
aware many users use their systems in this manner. I have been
given at this point to believe that the reason it does not work
on one of my 386 systems is something to do with the disk
controller in use on that system. The particular disk controller
used (DTC 7287) was chosen because of its ability to perform
sector translation (the drive in use is too large for use with a
normal AT sort of controller; it has too many tracks), and so
likely will not be going away.

Ok... *maybe* I've cleared that matter up, maybe not. In a
network environment consisting only of two systems, attempting to
make the file server system run copies of the BBS program seems a

- 148 -

FX-BBS Installation and User's Guide

desirable situation. However, when more than two systems are
involved, that is, when more than a certain number of systems are
going to be making heavy file requests from the file server
system, it will at some point become necessary to dedicate a
system to being a file server. If, for example, twenty other
users were to be making heavy hits on the file server, trying to
make the file server run other programs as well would often
seriously impact the speed of the other twenty programs. Are we
all clear on this stuff? I know I used to be... before I
started writing this.

Should you plan on going with either Novell or 3Com cards, you
will likely be required to purchase the software distributed by
those manufacturers. This software is not inexpensive, and
sometimes (but not always) imposes weird system requirements such
as the reformatting of your hard drives into some non-Dos format.
For Novell software, you should probably get nothing less than
ELS Netware Level II, which has a suggested list (this week) of
$1495, though I have seen it discounted to around $1200 here and
there. ELS Level I, as I understand it anyway, is much less
configurable. While 3Com literature indicates in a somewhat
nebulous manner that NetBIOS drivers are available, these drivers
did not come with any of the 3Com Ethernet cards I've seen, and
were available only through the purchase of separate (and not
inexpensive) software packages (according to 3Com representative
Beth Dixon, and as of Fall, 1989). One 3Com card however, is
available with an onboard 80186 and up to 512Kbytes of memory...
Its list price (at this writing) is $895. Perhaps these
networking systems are best left to those persons or agencies
with corporate-like budgets...

While I am familiar with the concepts involved with IBM's Token
Ring Network, I have never had the opportunity to use this system
and so can offer no comments with regard to its performance or
lack thereof, nor that of ARCNet. I can say however, that recent
tests conducted by PCWeek indicate that Ethernet is much faster
than even the 16mbps version of Token Ring, at least when Novell
drivers are used, and that this makes a great deal of sense on a
theoretical level. Artisoft is also supposed to have a NetBIOS
driver available for use with some ARCNet cards. I have not
tested the program with ARCNet however.

In my own tests, the FX-BBS program performs quite acceptably
using the Lantastic LAN. That is, with *both* a 12mhz 286 (not
running Desqview), and a 25mhz 386 system (that was running
Desqview), configured as file server systems, I was able to tell
the 25mhz system that the BBS system's drives C: through H: were
its own C: through H:, with the local C: partition re-mapped to
be drive J: using the Dos SUBST command. On the 25mhz system
then, I simply entered:

- 149 -

FX-BBS Installation and User's Guide


There really isn't a great deal more I can say about usage of a
local area network. But there are a few other things, and a few
things worthy of restatement:

The Lantastic software at least, and I suspect a few others as
well, is not completely compatible with multitasking systems
such as DesqView and DoubleDOS on all systems. While it seems
to function acceptably when run in a DesqView window on one
386, it refused to function in that manner at all on a 286 and
is recalcitrant on another 386. This is because the Lantastic
file server software is itself, a multitasking program, and
the capabilities of the 286 and different 386s differ. When I
attempted to run it with DesqView on a 286, things came to a
screeching halt real quick. When I tried such using
DoubleDOS, it worked a bit better. But not lots. With
DoubleDOS running on the file server, I was able to read from
the BBS system's drives without difficulty. I was not able to
write to them however, and in the process of forcing the
issue, I ended up having to reformat and restore a hard

For this reason alone, you may have to run the file server
software as a single task on a computer, without attempting to
use DoubleDOS or DesqView. Remote systems can still run
DoubleDOS or DesqView as required, since the NOS need only be
run on the file server system.

The more nodes you plan on ultimately adding, the faster your
network should be. Lantastic offers a 2mbps throughput rate
and onboard Z80 cpus with 32Kbytes of memory. The Z80s may
make it more attractive than you would at first think based on
its throughput rate. It employs a CSMA/CD type of protocol.
IBM's token ring comes in two flavors, the original 4mbps
version, and the more recent 16mbps version. Token ring is
not known for its speed, but is alleged to provide good
throughput over sustained periods of heavy loading. Ethernet
offers a 10mbps throughput rate and like Lantastic, uses
CSMA/CD logic. It offers the fastest response time under
light loading, and frequently under heavy loading as well,
since it doesn't need necessarily to wait for its turn...
But remember to look for onboard cpus, the amount of memory
provided and/or DMA capabilities.

Choosing a LAN is not to be taken lightly. With proper
configuration, Lantastic and the 2mbps cards I suspect, could
support perhaps 20-30 users before throughput degradation
began to be noticeable to callers. Following that, it might
be best to switch to Ethernet. Conversion at that point would
not be inexpensive.

- 150 -

FX-BBS Installation and User's Guide

The EDITUSER Program:

The EDITUSER program is provided to allow easy off-line edits and
changes to your BBS user file. Often, you'll want to change
caller information online with the FX-BBS program, using the
SYSOP Maintenance menu functions. The EDITUSER program presents
almost all caller parameters on a menu however, and can be very

The program is invoked with the following line:


Where OPTION can be "CREATE" to create a new user file, "UPDATE"
to make changes to an existing user file (a "BAK" file will be
made prior to allowing modifications to be made), "REVIEW" to
examine only callers with an access level of one, or "LIST" to
list the users within the file. Again, since the caller password
filename is not hard coded, it must be specified when invoking
this program.

When the program is invoked with the CREATE or UPDATE option, it
will display a screen asking for either the record number you
wish to view, or the name of the caller whose record you wish to
examine. You might enter "0" for record 0, "384" for record 384,
or "BOB SMITH" if he's the only one you're interested in. If
entering a caller's name and EDITUSER does not find that caller,
it will ask you if you wish to add the caller to the user file.

When a caller's record is presented on screen, use the cursor up
and down keys to move among the fields. The insert, backspace
and delete keys will all function as you expect. The CTRL-X
keystroke combination can be used to clear a field from the
current cursor position to the end of the field, and the CTRL-A
combination to clear the field altogether. You may also use the
PgUp and PgDn keys to page around through the records in the
file. A caller can be deleted from the file by depressing the
CTRL-Z keystroke combination, followed by the F1 key to save the

The REVIEW option is provided as a simple and effective way of
reviewing recent additions to the caller file with an access
level of one. These callers can have their access level raised
or records removed as required.

- 151 -

FX-BBS Installation and User's Guide

When you have completed all changes to the file required and
depress the Escape key to leave the program, additional options
are presented. The first is the option to delete callers who
have not called since a certain date. You will be asked to
supply the cutoff date, and will have the option of either
automatically deleting any and all callers who fit the category,
or of being asked about each caller prior to deletion.

The second option allows for all callers with an access level of
one remaining in the file to be removed.

Note that when you make a change to a user's record, the change
is *not* saved in the file unless you depress the F1 key!

When using EDITUSER to list a caller file, you are also provided
with the option of listing passwords or not as you require.

Unlike the primary FX-BBS program, along with the FXREPACK and
FXMAIL programs, the EDITUSER program is not heavily optimized
for usage in a multitasking environment. It does not perform
file locking in any way, nor does it give up time for other uses
when idle.

A "lock" parameter is provided for each caller record. This
parameter can be set to either 0 or 1. When nonzero, neither
FX-BBS nor EDITUSER will automatically delete the caller under
any circumstances. If the record is requested to be deleted in
an interactive way, you will be notified about the lock flag and
specifically asked before the program deletes the user.

Finally, note that when deleting users, the EDITUSER program does
NOT delete messages to/from a particular user. Such messages
MUST be deleted PRIOR to deleting the user, or they will not be
able to to found as easily.

EDITUSER was written using Turbo C 2.0, and employs some assembly
language routines originally developed using MASM, and later
assembled using TASM version 1.0.

- 152 -

FX-BBS Installation and User's Guide

Setting Up and Maintaining Your Directory Files:

FX-BBS employs a unique directory file structure. This structure
is the result of a desire to allow for file descriptions to be of
any length and to provide maximum flexibility for the SYSOP. The
mechanism provided works quite well in fact, once you get the
hang of it. It is not strictly a database, but a sort of
combination between database and text files.

Directory Text Files:

When you initially put your directory files together, you can use
any sort of ASCII text editor (do not use an editor that imbeds
special control characters, such as WordStar, Word or Sprint).
It is also preferable to use an editor that allows TABs to be
disabled, and that supports simple box drawing characters. Since
a simple editor is used to create the directory files, changes
can be made quite rapidly, allowing for an overall faster setup.

Directory text files consist of two primary areas, a "header"
area and the file descriptions. An example is provided with the
FX-BBS distribution package for your consideration.

The header may be of any length and contain any characters save
one. This header usually would describe what kind of files
appear inside the directory listing, such as games, word
processors, graphics files and so on. A box can be used to frame
the header description, and for the directory files in the
graphics path, colors and shadow effects might be added as well.
The header cannot contain a colon (":"), as this character is
used by FX-BBS. A colon *must* be provided in the first column
after the header so that FX-BBS knows when the header has been
completely output (the FXDCHECK program also expects to find a
colon in the first column after the header area, and will ignore
anything appearing before a colon). Colons may appear in file
descriptions, just not in the header area.

Following output of the header, ANSI color codes will be applied
by FX-BBS to display file names, sizes and descriptions in
different colors. This application of ansi color codes occurs
automatically from within the program any time a caller selects
the ANSI graphics mode and is relatively transparent to the
SYSOP. Because of this application of ANSI graphics, you should
not yourself, place ANSI escape sequences into the file listing
area of a directory text file.

- 153 -

FX-BBS Installation and User's Guide

The SYSOP Add and Install Functions:

The [A]dd a file function on the SYSOP maintenance menu allows
you to enter a description for any file in the upload directory.
This description can be placed in either the UPLOADS.DSC file as
a new upload file description, or the description can be placed
into a permanent directory text file. To do the latter, the Add
a program function simply calls the logic associated with the
file Install function.

While you can edit the directory text files at any time, the
"Install" function on the SYSOP maintenance menu can also be used
to move file descriptions from the special "UPLOAD.DSC" file (or
file descriptions entered using Add a Program logic) into these
text directory files. Descriptions so moved will be inserted
after the header area (after the colon) and before all other file
descriptions. In this way, newer file names will always be near
the top of a dir file, where the caller will want to see them
(callers don't have to go to the end of the dir file to see
what's new).

Files installed in this manner have their names (1 to 12
characters) printed starting at column 3 and file size starting
at column 18. File size is listed in "K", where a K is 1024
bytes. That is, a file with a size of 65535 bytes would have its
size listed here as "64K". Descriptions start in column 24 of as
many lines as required (The upload process imposes a 20 line
limit). The first line before the file description will indicate
the day, date and time the file was received, and the line
following the file description will indicate who the contributor
of the file was. Your initial dir files should also use these
same column numbers for conformity. Finally, each file
description will be separated from the others by a blank line.

When you select the SYSOP Install function, FX-BBS asks you for
the name of the file you wish to install. Following input of a
file name, FX-BBS searches the UPLOAD.DSC file for the file name
specified. When it has been found, FX-BBS will then check the
upload directory for the existence of the file. If it cannot be
found, FX-BBS will abort the Install process.

FX-BBS next displays a menu of your creation, called "DIRMAP.BBS"
which must be located in the normal BBS path. This file can
contain anything you wish, but is intended to assist you in
determining where to place a particular file based on which
subdirectory you might use to contain files associated with a
particular "DIRx" text file. You may name subdirectories
anything you wish, such as C:\FILES\EDITORS, or F:\FILES\GAMES
and so on. When this is done however, FX-BBS has no way of
knowing what DOS subdirectory belongs to which of the DIRxx text

- 154 -

FX-BBS Installation and User's Guide

files. If you name the various subdirectories DIR1 or DIR22 for
example, the number at the end of the directory name will be
assumed to correspond to the DIRx text file the description is to
be added to.

If the file being installed is found to be hidden, that is, a
private file for the SYSOP, FX-BBS will ask you if you wish to
"un-hide" the file before proceeding. Following this, FX-BBS
asks you for the actual name of the DOS drive and directory you
want the file to be placed into. Once this is entered, the
MOVE.EXE program is invoked by FX-BBS to move the file from the
upload directory into this DOS directory.

If the MOVE program completes successfully, FX-BBS continues by
proceeding to process the text description of the file. This
will be accomplished in one of two ways. If FX-BBS determines
that you have moved the file to a DOS subdirectory that has a
name matching one of the dir text file names, it will
automatically assume that the text description is to be placed
into the dir file with the matching name. That is, if for
example you installed a given file into D:\FILES\DIR12, FX-BBS
would assume the text description of the file should be placed
into the file named DIR12. For this reason, it may be a good
idea to name your caller accessible file directories DIR1, DIR2,
DIR9 and so on. These names can be used beneath the download
root path specified. For example, I use directories named
C:\FILES\DIR21, D:\FILES\DIR9, E:\FIlES\DIR19 and so on. If the
directory name you specify does not match one of the directory
text file names, FX-BBS asks for the number of the directory file
the description is to be placed into, such as 17, or 3 and so on.

Once the dir file name has been determined, either automatically
or be asking the SYSOP, FX-BBS proceeds to process the dir files
in both the TEXT and GRAPHICS text file paths specified in the
FXBSETUP program, displaying a message indicating which file it
is processing.

You may subsequently use a standard text editor to change the
file description installed by the program. In this manner, you
can make the file description shorter or longer. The description
may be of any length. This allows you to retain the original
uploader's comments, and to add your own as required. The FX-BBS
program does not presently convert descriptions entered in all
upper case to mixed case. While this would be a nice feature, it
seems a bit much to ask of the program, and might also require
too much code space to justify the function. In this instance
however, you may once again use a text editor to perform the
process manually.

- 155 -

FX-BBS Installation and User's Guide

The "Delete a file" function displayed on the SYSOP maintenance
menu currently relate only to the UPLOAD.DSC file. That is, this
function may be used only on the files described in the
UPLOAD.DSC file. To delete file descriptions in dir files other
than dir99, you must again use a standard text editor.

A final note: Your caller accessible files should always be
placed into a subdirectory as opposed to the root directory, for
a couple of reasons. First, the root directory is generally
restricted to containing not more than 512 entries, whereas
subdirectories are not. Second, you may at some point wish to
add other programs or uses to a particular hard drive. If all
your downloadable files are listed in the root directory, your
other files and subdirectories would get lost (visually and

- 156 -

FX-BBS Installation and User's Guide

The FXDCHECK Program:

As you may have surmised, there is only a loose association
between the file names and descriptions contained in the
directory text description files and the downloadable files which
are actually on your system. Nothing in the directory
descriptions tells FX-BBS where a particular file is. Instead,
FX-BBS searches for each file at the time of the download

Because of this loose association, it is possible over a period
of time for your directory text files to become inconsistent with
what is actually available. That is, downloadable files may
become corrupted or lost, yet remain in your directory
description files. Files might be added to downloadable areas
with the intention of adding a description for them at a later
time, and then forgotten.

The FXDCHECK program is intended to alleviate these sorts of
problems. FXDCHECK performs three basic functions in an effort
to help you validate your system. First, FXDCHECK searches all
your directory text files looking for duplicate entries. That
is, looking for occurrences of a given file name in more than one
directory text file (there's nothing really wrong with this
situation... I in fact cause it to occur quite often and on
purpose. But it's nice to be kept informed about these things).
Second, FXDCHECK will generate a list of file names found in
caller accessible paths (downloadable), which were not found to
be listed in any directory text files. These are files a caller
can download, but cannot possibly find a description for. Third,
FXDCHECK provides a list of all file names for which there are
descriptions, but no matching files. These are files a caller
can see the description of, and yet will be unable to download.

The FXDCHECK program need not be run often. No more than once
every month or two. This is fortunate, since the program has a
considerable amount of work to do and therefore can require a
fair amount of time to complete. On my 12mHz AT system, equipped
with 220Mb of disk space and containing approximately 2,000
downloadable files described in 36 directory text files, FXDCHECK
requires some 30-40 minutes to complete.

To run FXDCHECK, you must enter the name of a configuration file
to be used. For example, "FXDCHECK FX-BBS.CFG". You must also
provide FXDCHECK the ability to use the Dos CHKDSK program.
CHKDSK is used with the "/V" option to generate a list containing
all files on your system. This list is then used by FXDCHECK
when comparing files listed in the directory text files to those
actually available.

- 157 -

FX-BBS Installation and User's Guide

When started, FXDCHECK will perform a CHKDSK/V for each drive
listed in the configuration file as containing downloadable
files. Because the CHKDSK program's output is redirected,
problems which might occur are not shown to you. One particular
problem can arise from a lack of memory when using a multitasker
such as DesqView or DoubleDOS. When FXDCHECK detects one of
these programs, it will refuse to run. You cannot use the
program while running either DesqView or DoubleDOS. Another
problem which might be encountered relates to disk structure
problems encountered by CHKDSK. These types of problems can be
avoided by running CHKDSK/F prior to running FXDCHECK. Once the
CHKDSK program's output has been gathered, FXDCHECK will
construct an additional input file which contains the names of
all files listed in your directory description files.

Following this, FXDCHECK will begin searching for duplicate
entries in your directory descriptions. This process consists of
comparing each name listed sequentially with all other names
listed. As each new file name is processed, FXDCHECK will
display a period to indicate that it is in fact, doing something.
As this process continues, it will begin to get faster, since
fewer and fewer file names must be compared.

Next, FXDCHECK will begin its comparison of files contained on
your disks with those listed as available for download. For
files which are listed in the output of the CHKDSK operation but
which are not caller accessible, a period will displayed and the
file will be ignored. When processing files which are caller
accessible, FXDCHECK will display the name of the file on the
disk drive being processed and whether or not that file is found
in a directory text file or in the recent uploads area.

A report file is then generated which lists for you the three
major categories of information. This file is called
"REPORT??.FXD", where the "??" represents the system number
listed in the configuration file used to run FXDCHECK. Remember,
when multiple configuration files are used, different sets of
downloadable files and directory description files can be
provided, requiring the ability to produce multiple reports. The
report generated will indicate the system name, and the date and
time of the report's generation. It may be examined with a text
editor, or copied to a printer for later examination.

FXDCHECK makes for itself a subdirectory, called "FXDCHECK",
beneath the main FX-BBS operating path as listed in the
configuration file used. Report files, as well as all temporary
files generated (and deleted) as FXDCHECK runs are stored in this

- 158 -

FX-BBS Installation and User's Guide

Prior to running FXDCHECK, you should run the CHKDSK program to
search for lost clusters, etc. That is, when FXDCHECK runs
CHKDSK for itself, its output is redirected to a disk file.
Should CHKDSK find lost clusters, it will output a message about
whether or not you wanted to correct the problem. Since the
output of CHKDSK is redirected to a file, you will not see such a
message. Instead, the program will give every appearance of
simply stopping. Should this occur, depress CTRL-break, run
CHKDSK/F on all drives, and then restart FXDCHECK.

Other notes: FXDCHECK contains no optimization for a
multitasking environment and is NOT intended for use in a
multitasking environment. Since the program is disk intensive
and requires considerable time to complete, it is optimized for
speed primarily. You should shut your BBS down while running the
program. Should you decide to run it under a multitasker, be
advised that there is no file locking employed and it is
therefore possible to generate sharing violations ("Abort, Retry,
Ignore?" type messages). Be aware as well that you should NOT
run more than one copy of the program at a given time, since each
copy will attempt to use the same filenames and subdirectories.

- 159 -

FX-BBS Installation and User's Guide

The FXFILCVT Program:

FXFILCVT is a utility program which is intended to allow for a
nightly batch file or for manual conversion of uploaded files
with an extension of "xxx" to files with an extension of "yyy".
That is, ZIP to ARC, or LZH to ZOO and so on. I have
standardized the files on my particular BBS to be compressed with
only one method (ZIP in my case), but continue to receive files
with extension's of ARC, PAK, ZOO and LZH. I do not wish to
prohibit the uploading of such files, yet it is an annoyance to
have to convert them manually myself, enough of one such that it
has been done infrequently in the past. The FXFILCVT program
addresses this problem. While there are other similar
conversion programs available, FXFILCVT was necessary to
accommodate differences I wanted for use with FX-BBS. Specific
features of the program are as follows:

FXFILCVT is table driven, and uses other programs to
decompress and recompress as required. It can therefore
support converting anything to anything, and presently allows
for up to 20 different conversion types to be specified for

FXFILCVT performs recursive recompression of files, up to 4
layers deep. That is, an LZH file contained in another LZH
file will also be recompressed in the manner you desire.
Should the nested LZH file contain a ZOO and a PAK file, both
of these files will also be recompressed into the desired file
type if a conversion has been specified for them.

FXFILCVT cleans up after itself, deleting files that have been
recompressed into other files and removing any subdirectories
it creates.

FXFILCVT performs error checking on the conversion process by
checking the status returned by the decompressing and
recompressing programs, and in the event of a problem, aborts.
Such error checking is of course, dependent upon proper status
being returned from the programs used for compression.

FXFILCVT maintains the original dates of all files.

FXFILCVT supports "labeling" of compressed files with a
comment appropriate to your BBS (which you provide), provided
the compression method you use also supports such comments.

- 160 -

FX-BBS Installation and User's Guide

FXFILCVT provides an option to do nothing other than relabel
all compressed files within subdirectories (without performing

When the FXFILCVT program is used on files in the recent
uploads area, it can be told to change the UPLOADS.DSC file so
that the file names and sizes stored there will match those of
the converted files (FXFILCVT will NOT update standard
directory text files presently).

Because FXFILCVT can support automated conversion of so many
different file types, initial setup may seem a bit tedious. Once
this is done however, I'm sure you'll find it to be a valuable
time saver. I run the program myself on the second line of my
BBS, in a batch file used in association with echomail. This
batch file automatically runs the program each night.

To use the program, you must first chdir to the directory
containing the files you wish to modify. Following this, run the
program with a single argument:


where 'arg' is "UPDATE" if you are changing files in the upload
area and wish to have the UPLOAD.DSC file changed to reflect
the new name and file size, or "NONE" if you are converting files
in another directory.

FXFILCVT requires a text input file called FXFILCVT.DEF to reside
in whatever directory the actual FXFILCVT.EXE file resides in.
Note that it MUST be located in the SAME directory!!! The first
seven lines of the FXFILCVT.DEF file contain control information
which relates to all other files. Following the first seven
lines, up to 20 sets of three repeating lines can be specified.

- 161 -

FX-BBS Installation and User's Guide

The FXFILCVT.DEF file has the following specific format:

Line 1: The fully qualified path of the subdirectory the
UPLOADS.DSC file is in.
Line 2: New extension the files are to have (one type only).
Line 3: Name of program to be used to recompress all files.
Line 4: Command line arguments to be passed to the recompressing
program when it's run, not including any file names.
Line 5: Name of the program to be used to add your comments to a
recompressed file (enter the word "NONE" if comments are
not supported by your compression program).
Line 6: Command line arguments to be passed to the program
Line 7: Name of a standard ASCII (or ANSI) text file containing
the comment(s) to be added.

The following lines repeat as required. Up to 20 parameter sets
can be specified:

Line 8: Extension of file being converted.
Line 9: Name of the program to be used to decompress this file
Line 10: Command line arguments to be passed to the decompression
program when it's run, not including the name of any
files to be converted.

Example: To convert ARC, ZOO, PAK and LZH files to ZIP files, and
with the file UPLOADS.DSC located in directory C:\FX-BBS:

Contents of FXFILCVT.DEF file (do NOT include MY comments, or

Comment: Contents:
-------------------------------------------------- -------------------
path to uploads.dsc file (ends with '\')-> Line 1: C:\FX-BBS\
new extension the converted file is to have-> Line 2: ZIP
command to recompress all files-> Line 3: PKZIP
recompression arguments-> Line 4: -ex
command to add comment to all files-> Line 5: PKZIP
arguments for program adding comments-> Line 6: -z
name of file with comment in it-> Line 7: COMMENT.TXT
extension of file to convert-> Line 8: ARC
program to decompress files with .ARC extension-> Line 9: ARC
decompression arguments-> Line 10: -e
extension of file to convert-> Line 11: LZH
program to decompress files with .LZH extension-> Line 12: LHARC
decompression arguments-> Line 13: e
extension of file to convert-> Line 14: ZOO
program to decompress files with .ZOO extension-> Line 15: ZOO
decompression arguments-> Line 16: -extract
extension of file to convert-> Line 17: PAK
program to decompress files with .PAK extension-> Line 18: PAK
decompression arguments-> Line 19: e

- 162 -

FX-BBS Installation and User's Guide

The above file should have a CR/LF after the last line. Note too
that an additional 16 sets of the repeating arguments can be
entered, as required for converting other file types.

Example contents of COMMENT.TXT file:
BerthaBoard (209) 823-0093 [HST] Manteca, Ca.

Commands which would be used to convert files in the upload area:

Commands to relabel all files in directory D:\FILES\GAMES:

Note that in this case, FXFILCVT has no way of knowing which, if
any files to be relabeled may already have the correct labels...
It therefore has no choice but to execute the relabel function
for ALL files in the directory.

Commands to execute to convert files NOT in upload area
(say files in E:\FILES\DIR3):

For this example, it would of course be necessary to use a text
editor to modify the file description(s) in the dir text file.

- 163 -

FX-BBS Installation and User's Guide


FXFILCVT does NOT delete original compressed files in the event
of an error returned from the decompression program. In the
event of such an error, on either decompression or recompression,
the program stops running, leaving any subdirectories and
decompressed files it has created laying around for your
examination. EXCEPTION: If the decompression/recompression
programs you use do not return a status indicating their success
for examination by FXFILCVT, FXFILCVT will assume everything is
just fine... and this could be a problem for you in some

Various compression programs may or may not be able to run in
more limited amounts of memory as provided under DesqView. Be
sure and TEST the various combinations BEFORE you try running the
thing in a batch file.

Users of the PAK program don't necessarily use an extension of
PAK... I've received many files with an extension of ARC that
are incompatible with ARC decompression programs. As yet, I've
not used FXFILCVT enough to know how best to deal with this
situation. I do think it deserves your attention however.
Perhaps what I'll have to do is add some logic to retry ARC files
with the PAK program, if/when either are found to be specified in
the FXFILCVT.DEF program in a particular case... Could get

FXFILCVT cannot presently support recompression of EXE files
which are self-decompressing. Nor am I sure it can, since not
all EXE files are compressed files. Automatically running just
any EXE file on the off chance it might decompress seems
hazardous at best...

- 164 -

FX-BBS Installation and User's Guide

Some compression programs programs do not support comments. Many
others allow comments, but only those that will fit on a single
line as arguments for the compression program. Some others
however (PKZIP for example) allow much much longer comments. In
the latter case, such comments cannot be made to fit on the
command line, but must be entered via the use of I/O redirection.
For decompressing and recompressing files, FXFILCVT directly runs
the compression programs in order to have a better chance of
getting a proper status returned from them. When the program is
run in this manner, I/O redirection is not possible. For the
addition of comments, FXFILCVT spawns a copy of COMMAND.COM (or
whatever you're using) so that this I/O redirection can be done.
However, in this particular case, the program's status cannot be
checked. For example, if the PKZIP program is being used and the
comments to be used are contained in a file called
C:\TEXT\COMMENT.TXT, FXFILCVT will execute the following command
line for the labeling function:


The contents of the COMMENT.TXT file could be several lines long
and affords SYSOPs with the opportunity to advertise their system
a bit, to anyone else who might receive the file at some point in
the future, provided of course, it has not been relabeled by
another SYSOP... I might create a comment file containing the
following for example:

º BerthaBoard º
º (209) 823-0093 1200/2400/9600+ HST º
º (209) 239-9853 1200/2400 º
º FidoNet 1:208/204 º

PKZIP seems to have minor problems getting the last line
completely in, so you may want to add a CR/LF or two for it, or
any other similar program. PKZIP also outputs the filename, as
might be expected, and in this case, for long comments such as
the above, a CR/LF should start the comment file as well...

- 165 -

FX-BBS Installation and User's Guide

Selecting IRQs, I/O Base Addresses and Other Hassles

Not to confuse you or anything, but FX-BBS does not really use
the concept of COM1, COM2 and so on much of the time. FX-BBS
does not use MS-DOS to communicate with the modem at all, when
communications optimization is nonzero, or when other than COM1
or COM2 is specified, or if the baud rate is higher than 9600.
MS-DOS can't handle any of these special cases. On the other
hand, when you've configured the program so that it does not use
communications optimization, uses default values for COM1 and/or
COM2, and communicates at 9600 baud or less, MS-DOS *will* be
used for initializing the modem, in the interest of compatibility
with some of the less compatible systems around.

Configuring the program then, is usually not simply a matter of
telling the program to use port 1, 2 or whatever. Rather, the
SYSOP is required to enter all of the various parameters required
to handle the modem without MS-DOS's assistance. While the
number of parameters listed on Screen A, and their description,
may seem forbidding, it's not really all that bad.

The Modem Port Number ranges in value from 1 to 8. This may be
thought of as corresponding to COM1, COM2, etc, but it is not
usually used for modem processing by FX-BBS. It's actual purpose
is to serve as an index into the various inter-node chat buffers,
and identifies a particular copy of the program that's running in
a multitasking environment on a single system (the system number
parameter on screen M also does this, but is used on a LAN wide
basis, while the one mentioned here is used on a single system
only). It must therefore be unique, but it has no other purpose,
save to help you keep track of which program is using which
modem. The remaining parameters more than make up for this

Each modem you use will be serviced by a UART chip. I've
forgotten what this really stands for. Something like Universal
Asynchronous Receive and Transmit processor... No matter. This
chip might be numbered 8250, 16450 or 16550, depending on your
particular setup. Other types exist, and some companies emulate
UARTs somehow or another. In any case, each of these chips
provides eight registers for use by the system, with many
registers having more than one purpose. For example, depending
on what you've previously told the modem, two registers may be
used to communicate the baud rate to the modem. One of these
registers however will at other times have a character in it
which has been received, and the other is where one places a
character to be transmitted. There are other registers used to
indicate the status of the line, the type of interrupt received
and allowing for other control functions to be enabled or
disabled. The 16550 uses one of the registers in a nonstandard
or at least different manner than the others.

- 166 -

FX-BBS Installation and User's Guide

These eight registers may be thought of in many ways as simply
being special memory locations. They must be assigned addresses
in memory (actually "port" addresses), though the choices offered
are restricted in many ways by the modem or serial card
manufacturer. Typically, the registers used by the modem and
referred to as COM1 will be at the hex memory address of 0x03F8,
while those used by COM2 will be located at 0x02F8. COM3 is
usually located at 0x03E8 and COM4 at 0x02E8. If you read your
modem's documentation, you can figure out the allowed addresses.
They are not always those that are mentioned here, and that
doesn't really matter. Usually the address area to be used can
be changed by setting a dip switch or jumper, or a pair of them.
Many modems do not support being configured as anything other
than COM1 or COM2. Set the address to be used as required. It's
probably a good idea to use one of the addresses listed above.
In any case, you MUST configure each modem to use a different
address range.

The IRQ Number parameter is used to indicate which interrupt you
wish the modem to be assigned to. You will also have to examine
your modem's documentation to determine the values it supports,
as well as change a dip switch or two. Often, the IRQ you will
select is also associated with the idea of COM1 and COM2, but
this is not strictly required by FX-BBS. The chip which
generally services these interrupts is the 8259 PIC (Programmable
Interrupt Counter). XT class computers support only eight
interrupts. These are:

IRQ 0: System Clock
IRQ 1: Keyboard
IRQ 2: Reserved
IRQ 3: Asynchronous Port 2
IRQ 4: Asynchronous Port 1
IRQ 5: Hard Disk Controller
IRQ 6: Floppy Disk Controller
IRQ 7: Parallel Printer

The lower the IRQ number, the higher that interrupt's priority.
If interrupts are pending on IRQ 4 and IRQ 3, interrupt 3 will be
processed before interrupt 4. IRQ 2 is generally labeled as
"reserved" in MS-DOS documentation. A more appropriate label,
for XT class computers and not ATs, is "spare". For ATs, it
truly is reserved. If your modem or serial board supports the
moving of the IRQ to be used (the Everex 2400 baud internal does,
at this writing), you can specify IRQ 2 for FX-BBS.

- 167 -

FX-BBS Installation and User's Guide

An XT class machine then might have three modems assigned as

Modem 1: COM1; I/O Address 0x03F8; IRQ 4
Modem 2: COM2; I/O Address 0x02F8; IRQ 3
Modem 3: COM3; I/O Address 0x03E8; IRQ 2
or: COM4; I/O Address 0x02E8; IRQ 2

Using these three modems in that manner would use all available
interrupts on the XT. A fourth modem might be used in the event
that no parallel port is being used. This is provided you have a
modem or serial board that can be assigned IRQ 7. In this event,
one of the two lines above relating to modem 3 would have its IRQ
changed to be 7, but the line would otherwise remain the same.
We're not really done talking about this (we still need to
discuss the 8259), so you XT users should keep reading. But I'm
going to discuss differences for AT computers now.

AT class systems have a second 8259 chip, so can handle up to 15
interrupts. The two 8259 chips are "daisy chained," and the
second 8259 generates an interrupt 2 on the first 8259, which is
why interrupt 2 is considered reserved. On an AT class system,
the interrupts are assigned as follows (they are listed in order
of priority, with 0 highest):

IRQ 0: System Clock
IRQ 1: Keyboard
IRQ 2: Second 8259... see following eight interrupts.
IRQ 8: Real-time Clock
IRQ 9: Software redirected to IRQ 2
IRQ 10: Reserved
IRQ 11: Reserved
IRQ 12: Reserved
IRQ 13: Math chip (80287)
IRQ 14: Hard Disk Controller
IRQ 15: Reserved
IRQ 3: Asynchronous Port 2
IRQ 4: Asynchronous Port 1
IRQ 5: Parallel Printer 2
IRQ 6: Floppy Disk Controller
IRQ 7: Parallel Printer 1

- 168 -

FX-BBS Installation and User's Guide

On most AT class systems, unless you've installed options, IRQs
3, 4, 5, 9, 10, 11, 12 and 15 will be available for other uses.
Optionally, it might be possible as well to employ IRQs 7 and 13
for servicing serial ports. Supporting more than four modems
then is simply a matter of finding modems or serial boards that
will allow selection of these interrupts for use, and which will
allow each serial port's UART registers to be assigned a unique
address. It does not matter to FX-BBS what IRQ or memory address
is used. If you have a hard disk controller that uses IRQ 4,
FX-BBS will be quite content to support IRQ 14 (the normal disk
controller interrupt) for use as a serial port. You only need to
find the appropriate hardware, hardware that allows the
appropriate settings to be made. But that may be no small task.
Sources for such are not covered here... Because they are

It should be noted here I suppose that when using IRQs of 8 and
above under the DesqView multitasking program, I found it
necessary to configure the window in which the program runs

slightly differently from the others. On the "Advanced Setup
Options" screen for the particular program being installed, one
can select the interrupts that DesqView is to swap out and
restore each time a particular program is being run. The default
range of interrupt vectors apparently conflicts with the use of
interrupt vectors of 70 and above. When using COM3, with IRQ 9
and interrupt vector 71, I found that the range of vectors to be
swapped had to be changed to 0 to 70, to allow 71 not to be
swapped. I do not know if this is required for other IRQs above
8, but it seems likely to be.

The Interrupt Vector parameter refers to the interrupt address to
be used when an interrupt is generated (this is different from
the I/O register address). Perhaps these parameters might be
dispensed with. That is, computed from other parameters
available. IBM chose to deviate from the Intel recommended usage
of interrupt vectors. In many case these addresses are NOT those
originally intended for use by Intel. They might differ on some
less than 100% compatible clones.

- 169 -

FX-BBS Installation and User's Guide

When an interrupt is generated by the serial device (or any other
for that matter), it will call a procedure whose address is
indicated in low memory on your system. FX-BBS must set the
address to be used, and this is why the information is required.
Use the following hexadecimal values for the appropriate

XT and AT computers:
IRQ 0: 0x08
IRQ 1: 0x09
IRQ 2: 0x0a (Do not use on AT)
IRQ 3: 0x0b
IRQ 4: 0x0c
IRQ 5: 0x0d
IRQ 6: 0x0e
IRQ 7: 0x0f

AT computers only:
IRQ 8: 0x70
IRQ 9: 0x71
IRQ 10: 0x72
IRQ 11: 0x73
IRQ 12: 0x74
IRQ 13: 0x75
IRQ 14: 0x76
IRQ 15: 0x77

Let me confuse you a bit more by trying to clarify those values
again... Each interrupt vector is four bytes in size. The first
two bytes contain the offset of the location in memory to jump to
when that interrupt occurs. The second pair of bytes contain the
segment of the location to jump to. I won't go into a
description of segments and offsets here... If FX-BBS is told to
use a vector of 0x71 (IRQ 9), it will place a pointer into the
appropriate locations in memory to indicate a routine within FX-
BBS which will take care of processing that interrupt. Since
each interrupt vector is four bytes wide, it will store the
required value, in this case, starting at address 0x1C3 (4 times
0x71, - 1), or decimal location 451 (I think... I didn't look
this up just now, but am operating from memory). If you used the
debug program in a multitasking environment to watch (dump) four
bytes of memory starting at this location, you would see that
before and after starting FX-BBS in another window, the values
stored there would be changed. When FX-BBS exits, it restores
whatever values were at these locations before it modified them.

- 170 -

FX-BBS Installation and User's Guide

XT users can begin paying attention again... We've (finally)
come to the Interrupt Mask parameter. This parameter is used to
program the 8259 to enable a particular interrupt to actually be
generated. FX-BBS assumes the primary 8259 to be located at hex
I/O address 0x20, and the second to be located at hex address
0xa0. The interrupt mask register of the 8259 is eight bits wide
and uses one bit for each interrupt. A bit value of 0 is used to
enable an interrupt, and a value of one is used to disable the
interrupt. Without going into too much detail, the bit position
of the interrupt you wish to enable should be a 0, and the rest
should be set to 1. The mask value entered will be ANDed with
the mask register, and then stored there.

Assuming then that you wish to enable IRQ 4, you would end up
with a bit mask of 11101111 binary. The right most bit
corresponds to interrupt 0, and the left most to interrupt 7.
FXBSETUP expects this value to be entered in hexadecimal however,
not binary, so it is necessary to convert this value to hex. If
you are not familiar with hexadecimal, then for the moment,
assume you have 16 fingers... The number '10' indicates 16
somethings, typically "numbered" 0,1,2,3,4,5,6,7,8,9,a,b,c,d,e
and f, due to lack of foresight on the part of the caveman in not
inventing numbers to accommodate hexadecimal. Consider a four
bit binary pattern. The range of values are as follows:

Binary: Hex: Binary: Hex:
0000 0x00 1000 0x08
0001 0x01 1001 0x09
0010 0x02 1010 0x0a
0011 0x03 1011 0x0b
0100 0x04 1100 0x0c
0101 0x05 1101 0x0d
0110 0x06 1110 0x0e
0111 0x07 1111 0x0f

Using this table, the value of 11101111 binary can be written for
our purposes as 1110 1111. Each half of the number can now be
looked up in the table to make the final hex value of 0xef.
Confused? Think about it a bit... And just to make you all the
worse off, here's a quick way to convert a binary value to
decimal: starting at the left side of a group of bits (8 or 16
or more), find the first nonzero bit. That's "1". Moving to the
right, as you go to each of the next bits, double your previous
value. If the bit you've just gone to is a zero, you're done
with that bit. If it is a one, add one to your total. When
you've done this for ALL bits to the right, you have the decimal
equivalent of the binary value. Want to convert decimal to hex?
Look it up...

- 171 -

FX-BBS Installation and User's Guide

One last thing... For AT users with a second 8259, you need only
concern yourself with the second 8259's interrupt mask value. To
enable IRQ 13 for example, you must first reduce it to an eight
bit value. Since the first 8259 services the first eight
interrupts, subtract eight. That leaves you with 5. We want
then to set all bits except the one corresponding to IRQ 5, which
is the fifth bit from the right. Our binary mask then, will be
11011111, or 1101 1111 if we want to look the two halves up in
the table. The first half, as you can see, is equal to a hex
value of 0x0d. The second half is equal to 0x0f. Putting the
two halves together then produces a mask value of 0xdf, the same
value as would be used to enable interrupt 5 on the first 8259.

Got it??? I hope so. Unless you live down the street, I can't
come and help with your installation of all these modems, and
it'll probably (usually is it seems) be a hardware mess. Should
you call, likely as not we'll simply be rehashing what's written
here... We can do that. It's your dime. I'm not sure much will
come of it though, and you might be better off staring down this
section of the documentation.

Can FX-BBS really really support eight modems? As you can see,
it can be configured to do so if you have the hardware resources.
An XT class machine however, will likely NOT have sufficient
power to drive more than two serial devices at a speed acceptable
to the callers, and maybe not even two... How many an AT class
system can drive with adequate speed remains to be seen. I don't
have enough hardware myself to try it. The faster the system
doing the processing, and the slower the modems being used, the
better the chance that they'll all go fast enough. Why is so
much power required? Because it is. If you look at other
multiuser BBS packages, they'll be handling it the same way, or
will require you to purchase a bit of expensive hardware to use
along with your current machine.

- 172 -

FX-BBS Installation and User's Guide

Security Issues:

It's a simple fact that there are BBS vandals around. FX-BBS has
a few features which are intended to help thwart such vandals.
However, the responsibility of watching for these folks remains
with you the SYSOP.

To start with, FX-BBS knows nothing about the paths it is to use
for operation in advance. You must provide these. FX-BBS also
never tells a caller anything about path names. For critical
files, FX-BBS does not know the file names it is to use until it
initializes itself. FX-BBS defaults to reading FX-BBS.CFG for
the configuration file, but this may be overridden. For example,
if you invoked the program with "FX-BBS A:\DATA", FX-BBS would
attempt to read the file specified for configuration information.

The FX-Shell program (along with others) allow for the Dos hidden
attribute to be set for a directory. This attribute has no
effect on whether FX-BBS (or you) can find the path, only on
whether DIR can display its name. This means that if you choose
rather odd and unpredictable names for your directories and then
hide them, no one will be able to see them should they be allowed
to get to a Dos prompt by yourself. If the directory cannot be
observed directly, it's rather difficult to do a DIR of it, isn't
it? Files can be hidden as well as directories, and again, this
has no effect on whether FX-BBS can use the files or not.

I also go to the point of not using a prompt command which would
show the current directory, and not keeping the FORMAT or DEBUG
commands on the system anywhere. The standard Dos COMMAND.COM
program can be modified to disallow the COPY, DIR, DEL, RD,
RMDIR, MD, MKDIR, PROMPT and ERASE commands if you're really
paranoid, as I have sometimes been. This is why you are allowed
to specify a different program name for use with the ALT-F2 key.
Be advised though, that keeping multiple and different versions
of COMMAND.COM, with different names, can be a pain in the rear.
The second different one can sometimes result in the message
"unable to load COMMAND.COM aborted" being output after certain
programs are run. Not fatal, but requires the second COMMAND.COM
be restarted manually. Nor do I use a PATH command. And of
course, I back up the hard drives very regularly, just to be

I should note however, that I have never had any problems with
attempted break-ins, at least, not to my knowledge. FX-BBS has
never "accidentally" given anyone access to a system, though
there's a first time for everything. A SYSOP in Southern
California seemed to constantly have problems with his hard
drives being accidentally formatted in the middle of the night.
He used both Opus and PCBoard at different times (FX-BBS did not
at that time exist). He no longer runs his system. I don't
think he ever learned if the cause of the problem was a co-SYSOP,
a caller breaking in, a trojan or what. Just something to think

- 173 -

FX-BBS Installation and User's Guide

Business Considerations:

Business users, along with some others, may have two requirements
that differ from most users. These include first, the likelihood
of needing to keep certain files absolutely private to a given
group of persons, and second, record keeping to justify the use
of the BBS economically.

For FX-BBS, files may be made absolutely private in only one way
at the present time. This is by placing the files into a
completely separate conference file area, and then to make that
conference private. Users wishing to access these files will be
able to do so only if they know the password to that conference.
When a user selects the [F]iles option from the main menu, they
can see only those directory descriptions which you choose to
describe in the file DIR0 (that is, they will only know that file
area 73 exists if you tell them it exists, and will only know
what's in that area if you describe its contents in the file
DIR0). Private file areas should then not be described there.

Conference members will be provided additional information
however. In addition to the DIR0 file, they are provided a brief
mention of the directory area for each particular conference they
belong to. If such a conference file area is for example, "65",
callers belonging to that conference will be able to select file
area 65 for viewing as they would for any other area. Non-
conference members who might enter the same value of "65" as the
area to be viewed will be presented with the recent uploads file
instead. In this case, there is no indication provided to them
that the conference area even exists.

While this works in a foolproof manner for files already existing
on a particular system (most often the files of concern),
uploaded files must be dealt with differently. These files
cannot be made 100% private at the current time unless ALL
uploads are made private. All newly uploaded files are placed
into the common upload directory, which may be made private or
not, on an all or nothing basis. A "middle option" also exists
however, which may be used or not as the SYSOP sees fit. Uploads
may be made generally accessible by the public, with newly
uploaded and private files designated as private by the
contributor. When this is done, the file is simply hidden from
view for all callers with an access level below assistant SYSOP
(9). The names of files made private in this manner are not
displayed for callers, nor are the descriptions of such files
when the recently uploaded file list is viewed. None the less,
should a caller be a creative guesser and enter the right name,
on purpose or by accident, they would be able to access these
files. The choice of allowing this possibility to occur or not
remains with the SYSOP.

- 174 -

FX-BBS Installation and User's Guide

Regarding the issue of record keeping, different methods are
possible, though none are provided which are aimed specifically
at the business user. Categories of information one might find
useful and how the information can be gathered include the

1. User records do not presently contain a caller's address or
telephone number. It is possible that I will add this feature
shortly (it *is* under serious consideration). This addition
however, will impact all users of the program, and is only a
halfway good idea anyway, since callers can falsify such
information and it is difficult to automatically verify
accuracy. For the moment in any case, this information must
be collected differently. The recommended method is to create
a questionnaire which asks for whatever information you might
wish to collect. If you must be very strict about gathering
such information, callers should be denied access to the
system until such time as the questionnaire has been answered.
Telephone numbers may be verified by calling the user in
question (perhaps collect). Addresses may be verified by
requiring that callers send a self addressed stamped envelope
to you so that you can write a new password on it and send it
back. I've seen one system which goes so far as to require
callers wishing access to send a photocopy of their driver's
license or a voided check (I chose not to send either
however... since the requests seemed a bit more than
justified and the information potentially hazardous somehow or
another). These are just ideas, for your consideration.

2. Call history information is kept in a file called FX-
BBS.LOG. Each entry in this file has the following format:

struct {
char who[30]; /* 30 characters for caller name */
char when[30]; /* 30 characters specifying the date, */
/* day and time of the call. Format: */
/* Day Mon DT HH:MM:SS YEAR */
char done[30]; /* date field for when caller logged off */
char baud[10]; /* baud rate specification */
char where[20];/* City/State caller called from */
} log_rec;

The last parameter is obtained from the caller's record in the
user file. It is not guaranteed to be accurate. For the FX-
BBS.LOG file, it should be remembered that the file is self
regulating in size. That is, if the file is determined to
have grown too large, FX-BBS will delete the oldest portion of
the file. Periodically then, this file should be copied to
another directory, or to floppy diskette. Its maximum
capacity is 1600 records or so (192,000 bytes). When the file
reaches this size, it will be reduced to 800 records or so
(96,000 bytes). The file is continuously added to and is used
by two of the statistics functions (main menu option "%"). It

- 175 -

FX-BBS Installation and User's Guide

should therefore not be deleted without thought. On the other
hand, if the file is not deleted each week, different copies
you might make of it will possibly overlap from week to week.

No specific tools for listing or editing this file are
provided, but should not be difficult to construct. Each
record of the file contains plain ASCII text. Each field of
each record is a 0 terminated string with the first
significant character stored in byte 0 of the field's area.
No carriage return or line feed is provided at the end of each
record. The file is built in chronological order, that is,
added to at the end following each call. Should you wish it
sorted in some other manner but do not wish to write a program
to perform this task, it should be sortable using the DOS sort

3. Should you impose an access fee, parameters exist in the
caller's record to allow entry of a subscription expiration
date. These parameters must be filled in using the EDITUSER
program and are used by FX-BBS to determine whether or not a
caller is provided access to the system or not. Refer to the
EDITUSER program and the access level screen for the FXBSETUP
program for additional information.

- 176 -

FX-BBS Installation and User's Guide

Utility Programs:

Several utility programs are included here, with more expected to
be added as they are completed. All anticipated utility programs
are described here. Some of these utility programs may be
available in some form or another in the public domain. Versions
of the program described here however, are written expressly for
use with FX-BBS. They are not always distributed with copies of
FX-BBS on other bulletin board systems, but are available on
Bertha Board and are included when FX-BBS is registered.

CHMOD - The Chmod program allows you to change file attributes.
This might be useful for example, to make all files associated
with a particular conference invisible, by setting the hidden
attribute, to un-hide several files at once by using wild cards
and resetting the hidden attribute, to protect certain files by
making them read-only, or to make certain files un-executable, by
setting the system attribute.

You will recall that files which are uploaded and intended to be
private for the SYSOP simply have the hidden attribute set,
making them invisible to the [L]ist New files and [W]hereis
functions. Chmod can assist you then in making these files

For instructions on using the Chmod program, simply type the
program name (that is, run it). The CHMOD program was compiled
using Turbo Pascal 5.5.

FILEDATE - This program is provided to assist in assuring that
file dates are correct. This is important since the dates DOS
provides for files are used to determine whether files are "new"
when a caller asks to list "new" files. The dates of the files
are compared to the date the caller last called, and if more
recent, the file is assumed to be new. Again, simply run the
program for instructions on how it should be used. If you omit
the date and time fields, the file(s) in question will be set to
the current date and time. Otherwise, the date and/or time
specified will be used. This program was compiled using Turbo
Pascal 5.5.

- 177 -

FX-BBS Installation and User's Guide

MOVE - This program allows for files to be moved from one sub-
directory to another, or even to a different drive. Note that
when a file is simply moved from one subdirectory to another on
the same drive, only the filename is moved. The file itself is
NOT moved. When a file is moved to another drive, the file is
first copied to that drive and then the file is deleted on the
original drive. This program is spawned by the BBS program's
"Install File" function, selectman from the SYSOP maintenance
menu. In order for Install to function properly, MOVE *must* be
located in the primary FX-BBS subdirectory.

The move program cannot make subdirectories. That is, the
destination subdirectory must already exist. For instructions on
using the program, simply run it. Move also cannot move sub-
directories. Attempting this will produce an error. The MOVE
program was written using Turbo Pascal 5.5.

FXBFETCH - This program is provided to allow for BBS system file
access from within doors. Specifically, it was written to feed
the PKXARC program. This program is not included with the FX-BBS
primary arc file, and must be obtained separately. If you cannot
find it, it will be available on Bertha Board... FXBFETCH was
compiled using Turbo C version 1.5. It has not been recompiled
using the newer version of Turbo C as yet. CTRL-C is disabled by
the FXBFETCH program.

FX and D programs - Sorted directory programs. Run the program
with "FX ?" for instructions. FX is a very old program,
originally compiled using Ecosoft's ECO-C compiler, then
Datalight's C, and finally, Turbo C version 1.0. It includes a
small amount of assembly code compiled with MASM. It has not
been changed in some time, though needs to have a bug corrected
which causes the program to not display things as well as it
might when a directory is found to be empty. The "D" program is
a newer experiment, not quite right as yet I suppose, which
displays a similar directory listing. It is written in Turbo
Pascal. While it has a few good points, I think I prefer FX.

FINDFILE - Searches all subdirectories of a specific drive,
starting with a specified directory. To search for all arc files,
you would enter FINDFILE \*.ARC. To start the search in the
D:=FILES subdirectory, enter FINDFILE D:\FILES\*.ARC. FINDFILE
was originally written using Ecosoft's ECO-C compiler. It is
presently compiled using Turbo C version 1.5.

- 178 -

FX-BBS Installation and User's Guide

FILESET - This is another door utility program, compiled using
Turbo C version 2.0. This program solicits a file name from the
caller and then searches all download file paths for that file
name, using the configuration file specified to determine which
paths are to be searched. If the file is found, the program sets
*a previously existing* DOS environment variable to represent the
complete path and name of the file. The program uses some rather
screwball techniques to set *all* copies of the environment
variable it can find in the system to the specified file name...
It may or may not find them all. Run the program with no options
to view a help screen. It is necessary to use I/O redirection
with the FILESET program. CTRL-C is disabled by the FILESET

INPUTSET - This program is also compiled using Turbo C version
2.0, and is similar to the FILESET program. It differs in that
it does not search for any particular file names, but rather
simply sets a previously existing environment variable to a
string entered by the caller. Again, the program attempts to set
all copies of the environment variable it can find using the same
weird techniques employed by FILESET. The environment variables
may be passed to other programs from within a batch file. It is
necessary to use I/O redirection with the INPUTSET program.
CTRL-C is disabled by the INPUTSET program.

ASK - Ask was originally written using the Ecosoft ECO-C
compiler, and is presently compiled with the Turbo C 2.0
compiler. It is used to ask the caller a single character
question from within a batch file. The question asked can take
the form of a Yes/No question, numeric input from 0 to 9, or an
alpha character from A to Z. The DOS variable ERRORLEVEL is set
to indicate the caller's response. Unlike the FILESET and
INPUTSET programs, the ASK program will also display a prompt for
the caller. Run the program with no options for further
information. As with FILESET and INPUTSET, the program must be
run using I/O redirection. CTRL-C is disabled by the ASK
program, but it does recognize multitaskers, and gives up all
time possible while waiting for a caller to make an input.

- 179 -

FX-BBS Installation and User's Guide

FXCOMM and FXCOMML - These programs are both TSRs serving similar
purposes. Both attach themselves to interrupt 14 and assume a
function number of 0xfd (253). The FXCOMM program occupies
approximately 2Kbytes of memory, while the FXCOMML program
occupies considerably more. Both programs provide nothing more
than common data buffers for use by all copies of FX-BBS which
might be running.

By default, FX-BBS uses a portion of screen RAM (what may be
thought of as line 26 of the screen) for communicating with
several different copies of itself running on a single system.
The works well, provided the monitor in use has such memory (some
do not). EGA and VGA displays are equipped with such memory, but
also allow the user to actually display data on the 26th line.
Some CGA displays, while allowing FX-BBS to use the 26th line,
exhibit excessive snow when FX-BBS does so. In each of these
situations, the FXCOMM TSR should be used. It should be loaded
*before* starting your multitasking program. When FXCOMM is
loaded, FX-BBS can use an area of memory within the TSR to
replace the screen RAM it ordinarily would use.

The FXCOMML program also performs this replacement, but goes
further in that it provides buffers for use in supporting LAN
chatting among callers. All copies of FX-BBS must use the same
buffers and coordinate between each other regarding data
contained there. The reason for this is simply that LAN cards
(or rather the NetBIOS drivers) are not usually prepared to have
multiple programs talking to it, nor to have its memory buffers
swapped out of main memory and something else swapped in in their
place (crashes the system rather badly). One restriction comes
with this program which has been mentioned before and bears
mentioning again: FXCOMML intercepts ALL *datagram* processing
on a given LAN and attempts to process it (it assumes the LAN is
there primarily for its use/support). It is conceivable that it
might make such traffic available to callers during inter-system
chat sessions. If this is a problem, do not allow inter-system
LAN chat traffic of any sort. This program was written with
Turbo-C version 2.0.

FXCNFCFG - While all copies of FX-BBS running on a given system
share in datagram processing, no one copy of the program can
initialize or de-initialize the network as required. No one copy
of the program can assume such authority! Initializing the
datagram processing while another program was performing such
would at the very least be hazardous to that particular chat
session. The sole purpose of the FXCNFCFG ("FX-BBS Conference
Configuration") program is to perform LAN datagram initialization
and de-initialization. The program requires one of two command
line parameters: Specifying "START" will cause the program to
initialize the system for datagram processing. Specifying the
"STOP" parameter will cause the program to turn OFF all LAN
datagram processing. This program was written with Turbo- 2.0.

- 180 -

FX-BBS Installation and User's Guide

KEYCODES - A simple program which when run, displays the byte
value codes generated by your system when a particular key is
depressed. The purpose of this program is to assist in
generating strings to be assigned to function keys (refer to
Screen O). I think it was written in C.

FXUSRINF - Another short little program written in C, this
program reads FXINFOxx.INF files and outputs a "userinfo.txt"
kind of file as required for some door programs, notably those
from Milton Gameworks (specifically, Planet Busters). Invoke the
program as follows:


where xx in the file FXINFOxx.TXT is the two digit number for the
info file to be converted, and USERINFO.TXT is whatever output
filename you've configured the door in question to expect.

- 181 -

FX-BBS Installation and User's Guide


That's really about it. While this documentation is pretty
large, I realize that it remains in some ways, inadequate. I'm
thinking about writing a second document which will describe what
the programs do from a flow standpoint, and a third which would
be a caller user's manual, but don't hold your breath. So set up
the program and run it, and welcome to the world of SYSOPing.
Pointers? Not too many, but here's a few, mostly related to
SYSOPing. Have fun.

Remember to be polite. You may be grinning as you type the joke
about Italians, but the other person may not get it, or might be
Italian. The point is, humor comes across very flatly on a
computer screen, especially when applied to someone you don't
know too well.

Remember to back up your files often, and don't forget to backup
the "hidden" files as well. Files can go away. Your system will
be in heavy use. After a year or so, your power supply might not
be as great as it once was, or your hard disks might be a bit
tired. Disk controllers CAN become confused sometimes,
especially when heavy fragmentation occurs over the course of
several months.

Remember to keep your upload directory cleaned out. A few files
are OK, but when you get 40 or 50 in there, it takes a long time
to read to see what's new, and a long time to clean the sucker
out again (you DO TEST those new uploads, don't you?), after
which time, you'll want to backup the computer again so in the
event of a crash, you don't have to clean out that upload
directory again...

Test new programs sent to you. They might be Trojans or Viruses
and you wouldn't want your callers to get hold of them. Then
too, you wouldn't want to get hold of them either. What's a
SYSOP to do? Many programs are available which will check a
program to see if it's a trojan before it's run, and others are
available to prevent any hard disk writes. Get them. Use them.

You really should have a clock/calendar card in your system.
Failing that, you must enter the correct date/time each time you
reboot. FX-BBS depends on having the correct date and time when
checking for when a caller last called (important in determining
whether new messages, files or bulletins are available), and for
determining how much time a caller has left.

Remember too, that if you have problems or suggestions, I can
always be reached on BerthaBoard, (209) 239-9853, 1200/2400.

- 182 -

FX-BBS Installation and User's Guide

Restrictions, Known Bugs, Program Hints, Etc:

1. Welcome files, directory files and so forth which contain ANSI
escape sequences may not always be displayed correctly on the
local screen (they will be displayed correctly on the remote
screen however). This is because cursor commands may be
encountered within the file which will cause ANSI.SYS to position
the cursor into the local status area at the bottom of the
screen, or which attempt to display more information on a screen
than will fit in the available screen area. When FX-BBS
determines that this has happened, it will correct for the
problem by positioning the cursor on the last line above the
status area and then scrolling the screen upwards one line. The
effect is that some menus may be output with lines that appear
broken on the local screen. Again, the remote caller does not
see this effect, and it does not happen often on the local
screen. If it bothers you, try redesigning the menu so that the
effect is not produced. I've found it helpful to remove all ANSI
commands in a menu after the final character of actually visible

2. If, when External protocols are being used, files received are
placed into subdirectories other than the standard upload
directory specified, the file will be properly received, but the
FX-BBS program will be unable to determine the file size.

3. The SYSOP install function will not work properly if the MOVE
program is not in the FX-BBS path, or if there is less than about
70Kbytes of memory available for MOVE to run in (the amount of
memory shown in status display at the bottom of the screen plus
the greater of either 8500 or the number of lines you allow for
messages times 82 bytes per line, should be greater than the
70Kbytes required by the MOVE program). The Install function is
also the program most dependent on finding a colon between the
directory text file header and the descriptions which follow it.

4. Callers who enter CTRL-C on certain menus may see things
occurring slightly differently from yourself when communication
optimization is set to greater than one. This is because your
screen will often be processing more rapidly than theirs. When
CTRL-C is depressed, FX-BBS will purge its transmit buffer.

5. Be certain that your modem supports CTS and DTR properly.
Generally, the "&D2" and "&C1" parameters should not be omitted,
unless your modem supports these functions via dip switches, or
some other mechanism.

- 183 -

FX-BBS Installation and User's Guide

6. Your local screen will be updated sporadically when
communications optimization is set to "2" or greater. THIS IS
caller does not see this effect. It is caused by the program
running as fast as it can to fill its transmit buffer and then
stopping until the buffer has been substantially emptied.

7. FX-BBS will attempt to set the baud rate the first time it
initializes the modem. FX-BBS will also do the same each time a
caller connects or disconnects, unless you have specified that
the baud rate is to be locked (you are using your modem at a
speed of 9600 baud or greater). If you have specified that the
baud rate is locked, FX-BBS will initialize the serial port's
baud rate only once. FX-BBS does not automatically issue the
modem's "locked baud rate" command. You must either do this when
you configure the modem (prior to using FX-BBS), or include it in
the modem initialization string.

8. FX-BBS passes the CALLER'S baud rate to door and external
protocol programs. If you have the baud rate locked at 19200 and
a caller is connected at 2400, the external programs will be told
2400. In these cases, you must "front end" the external program
with a batch file specifying the appropriate 19200 or 38400 baud

9. Fossil drivers such as X00.SYS and OPUS_COM may be required
for use with programs such as BinkleyTerm and others. FX-BBS
does not provide any Fossil compatible code for use by these
programs! FX-BBS also does not itself require such a driver, nor
does it preclude the use of such. While this may mean lesser
compatibility with some rare systems, it also means that FX-BBS
is not dependent on such programs. FX-BBS ignores interrupt 14
completely, and talks directly to the hardware. No problems have
been encountered thus far with available Fossil drivers.

10. You must have memory partitions (or windows) in the
DoubleDOS and DesqView environments configured to be capable of
running in background when using FX-BBS. DesqView in particular
has several parameters which can effect whether all copies of the
program will run all the time. Refer to the discussion of
multitasking considerations for more information on these.

- 184 -

FX-BBS Installation and User's Guide

11. FX-BBS may or may not be compatible with this or that door.
A "front end" program may be required to convert information
output by FX-BBS to a format compatible with various door
programs (like the FXUSRINF program, only perhaps different as
dictated by the door in question). There is it seems, no real
standard for the format of door parameter files, in spite of the
fact that someone claims to have written such (for RBBS). If you
have a particular format you'd like to see supported, please let
me know by leaving a comment or message on BerthaBoard.

12. Many doors are authored by many people. Door programs are of
varying quality, and are written in various languages which may
or may not be really suited to the task. No guarantees
whatsoever are made regarding whether FX-BBS will execute a
particular door or external protocol program properly or at all,
nor how FX-BBS will perform once an external program has been
executed, since such a program has the potential of modifying the
system in some low level way. Door programs are expected to be
"polite" as well. FX-BBS won't argue with a door program over
which program is going to control the UART and com port. If your
particular door program insists on arguing (that is, it cannot be
spawned successfully), you should configure it as a door to be
exited to.

13. Inter-node chat capabilities, by default, depend on memory
being available at the end of screen memory (what might be
thought of as screen line 26). This is required primarily
because DesqView uses the inter-program communications buffer
located in memory page 0. Inter-node chatting will not function
properly on systems with monitors which do not have memory in the
area mentioned, such as older IBM monochrome monitors, or when
EGA/VGA monitors are configured for 43/50 line screen display
modes unless the FXCOMM TSR program is used.

14. Excessively large HISTORY.DNL files can cause delays after
downloads as the program searches the file for matching file
names. Because of this problem, no optimization is performed for
I/O with this file. Should you observe excessive delays relating
to this file, you should consider editing it to remove rarely
downloaded file names.

15. You cannot place a colon (":") in the header area of the
directory text files you generate. Remember, a colon is used as
an indicator of where to install a new file listing by FX-BBS. If
you place a colon in the header area, you will cause file
descriptions to be placed within the header area. Colons should
be placed in column 1 following the header.

- 185 -

FX-BBS Installation and User's Guide

16. On at least one system, it was found to be necessary to add a
delay to DesqView's start-up script to prevent multiple copies of
the program from firing up at the same time. Why this is
required on one particular system is presently unknown. If you
should experience difficulty with the program, you might try this
(look at the DesqView "learn" menu to see how to introduce a

17. Direct screen writes are not performed in all instances, even
if direct screen writes are requested. While a caller is online,
characters output which they might receive at their system are
output using the bios. Data displayed which they would not see
(the status area primarily) will be output using direct screen
writes however (if enabled).

18. Remember that increasing the maximum number of lines a caller
can enter in a message above 99 cause FX-BBS to use additional
memory, though this memory is returned to the system for use by
doors or external file transfer programs. Refer to documentation
for configuration program Screen D processing for more

20. Specifying a communications optimization value (configuration
program Screen L) of greater than 0 improves processing speed for
callers, but also causes the system to use more memory. This
memory is NOT returned to the system for use by doors or external
file transfer programs. While you should generally specify a
nonzero value for communications optimization if your modem
supports this, the larger the value, the more memory required.
On my system, I specify a value of 2-4 usually for a 2400 baud
modem, and of 6 (establishes an 8192 byte transmit ring buffer)
for the 9600 baud HST modem. Refer to the description of Screen
L for more information.

21. If your modem doesn't respond, make certain that your modem
supports the ampersand commands. If it does not, including the
ampersand commands in the modem initialization string may confuse
it. The ampersand commands are used on some modems to take the
place of dip switches. If your modem does not support ampersand
commands, it will likely have dip switches requiring some
manipulation. Refer to the setup program description, Screen A
for more information. Refer as well to the section concerning
your choice of IRQ, I/O addresses and so on.

- 186 -

FX-BBS Installation and User's Guide

22. If you take it upon yourself to remove the "&F" command from
the modem initialization string, and out of the blue one day,
your modem suddenly begins to act differently, you might consider
first the possibility that your modem has forgotten all or a
portion of the initialization information you've stored within
it... I've included the &F command in the init string for a
reason: It seems to be a rather common occurrence for some (but
not all) modems to forget what you've told them.

23. The overlay version of the program employs 31 separate
overlays. The primary intent of developing the overlay module is
to decrease memory used, so the software is structured primarily
with that goal in mind. To help give you an idea of what's
happening when you run the overlay version, files that make up
FX-BBS are listed below. As you examine the list and associated
processing, imagine the path that the program follows when a
caller logs on. Each time a different overlay area is entered,
the previous one is overwritten as the new one is loaded from
disk... It certainly would seem that this can have an effect on
performance, and this is indeed the case. The program is best
run from a ram disk. If this is not possible, it still should
provide acceptable performance if you've a reasonable hard drive
formatted for optimum interleave (don't trust the manufacturer's
recommendations - test it!) and enough buffers allocated in your

Library Modules (not overlayable):
1. emu - C Language floating point emulation library.

2. mathl - C math functions.
3. cl - Main C library module.
4. tclib2l - My own library for menuing and screen
functions, etc.

Non-overlayed Modules:
1. c0L - C language start up code (part of compiler).
2. fxbbs - Primary module; some mail functions, data
3. fxbbsio - Keyboard and screen interface functions.
4. fxbbscom - Modem service functions.
5. fxbbsmlt - multitasker interface and init.
6. fxbbssd - Status display functions.
7. fxbbsmsp - Non-overlayed mail support functions.

Overlay Modules:
1. fxbbscnf - Conference support.
2. fxbbsstt - Statistics overlay (Main menu '%' command).
3. fxbbssmf - Misc. small overlayable functions.
4. fxbbsman - Main module from processing standpoint.
5. fxbbsmnu - Menu file output, command line processing,
6. fxbbsntr - Message entry module.
7. fxbbslgn - Caller logon functions.
8. fxbbsdir - Caller viewable directory processing.

- 187 -

FX-BBS Installation and User's Guide

9. fxbbswat - Watch for caller to call...
10. fxbbscfg - Configuration file processing.
11. fxbbssop - Sysop menu functions.
12. fxbbsarc - Compressed file listing functions.
13. fxbbsbul - Bulletin functions, get comment logic.
14. fxbbsdor - Door processing.
15. fxbbsrst - Modem reset, STATS.BBS maintanance gizmos.
16. fxbbsmal - Part of mail processing (message reading).
17. fxbbsmsg - Part of mail processing (overlayed support
18. fxbbscht - Chat support functions.
19. fxbbsfil - Primary file transfer support.
20. fxbbsupl - File upload entry functions.
21. fxbbsdnl - File download entry functions.
22. fxbbstrm - Main terminal mode loop.
23. fxbbstr1 - Terminal mode file transfer entry functions.
Interfaces with other FXBBSxxx file modules.
24. fxbbstr2 - More terminal support functions.
25. fxbbslan - Local Area Network specific processing.
26. fxbbssys - System level (low-level directory searching)
27. fxbbsedt - Most of the logic associated with full screen
28. fxbbsed2 - Block operators for full screen editor, prep
29. fxbbs99 - Functions relating to listing and maintaining
the upload description file.
30. fxbbsems - Data allocation and initialization module.
31. fxbbsslk - Sealink support.

24. When using IRQs above 8 (using the second 8259) under the
DesqView program, I found it necessary to change the default
range of interrupts processed by DesqView for each window to a
range of 0 through 70 (by default, the range is 0 to 0xFF).
Specifically, this was required when I used IRQ 9, with interrupt
vector 0x71. I do not have the hardware required to support
other IRQs above 8 and so do not know if this would be required
for other IRQs.

25. When using the terminal mode supported by FX-BBS, be certain
that your terminal mode modem initialization string includes the
proper carrier detect commands (typically "&D2&C1"), or that your
modem dip switches are properly set. The terminal program uses
detection of carrier as an indication that the other system has
answered. It does NOT examine connect strings or flags returned
by the modem.

- 188 -

FX-BBS Installation and User's Guide

26. FX-BBS cannot operate properly if the status display area
states that there is 0Kb memory free. It may not work properly
if only 1 or 2Kb is free either. The problem here is that when
searching subdirectories for files, FX-BBS repeatedly makes
requests for small amounts of memory from Dos until the process
is completed. If you do a "whereis *.*" and examine the display
a screenful at a time, you may well be able to see the amount of
free memory vary when the pause for each screenful occurs. At
the present time, the program continues to run whether it can
allocate the required memory or not. If it runs out of memory,
or has less memory than required, either no file names will be
found and displayed, or only a partial list will be. This would
hold true as well for files being downloaded, and during the
search for matching files during upload processing. On my own
system, 20Kb seems to be a good minimum figure to allow. If you
are anticipating allowing very little memory in a partition, you
should test processing by doing a whereis *.* and making sure the
program never runs out of memory. Should this be a real problem
for you, that is, should you absolutely have to run with minimum
memory and are running out of such, you can decrease the amount
of memory required by placing more files in more subdirectories
nearing the root search path, as opposed to lots of files in a
few subdirectories which are heavily nested.

27. Should you notice that external protocol or game programs are
slowing down the system noticeably, you might want to try running
the TAME program with the program in question. TAME is a TSR and
essentially runs interference when the program checks the
keyboard for input. Most of the time, the program receives
inputs from the COM port, so needn't spend a great deal of time
looking at the keyboard.

When running TAME, I found that I achieved best results by
starting the TSR from within the batch file spawned by FX-BBS.
For example, consider the following batch file fragment:

rem Start TAME TSR:
DSZ CON port %1 sz @%3
rem remove TAME TSR from memory:

TAME itself represents only 2-3Kb of memory overhead. Since TAME
can be removed from memory, it's ok to run it in a batch file.
Indeed, when run from a batch file, you must be certain to remove
it from memory!

As mentioned elsewhere however, it is possible for unregistered
versions of Tame to delay long enough when exited to allow one
caller to hangup and another caller to call in. If their baud
rates match, the second caller will find her/himself in the
middle of the previous caller's session. Use caution!

- 189 -

FX-BBS Installation and User's Guide

FX-BBS Configuration File Default Values:

The configuration file is stored as ASCII text. Default values
used for initialization are shown here. C Escape characters have
been removed, and the C comments (text between "/*" and "*/")
have been shortened to end by column 65. Note that the comments
are NOT written to the configuration file. The file has a
somewhat disjointed appearance due to addition and deletion of
parameters over time as enhancements have been made. As old lines
were removed from usage, they were reused for other purposes.
While the file could certainly be organized to look better, the
programs don't really care... And if it ain't broke...

You *could* edit this file with a standard text editor, though
this is *not* recommended. The information is made available
here so that you can check the file should you suspect that you
have a problem.

Should you attempt to edit the file with a text editor, be
certain not to make a given line longer than the configuration
program itself would allow it to be (35 characters). Doing so
may cause areas of the FX-BBS program to be overwritten when the
configuration file is loaded. In some respects, it seems the
following information may be thought of as sufficient rope...

- 190 -

FX-BBS Installation and User's Guide

{"0"}, /* line 0 is address for array buffer */
{"0"}, /* line 1 is address for async receive bfr */
{"0"}, /* line 2 is address for async transmit bfr*/
{"0"}, /* line 4 is multi-tasking flag. */
{"D:\FILES\"}, /* line 4 contains root search path nbr 2 */
{"0"}, /* line 5 hour nbr for auto exit 0-ignored */
{"90"}, /* line 6 wait time for xfr to start(secs) */
{"1"}, /* line 7 is 1 for LPT1, 2 for LPT2 */
{"0"}, /* line 8 is nbr of external xfr protocols */
{"ATS0=0HM"}, /* line 9 is modem onhook string. */
{"1"}, /* line 10 = access lvl for new callers if */
/* greater than 1. Else new user lvl == 1. */
{"C:\COMMAND"}, /* Line 11 is path & name of ALT-F2 prgm */
/* to use for F2 */
{"ATH1M"}, /* line 12 is modem offhook string. */
/* following 3 lines spec ANSI color strngs*/
/* used here and there by FX-BBS */
{"31-1"}, /* line 13 is dir color 1-first 15 chars */
/* of dir line */
{"32"}, /* line 14 is dir color 2 16 - 23 of a dir */
/* line */
{"36"}, /* line 15 is dir color 3 24 - 80 of a dir */
/* line */
{"A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,"}, /*line 16 1st part*/
/* of cmd line */
{"0"}, /* line 17 tim lmt in min fr 300 baud-0=N/A*/
{"99"}, /* line 18 is max allowed msg lines (<= 99)*/
{"45"}, /* line 19 = time limit in min (lev 1) */
{"75"}, /* line 20 = time limit (lev 2) */
{"90"}, /* line 21 = time limit (lev 3) */
{"120"}, /* line 22 = time limit (lev 4) */
{"150"}, /* line 23 = time limit (lev 5) */
{"180"}, /* line 24 = time limit (lev 6) */
{"210"}, /* line 25 = time limit (lev 7) */
{"240"}, /* line 26 = time limit (lev 8) */
{"0"}, /* line 27 = time limit (lev 9) */
{"280"}, /* line 28 = time limit (lev10) */
{"N"}, /* line 29 is closed system flag. */
{"N"}, /* line 30 is default for SYSOP avail. */
{"N"}, /* line 31 is default for print on. */
{"Y"}, /* line 32 is log file on flag. */
{"R,S,T,U,V,W,X,Y,!,#,$,%,^,>"}, /* line 33 2nd prt cmd line */
{"Y"}, /* line 34 is minimum baud rate flag. */
{"2"}, /* line 35 is for COM port */
{"N"}, /* line 36 = flag for runing w/frontend prg*/
{"2400"}, /* line 37 is maximum baud rate modem sprts*/
{"Leave a comment for the SYSOP (Y/N)?"},/* Line 38 prompt to */
/* display when the user says good-bye */
{"01"}, /* line 39 is nbr of mail sections <= 40 */
{"General Mail"}, /* line 40 is name of mail section 1 */
{"NONE"}, /* line 41 is name of mail section 2 */
{"NONE"}, /* line 42 is name of mail section 3 */
{"NONE"}, /* line 43 is name of mail section 4 */
{"NONE"}, /* line 44 is name of mail section 5 */
{"NONE"}, /* line 45 is name of mail section 6 */

- 191 -

FX-BBS Installation and User's Guide

{"NONE"}, /* line 46 is name of mail section 7 */
{"NONE"}, /* line 47 is name of mail section 8 */
{"NONE"}, /* line 48 is name of mail section 9 */
{"NONE"}, /* line 49 is name of mail section 10 */
{"AT&FS0=1S2=255V1X1&D2&C1&T5E1Q0"}, /* line 50 modem init str*/
{"C:\FX-BBS\"}, /* line 51 is path for general bbs files */
{""}, /* line 52 is name of user description file*/
{"0"}, /* line 53 is dly time for blanking screen */
{"C:\FX-BBS\GRAPH\"},/* line 54 is graphics text path */
{"18"}, /* line 55 is number of directory files, */
/* excluding DIR0! */
{"D:\FILES\UPLOADS\"},/* line 56 is path for uploads */
{"C:\FX-BBS\HELP\"}, /* line 57 is path to help files */
{"180"}, /* line 58 is # seconds to wait with no */
/* activity before hanging up. */
{"NONE"}, /* line 59 is root search path #3. */
{"NONE"}, /* line 60 is root search path #4. */
{"Y"}, /* line 61 specs whether new uplods are */
/* immediately made public. */
{"0"}, /* line 62 is nbr of conferences available */
{"0"}, /* line 63 maximum door number allowed */
{"FX-BBS Bulletin Board"},/* line 64 contains the name of BBS */
{"Y"}, /* line 65 indicates whether direct screen */
/* writes are performed */
{"PASSWORD"}, /* line 66 is password to FX-Shell. */
{"Graffiti"}, /* line 67 is name of mail section 11 */
{"NONE"}, /* line 68 is name of mail section 12 */
{"NONE"}, /* line 69 is name of mail section 13 */
{"NONE"}, /* line 70 is name of mail section 14 */
{"NONE"}, /* line 71 is name of mail section 15 */
{"NONE"}, /* line 72 is name of mail section 16 */
{"NONE"}, /* line 73 is name of mail section 17 */
{"NONE"}, /* line 74 is name of mail section 18 */
{"NONE"}, /* line 75 is name of mail section 19 */
{"NONE"}, /* line 76 is name of mail section 20 */
{"3"}, /* line 77 is COM port IRQ */
{"50"}, /* line 78 is percentage of time required */
/* for upload to reward uploader with */
{"09"}, /* line 79 == local help menu color */
{"04"}, /* line 80 == local status menu color */
{"06"}, /* line 81 == local recent caller display */
{"36-1"}, /* line 82 == ansi bulletin color */
{"31-1"}, /* line 83 == ansi main menu color */
{"33-1"}, /* line 84 == ansi file system color */
{"32-1"}, /* line 85 == ansi mail system color */
{"NONE"}, /* line 86 == door name 1 */
{"NONE"}, /* line 87 == door name 2 */
{"NONE"}, /* line 88 == door name 3 */
{"NONE"}, /* line 89 == door name 4 */
{"NONE"}, /* line 90 == door name 5 */
{"NONE"}, /* line 91 == door name 6 */
{"N"}, /* line 92 == private flag for conf 1 */
{"N"}, /* line 93 == private flag for conf 2 */
{"N"}, /* line 94 == private flag for conf 3 */
{"N"}, /* line 95 == private flag for conf 4 */

- 192 -

FX-BBS Installation and User's Guide

{"N"}, /* line 96 == private flag for conf 5 */
{"N"}, /* line 97 == private flag for conf 6 */
{"0"}, /* line 98 == mail section for conf 1 */
{"0"}, /* line 99 == mail section for conf 2 */
{"0"}, /* line 100 == mail section for conf 3 */
{"0"}, /* line 101 == mail section for conf 4 */
{"0"}, /* line 102 == mail section for conf 5 */
{"0"}, /* line 103 == mail section for conf 6 */
{"0"}, /* line 104 == dir # for conf 1 */
{"0"}, /* line 105 == dir # for conf 2 */
{"0"}, /* line 106 == dir # for conf 3 */
{"0"}, /* line 107 == dir # for conf 4 */
{"0"}, /* line 108 == dir # for conf 5 */
{"0"}, /* line 109 == dir # for conf 6 */
{"Y"}, /* line 110 is auto_baud detect flag */
{"N"}, /* line 111 is repack option */
{"N"}, /* line 112 is SYSOP only flag for msg del */
{"0xf7"}, /* line 113 is interrupt mask */
{"NONE"}, /* line 114 Door Password 1 */
{"NONE"}, /* line 115 Door Password 2 */
{"NONE"}, /* line 116 Door Password 2 */
{"NONE"}, /* line 117 Door Password 4 */
{"NONE"}, /* line 118 Door Password 5 */
{"NONE"}, /* line 119 Door Password 6 */
{"NONE"}, /* line 120 Name of external protocol 1 */
{"NONE"}, /* line 121 Name of extennal protocol 2 */
{"NONE"}, /* line 122 Name of external protocol 3 */
{"NONE"}, /* line 123 Name of external protocol 4 */
{"NONE"}, /* line 124 external protocol 1 dnload cmd */
{"NONE"}, /* line 125 external protocol 2 dnload cmd */
{"NONE"}, /* line 126 external protocol 3 dnload cmd */
{"NONE"}, /* line 127 external protocol 4 dnload cmd */
{"NONE"}, /* line 128 external protocol 1 upload cmd */
{"NONE"}, /* line 129 external protocol 2 upload cmd */
{"NONE"}, /* line 130 external protocol 3 upload cmd */
{"NONE"}, /* line 131 external protocol 4 upload cmd */
{"NONE"}, /* line 132 mail section 21 */
{"NONE"}, /* line 133 mail section 22 */
{"NONE"}, /* line 134 mail section 23 */
{"NONE"}, /* line 135 mail section 24 */
{"NONE"}, /* line 136 mail section 25 */
{"NONE"}, /* line 137 mail section 26 */
{"NONE"}, /* line 138 mail section 27 */
{"NONE"}, /* line 139 mail section 28 */
{"NONE"}, /* line 140 mail section 29 */
{"NONE"}, /* line 141 mail section 30 */
{"NONE"}, /* line 142 mail section 31 */
{"NONE"}, /* line 143 mail section 32 */
{"NONE"}, /* line 144 mail section 33 */
{"NONE"}, /* line 145 mail section 34 */
{"NONE"}, /* line 146 mail section 35 */
{"NONE"}, /* line 147 mail section 36 */
{"NONE"}, /* line 148 mail section 37 */
{"NONE"}, /* line 149 mail section 38 */
{"NONE"}, /* line 150 mail section 39 */

- 193 -

FX-BBS Installation and User's Guide

{"NONE"}, /* line 151 mail section 40 */
{"0"}, /* line 152 download ratio for level 1 */
{"10"}, /* line 153 download ratio for level 2 */
{"20"}, /* line 154 download ratio for level 3 */
{"30"}, /* line 155 download ratio for level 4 */
{"40"}, /* line 156 download ratio for level 5 */
{"50"}, /* line 157 download ratio for level 6 */
{"999"}, /* line 158 download ratio for level 7 */
{"999"}, /* line 159 download ratio for level 8 */
{"999"}, /* line 160 download ratio for level 9 */
{"999"}, /* line 161 download ratio for level 10 */
{"1"}, /* line 162 max daily calls for level 1 */
{"3"}, /* line 163 max daily calls for level 2 */
{"5"}, /* line 164 max daily calls for level 3 */
{"99"}, /* line 165 max daily calls for level 4 */
{"99"}, /* line 166 max daily calls for level 5 */
{"99"}, /* line 167 max daily calls for level 6 */
{"99"}, /* line 168 max daily calls for level 7 */
{"99"}, /* line 169 max daily calls for level 8 */
{"99"}, /* line 170 max daily calls for level 9 */
{"99"}, /* line 171 max daily calls for level 10 */
{"NONE"}, /* line 172 download search path 5 */
{"NONE"}, /* line 173 download search path 6 */
{"0"}, /* line 174 files dl per day level 1 */
{"5"}, /* line 175 files dl per day level 2 */
{"10"}, /* line 176 files dl per day level 3 */
{"20"}, /* line 177 files dl per day level 4 */
{"99"}, /* line 178 files dl per day level 5 */
{"99"}, /* line 179 files dl per day level 6 */
{"99"}, /* line 180 files dl per day level 7 */
{"99"}, /* line 181 files dl per day level 8 */
{"99"}, /* line 182 files dl per day level 9 */
{"99"}, /* line 183 files dl per day level 10 */
{"0"}, /* line 184 Kb dl per day level 1 */
{"500"}, /* line 185 Kb dl per day level 2 */
{"1000"}, /* line 186 Kb dl per day level 3 */
{"5000"}, /* line 187 Kb dl per day level 4 */
{"9999"}, /* line 188 Kb dl per day level 5 */
{"9999"}, /* line 189 Kb dl per day level 6 */
{"9999"}, /* line 190 Kb dl per day level 7 */
{"9999"}, /* line 191 Kb dl per day level 8 */
{"9999"}, /* line 192 Kb dl per day level 9 */
{"9999"}, /* line 193 Kb dl per day level 10 */
{"1800"}, /* line 194 is start SYSOP avail time */
{"2200"}, /* line 195 is stop SYSOP avail time */
{"0"}, /* line 196 is Mail system Auto-Repack time*/
{"1000"}, /* line 197 Repack purge level */
{"1"}, /* line 198 Node specific minacclevel reqd */
{"SYSOP"}, /* line 199 SYSOP's Name */
{"L"}, /* line 200 Local/echo/Net mail flag sec 1 */
{"L"}, /* line 201 Local/echo/Net mail flag sec 2 */
{"L"}, /* line 202 Local/echo/Net mail flag sec 3 */
{"L"}, /* line 203 Local/echo/Net mail flag sec 4 */
{"L"}, /* line 204 Local/echo/Net mail flag sec 5 */
{"L"}, /* line 205 Local/echo/Net mail flag sec 6 */

- 194 -

FX-BBS Installation and User's Guide

{"L"}, /* line 206 Local/echo/Net mail flag sec 7 */
{"L"}, /* line 207 Local/echo/Net mail flag sec 8 */
{"L"}, /* line 208 Local/echo/Net mail flag sec 9 */
{"L"}, /* line 209 Local/echo/Net mail flag sec 10*/
{"L"}, /* line 210 Local/echo/Net mail flag sec 11*/
{"L"}, /* line 211 Local/echo/Net mail flag sec 12*/
{"L"}, /* line 212 Local/echo/Net mail flag sec 13*/
{"L"}, /* line 213 Local/echo/Net mail flag sec 14*/
{"L"}, /* line 214 Local/echo/Net mail flag sec 15*/
{"L"}, /* line 215 Local/echo/Net mail flag sec 16*/
{"L"}, /* line 216 Local/echo/Net mail flag sec 17*/
{"L"}, /* line 217 Local/echo/Net mail flag sec 18*/
{"L"}, /* line 218 Local/echo/Net mail flag sec 19*/
{"L"}, /* line 219 Local/echo/Net mail flag sec 20*/
{"L"}, /* line 220 Local/echo/Net mail flag sec 21*/
{"L"}, /* line 221 Local/echo/Net mail flag sec 22*/
{"L"}, /* line 222 Local/echo/Net mail flag sec 23*/
{"L"}, /* line 223 Local/echo/Net mail flag sec 24*/
{"L"}, /* line 224 Local/echo/Net mail flag sec 25*/
{"L"}, /* line 225 Local/echo/Net mail flag sec 26*/
{"L"}, /* line 226 Local/echo/Net mail flag sec 27*/
{"L"}, /* line 227 Local/echo/Net mail flag sec 28*/
{"L"}, /* line 228 Local/echo/Net mail flag sec 29*/
{"L"}, /* line 229 Local/echo/Net mail flag sec 30*/
{"L"}, /* line 230 Local/echo/Net mail flag sec 31*/
{"L"}, /* line 231 Local/echo/Net mail flag sec 32*/
{"L"}, /* line 232 Local/echo/Net mail flag sec 33*/
{"L"}, /* line 233 Local/echo/Net mail flag sec 34*/
{"L"}, /* line 234 Local/echo/Net mail flag sec 35*/
{"L"}, /* line 235 Local/echo/Net mail flag sec 36*/
{"L"}, /* line 236 Local/echo/Net mail flag sec 37*/
{"L"}, /* line 237 Local/echo/Net mail flag sec 38*/
{"L"}, /* line 238 Local/echo/Net mail flag sec 39*/
{"L"}, /* line 239 Local/echo/Net mail flag sec 40*/
{"Y"}, /* line 240 is allow comments flag (Y/N) */
{"0"}, /* line 241 is this node_number */
{"0"}, /* line 242 is this net_number */
{"0"}, /* line 243 is this zone_number */
{"NONE"}, /* line 244 is first half of origin line */
{"NONE"}, /* line 245 is second half of origin line */
{"0"}, /* line 246 is parent or destination node */
{"0"}, /* line 247 is parent or destination net */
{"0"}, /* line 248 is dest net for section 1 */
{"0"}, /* line 249 is dest net for section 2 */
{"0"}, /* line 250 is dest net for section 3 */
{"0"}, /* line 251 is dest net for section 4 */
{"0"}, /* line 252 is dest net for section 5 */
{"0"}, /* line 253 is dest net for section 6 */
{"0"}, /* line 254 is dest net for section 7 */
{"0"}, /* line 255 is dest net for section 8 */
{"0"}, /* line 236 is dest net for section 9 */
{"0"}, /* line 257 is dest net for section 10 */
{"0"}, /* line 258 is dest net for section 11 */
{"0"}, /* line 259 is dest net for section 12 */
{"0"}, /* line 260 is dest net for section 13 */

- 195 -

FX-BBS Installation and User's Guide

{"0"}, /* line 261 is dest net for section 14 */
{"0"}, /* line 262 is dest net for section 15 */
{"0"}, /* line 263 is dest net for section 16 */
{"0"}, /* line 264 is dest net for section 17 */
{"0"}, /* line 265 is dest net for section 18 */
{"0"}, /* line 266 is dest net for section 19 */
{"0"}, /* line 267 is dest net for section 20 */
{"0"}, /* line 268 is dest net for section 21 */
{"0"}, /* line 269 is dest net for section 22 */
{"0"}, /* line 270 is dest net for section 23 */
{"0"}, /* line 271 is dest net for section 24 */
{"0"}, /* line 272 is dest net for section 25 */
{"0"}, /* line 273 is dest net for section 26 */
{"0"}, /* line 274 is dest net for section 27 */
{"0"}, /* line 275 is dest net for section 28 */
{"0"}, /* line 276 is dest net for section 29 */
{"0"}, /* line 277 is dest net for section 30 */
{"0"}, /* line 278 is dest net for section 31 */
{"0"}, /* line 279 is dest net for section 32 */
{"0"}, /* line 280 is dest net for section 33 */
{"0"}, /* line 281 is dest net for section 34 */
{"0"}, /* line 282 is dest net for section 35 */
{"0"}, /* line 283 is dest net for section 36 */
{"0"}, /* line 284 is dest net for section 37 */
{"0"}, /* line 285 is dest net for section 38 */
{"0"}, /* line 286 is dest net for section 39 */
{"0"}, /* line 287 is dest net for section 40 */
{"0"}, /* line 288 is dest node for section 1 */
{"0"}, /* line 289 is dest node for section 2 */
{"0"}, /* line 290 is dest node for section 3 */
{"0"}, /* line 291 is dest node for section 4 */
{"0"}, /* line 292 is dest node for section 5 */
{"0"}, /* line 293 is dest node for section 6 */
{"0"}, /* line 294 is dest node for section 7 */
{"0"}, /* line 295 is dest node for section 8 */
{"0"}, /* line 296 is dest node for section 9 */
{"0"}, /* line 297 is dest node for section 10 */
{"0"}, /* line 298 is dest node for section 11 */
{"0"}, /* line 299 is dest node for section 12 */
{"0"}, /* line 300 is dest node for section 13 */
{"0"}, /* line 301 is dest node for section 14 */
{"0"}, /* line 302 is dest node for section 15 */
{"0"}, /* line 303 is dest node for section 16 */
{"0"}, /* line 304 is dest node for section 17 */
{"0"}, /* line 305 is dest node for section 18 */
{"0"}, /* line 306 is dest node for section 19 */
{"0"}, /* line 307 is dest node for section 20 */
{"0"}, /* line 308 is dest node for section 21 */
{"0"}, /* line 309 is dest node for section 22 */
{"0"}, /* line 310 is dest node for section 23 */
{"0"}, /* line 311 is dest node for section 24 */
{"0"}, /* line 312 is dest node for section 25 */
{"0"}, /* line 313 is dest node for section 26 */
{"0"}, /* line 314 is dest node for section 27 */
{"0"}, /* line 315 is dest node for section 28 */

- 196 -

FX-BBS Installation and User's Guide

{"0"}, /* line 316 is dest node for section 29 */
{"0"}, /* line 317 is dest node for section 30 */
{"0"}, /* line 318 is dest node for section 31 */
{"0"}, /* line 319 is dest node for section 32 */
{"0"}, /* line 320 is dest node for section 33 */
{"0"}, /* line 321 is dest node for section 34 */
{"0"}, /* line 322 is dest node for section 35 */
{"0"}, /* line 323 is dest node for section 36 */
{"0"}, /* line 324 is dest node for section 37 */
{"0"}, /* line 325 is dest node for section 38 */
{"0"}, /* line 326 is dest node for section 39 */
{"0"}, /* line 327 is dest node for section 40 */
{"DC"}, /* line 328 is flow flag for section 1 */
{"DC"}, /* line 329 is flow flag for section 2 */
{"DC"}, /* line 330 is flow flag for section 3 */
{"DC"}, /* line 331 is flow flag for section 4 */
{"DC"}, /* line 332 is flow flag for section 5 */
{"DC"}, /* line 333 is flow flag for section 6 */
{"DC"}, /* line 334 is flow flag for section 7 */
{"DC"}, /* line 335 is flow flag for section 8 */
{"DC"}, /* line 336 is flow flag for section 9 */
{"DC"}, /* line 337 is flow flag for section 10 */
{"DC"}, /* line 338 is flow flag for section 11 */
{"DC"}, /* line 339 is flow flag for section 12 */
{"DC"}, /* line 340 is flow flag for section 13 */
{"DC"}, /* line 341 is flow flag for section 14 */
{"DC"}, /* line 342 is flow flag for section 15 */
{"DC"}, /* line 343 is flow flag for section 16 */
{"DC"}, /* line 344 is flow flag for section 17 */
{"DC"}, /* line 345 is flow flag for section 18 */
{"DC"}, /* line 346 is flow flag for section 19 */
{"DC"}, /* line 347 is flow flag for section 20 */
{"DC"}, /* line 348 is flow flag for section 21 */
{"DC"}, /* line 349 is flow flag for section 22 */
{"DC"}, /* line 350 is flow flag for section 23 */
{"DC"}, /* line 351 is flow flag for section 24 */
{"DC"}, /* line 352 is flow flag for section 25 */
{"DC"}, /* line 353 is flow flag for section 26 */
{"DC"}, /* line 354 is flow flag for section 27 */
{"DC"}, /* line 355 is flow flag for section 28 */
{"DC"}, /* line 356 is flow flag for section 29 */
{"DC"}, /* line 357 is flow flag for section 30 */
{"DC"}, /* line 358 is flow flag for section 31 */
{"DC"}, /* line 359 is flow flag for section 32 */
{"DC"}, /* line 360 is flow flag for section 33 */
{"DC"}, /* line 361 is flow flag for section 34 */
{"DC"}, /* line 362 is flow flag for section 35 */
{"DC"}, /* line 363 is flow flag for section 36 */
{"DC"}, /* line 364 is flow flag for section 37 */
{"DC"}, /* line 365 is flow flag for section 38 */
{"DC"}, /* line 366 is flow flag for section 39 */
{"DC"}, /* line 367 is flow flag for section 40 */
{"0x0b"}, /* line 368 is COM vector */
{"N"}, /* line 369 overlay door number 1 flag */
{"N"}, /* line 370 overlay door number 2 flag */

- 197 -

FX-BBS Installation and User's Guide

{"N"}, /* line 371 overlay door number 3 flag */
{"N"}, /* line 372 overlay door number 4 flag */
{"N"}, /* line 373 overlay door number 5 flag */
{"N"}, /* line 374 overlay door number 6 flag */
{"01"}, /* line 375 BBS system number (01 - 99) */
{"NONE"}, /* line 376 is file extention to disallow */
{"NONE"}, /* line 377 is file extention to disallow */
{"NONE"}, /* line 378 is file extention to disallow */
{"NONE"}, /* line 379 is file extention to disallow */
{"NONE"}, /* line 380 is file extention to disallow */
{"NONE"}, /* line 381 is file extention to disallow */
{"NONE"}, /* line 382 is file extention to disallow */
{"NONE"}, /* line 383 is file extention to disallow */
{"NONE"}, /* line 384 is file extention to disallow */
{"NONE"}, /* line 385 is file extention to disallow */
{"NONE"}, /* line 386 is file extention to disallow */
{"NONE"}, /* line 387 is file extention to disallow */
{"NONE"}, /* line 388 is file extention to disallow */
{"NONE"}, /* line 389 is file extention to disallow */
{"NONE"}, /* line 390 is file extention to disallow */
{"NONE"}, /* line 391 is file extention to disallow */
{"NONE"}, /* line 392 is file extention to disallow */
{"NONE"}, /* line 393 is file extention to disallow */
{"NONE"}, /* line 394 is file extention to disallow */
{"NONE"}, /* line 395 is file extention to disallow */
{"N"}, /* line 396 is subscription flag */
{"1"}, /* line 397 is drop level */
{"NONE"}, /* line 398 is illegal logon fragment 1 */
{"NONE"}, /* line 399 is illegal logon fragment 2 */
{"NONE"}, /* line 400 is illegal logon fragment 3 */
{"NONE"}, /* line 401 is illegal logon fragment 4 */
{"NONE"}, /* line 402 is illegal logon fragment 5 */
{"NONE"}, /* line 403 is illegal logon fragment 6 */
{"NONE"}, /* line 404 is illegal logon fragment 7 */
{"NONE"}, /* line 405 is illegal logon fragment 8 */
{"NONE"}, /* line 406 is illegal logon fragment 9 */
{"NONE"}, /* line 407 is illegal logon fragment 10 */
{"NONE"}, /* line 408 is illegal logon fragment 11 */
{"NONE"}, /* line 409 is illegal logon fragment 12 */
{"NONE"}, /* line 410 is illegal logon fragment 13 */
{"NONE"}, /* line 411 is illegal logon fragment 14 */
{"NONE"}, /* line 412 is illegal logon fragment 15 */
{"NONE"}, /* line 413 is illegal logon fragment 16 */
{"NONE"}, /* line 414 is illegal logon fragment 17 */
{"NONE"}, /* line 415 is illegal logon fragment 18 */
{"NONE"}, /* line 416 is illegal logon fragment 19 */
{"NONE"}, /* line 417 is illegal logon fragment 20 */
{"NONE"}, /* line 418 is illegal logon fragment 21 */
{"NONE"}, /* line 419 is illegal logon fragment 22 */
{"NONE"}, /* line 420 is illegal logon fragment 23 */
{"NONE"}, /* line 421 is illegal logon fragment 24 */
{"NONE"}, /* line 422 is illegal logon fragment 25 */
{"NONE"}, /* line 423 is illegal logon fragment 26 */
{"NONE"}, /* line 424 is illegal logon fragment 27 */
{"NONE"}, /* line 425 is illegal logon fragment 28 */

- 198 -

FX-BBS Installation and User's Guide

{"NONE"}, /* line 426 is illegal logon fragment 29 */
{"NONE"}, /* line 427 is illegal logon fragment 30 */
{"NONE"}, /* line 428 is illegal logon fragment 31 */
{"NONE"}, /* line 429 is illegal logon fragment 32 */
{"NONE"}, /* line 430 is illegal logon fragment 33 */
{"NONE"}, /* line 431 is illegal logon fragment 34 */
{"NONE"}, /* line 432 is illegal logon fragment 35 */
{"NONE"}, /* line 433 is illegal logon fragment 36 */
{"NONE"}, /* line 434 is illegal logon fragment 37 */
{"NONE"}, /* line 435 is illegal logon fragment 38 */
{"NONE"}, /* line 436 is illegal logon fragment 39 */
{"NONE"}, /* line 437 is illegal logon fragment 40 */
{"0"}, /* line 438 is optimze communications */
{"N"}, /* line 439 is Lock baud rate flag */
{"NONE"}, /* line 440 is name of protocol 5 */
{"NONE"}, /* line 441 is name of protocol 6 */
{"NONE"}, /* line 442 is external prot 5 dnld cmnd */
{"NONE"}, /* line 443 is external prot 6 dnld cmnd */
{"NONE"}, /* line 444 is external prot 5 upld cmnd */
{"NONE"}, /* line 445 is external prot 6 upld cmnd */
{"50"}, /* line 446 is pack level for section 1 */
{"50"}, /* line 447 is pack level for section 2 */
{"50"}, /* line 448 is pack level for section 3 */
{"50"}, /* line 449 is pack level for section 4 */
{"50"}, /* line 450 is pack level for section 5 */
{"50"}, /* line 451 is pack level for section 6 */
{"50"}, /* line 452 is pack level for section 7 */
{"50"}, /* line 453 is pack level for section 8 */
{"50"}, /* line 454 is pack level for section 9 */
{"50"}, /* line 455 is pack level for section 10 */
{"50"}, /* line 456 is pack level for section 11 */
{"50"}, /* line 457 is pack level for section 12 */
{"50"}, /* line 458 is pack level for section 13 */
{"50"}, /* line 459 is pack level for section 14 */
{"50"}, /* line 460 is pack level for section 15 */
{"50"}, /* line 461 is pack level for section 16 */
{"50"}, /* line 462 is pack level for section 17 */
{"50"}, /* line 463 is pack level for section 18 */
{"50"}, /* line 464 is pack level for section 19 */
{"50"}, /* line 465 is pack level for section 20 */
{"50"}, /* line 466 is pack level for section 21 */
{"50"}, /* line 467 is pack level for section 22 */
{"50"}, /* line 468 is pack level for section 23 */
{"50"}, /* line 469 is pack level for section 24 */
{"50"}, /* line 470 is pack level for section 25 */
{"50"}, /* line 471 is pack level for section 26 */
{"50"}, /* line 472 is pack level for section 27 */
{"50"}, /* line 473 is pack level for section 28 */
{"50"}, /* line 474 is pack level for section 29 */
{"50"}, /* line 475 is pack level for section 30 */
{"50"}, /* line 476 is pack level for section 31 */
{"50"}, /* line 477 is pack level for section 32 */
{"50"}, /* line 478 is pack level for section 33 */
{"50"}, /* line 479 is pack level for section 34 */
{"50"}, /* line 480 is pack level for section 35 */

- 199 -

FX-BBS Installation and User's Guide

{"50"}, /* line 481 is pack level for section 36 */
{"50"}, /* line 482 is pack level for section 37 */
{"50"}, /* line 483 is pack level for section 38 */
{"50"}, /* line 484 is pack level for section 39 */
{"50"}, /* line 485 is pack level for section 40 */
{"N"}, /* line 486 is check snow parameter */
{"0x02f8"}, /* I/O Register Address */
{"N"} /* Line 488 is LAN chat mode enable flag */
{"Y"}, /* Internal Com flag: MUST BE "Y" */
{"NONE"}, /* line 490 is conference dir 1 */
{"NONE"}, /* line 491 is conference dir 2 */
{"NONE"}, /* line 492 is conference dir 3 */
{"NONE"}, /* line 493 is conference dir 4 */
{"NONE"}, /* line 494 is conference dir 5 */
{"NONE"} /* line 495 is conference dir 6 */
{"C:\\FX-BBS\\MSGS\\"}, /* line 496 is path to message files. */
{"D:\\FILES\\"}, /* line 497 is root search path nbr 2 */
{"C:\\FX-BBS\\TEXT\\"}, /* line 498 is path to text files. */
{"C:\\FILES\\"}, /* line 499 is root search path nbr 1 */
{"N"}, /* line 500 is batch protocol flag 1 */
{"N"}, /* line 501 is batch protocol flag 1 */
{"N"}, /* line 502 is batch protocol flag 1 */
{"N"}, /* line 503 is batch protocol flag 1 */
{"N"}, /* line 504 is batch protocol flag 1 */
{"N"}, /* line 505 is batch protocol flag 1 */
{"N"}, /* line 506 == private flag for conf 7 */
{"N"}, /* line 507 == private flag for conf 8 */
{"N"}, /* line 508 == private flag for conf 9 */
{"N"}, /* line 509 == private flag for conf 10 */
{"N"}, /* line 510 == private flag for conf 11 */
{"N"}, /* line 511 == private flag for conf 12 */
{"N"}, /* line 512 == private flag for conf 13 */
{"N"}, /* line 513 == private flag for conf 14 */
{"N"}, /* line 514 == private flag for conf 15 */
{"N"}, /* line 515 == private flag for conf 16 */
{"N"}, /* line 516 == private flag for conf 17 */
{"N"}, /* line 517 == private flag for conf 18 */
{"N"}, /* line 518 == private flag for conf 19 */
{"N"}, /* line 519 == private flag for conf 20 */
{"0"}, /* line 520 == mail section for conf 7 */
{"0"}, /* line 521 == mail section for conf 8 */
{"0"}, /* line 522 == mail section for conf 9 */
{"0"}, /* line 523 == mail section for conf 10 */
{"0"}, /* line 524 == mail section for conf 11 */
{"0"}, /* line 525 == mail section for conf 12 */
{"0"}, /* line 526 == mail section for conf 13 */
{"0"}, /* line 527 == mail section for conf 14 */
{"0"}, /* line 528 == mail section for conf 15 */
{"0"}, /* line 529 == mail section for conf 16 */
{"0"}, /* line 530 == mail section for conf 17 */
{"0"}, /* line 531 == mail section for conf 18 */
{"0"}, /* line 532 == mail section for conf 19 */
{"0"}, /* line 533 == mail section for conf 20 */
{"0"}, /* line 534 == dir # for conf 7 */
{"0"}, /* line 535 == dir # for conf 8 */

- 200 -

FX-BBS Installation and User's Guide

{"0"}, /* line 536 == dir # for conf 9 */
{"0"}, /* line 537 == dir # for conf 10 */
{"0"}, /* line 538 == dir # for conf 11 */
{"0"}, /* line 539 == dir # for conf 12 */
{"0"}, /* line 540 == dir # for conf 13 */
{"0"}, /* line 541 == dir # for conf 14 */
{"0"}, /* line 542 == dir # for conf 15 */
{"0"}, /* line 543 == dir # for conf 16 */
{"0"}, /* line 544 == dir # for conf 17 */
{"0"}, /* line 545 == dir # for conf 18 */
{"0"}, /* line 546 == dir # for conf 19 */
{"0"}, /* line 547 == dir # for conf 20 */
{"NONE"}, /* line 548 is conference dir 7 */
{"NONE"}, /* line 549 is conference dir 8 */
{"NONE"}, /* line 550 is conference dir 9 */
{"NONE"}, /* line 551 is conference dir 10 */
{"NONE"}, /* line 552 is conference dir 11 */
{"NONE"}, /* line 553 is conference dir 12 */
{"NONE"}, /* line 554 is conference dir 13 */
{"NONE"}, /* line 555 is conference dir 14 */
{"NONE"}, /* line 556 is conference dir 15 */
{"NONE"}, /* line 557 is conference dir 16 */
{"NONE"}, /* line 558 is conference dir 17 */
{"NONE"}, /* line 559 is conference dir 18 */
{"NONE"}, /* line 560 is conference dir 19 */
{"NONE"}, /* line 561 is conference dir 20 */
{"NONE"}, /* line 562 == door name 7 */
{"NONE"}, /* line 563 == door name 8 */
{"NONE"}, /* line 564 == door name 9 */
{"NONE"}, /* line 565 == door name 10 */
{"NONE"}, /* line 566 == door name 11 */
{"NONE"}, /* line 567 == door name 12 */
{"NONE"}, /* line 568 == door name 13 */
{"NONE"}, /* line 569 == door name 14 */
{"NONE"}, /* line 570 == door name 15 */
{"NONE"}, /* line 571 == door name 16 */
{"NONE"}, /* line 572 == door name 17 */
{"NONE"}, /* line 573 == door name 18 */
{"NONE"}, /* line 574 == door name 19 */
{"NONE"}, /* line 575 == door name 20 */
{"NONE"}, /* line 576 == door name 21 */
{"NONE"}, /* line 577 == door name 22 */
{"NONE"}, /* line 578 == door name 23 */
{"NONE"}, /* line 579 == door name 24 */
{"NONE"}, /* line 580 == door name 25 */
{"NONE"}, /* line 581 == door name 26 */
{"NONE"}, /* line 582 == door name 27 */
{"NONE"}, /* line 583 == door name 28 */
{"NONE"}, /* line 594 == door name 29 */
{"NONE"}, /* line 595 == door name 30 */
{"NONE"}, /* line 586 == door name 31 */
{"NONE"}, /* line 587 == door name 32 */
{"NONE"}, /* line 588 == door name 33 */
{"NONE"}, /* line 589 == door name 34 */
{"NONE"}, /* line 590 == door name 35 */

- 201 -

FX-BBS Installation and User's Guide

{"NONE"}, /* line 591 == door name 36 */
{"NONE"}, /* line 592 == door name 37 */
{"NONE"}, /* line 593 == door name 38 */
{"NONE"}, /* line 594 == door name 39 */
{"NONE"}, /* line 595 == door name 40 */
{"NONE"}, /* line 596 Door Password 7 */
{"NONE"}, /* line 597 Door Password 8 */
{"NONE"}, /* line 598 Door Password 9 */
{"NONE"}, /* line 599 Door Password 10 */
{"NONE"}, /* line 600 Door Password 11 */
{"NONE"}, /* line 601 Door Password 12 */
{"NONE"}, /* line 602 Door Password 13 */
{"NONE"}, /* line 603 Door Password 14 */
{"NONE"}, /* line 604 Door Password 15 */
{"NONE"}, /* line 605 Door Password 16 */
{"NONE"}, /* line 606 Door Password 17 */
{"NONE"}, /* line 607 Door Password 18 */
{"NONE"}, /* line 608 Door Password 19 */
{"NONE"}, /* line 609 Door Password 20 */
{"NONE"}, /* line 610 Door Password 21 */
{"NONE"}, /* line 611 Door Password 22 */
{"NONE"}, /* line 612 Door Password 23 */
{"NONE"}, /* line 613 Door Password 24 */
{"NONE"}, /* line 614 Door Password 25 */
{"NONE"}, /* line 615 Door Password 26 */
{"NONE"}, /* line 616 Door Password 27 */
{"NONE"}, /* line 617 Door Password 28 */
{"NONE"}, /* line 618 Door Password 29 */
{"NONE"}, /* line 619 Door Password 30 */
{"NONE"}, /* line 620 Door Password 31 */
{"NONE"}, /* line 621 Door Password 32 */
{"NONE"}, /* line 622 Door Password 33 */
{"NONE"}, /* line 623 Door Password 34 */
{"NONE"}, /* line 624 Door Password 35 */
{"NONE"}, /* line 625 Door Password 36 */
{"NONE"}, /* line 626 Door Password 37 */
{"NONE"}, /* line 627 Door Password 38 */
{"NONE"}, /* line 628 Door Password 39 */
{"NONE"}, /* line 629 Door Password 40 */
{"N"}, /* line 630 overlay door number 7 flag */
{"N"}, /* line 631 overlay door number 8 flag */
{"N"}, /* line 632 overlay door number 9 flag */
{"N"}, /* line 633 overlay door number 10 flag */
{"N"}, /* line 634 overlay door number 11 flag */
{"N"}, /* line 635 overlay door number 12 flag */
{"N"}, /* line 636 overlay door number 13 flag */
{"N"}, /* line 637 overlay door number 14 flag */
{"N"}, /* line 638 overlay door number 15 flag */
{"N"}, /* line 639 overlay door number 16 flag */
{"N"}, /* line 640 overlay door number 17 flag */
{"N"}, /* line 641 overlay door number 18 flag */
{"N"}, /* line 642 overlay door number 19 flag */
{"N"}, /* line 643 overlay door number 20 flag */
{"N"}, /* line 644 overlay door number 21 flag */
{"N"}, /* line 645 overlay door number 22 flag */

- 202 -

FX-BBS Installation and User's Guide

{"N"}, /* line 646 overlay door number 23 flag */
{"N"}, /* line 647 overlay door number 24 flag */
{"N"}, /* line 648 overlay door number 25 flag */
{"N"}, /* line 649 overlay door number 26 flag */
{"N"}, /* line 650 overlay door number 27 flag */
{"N"}, /* line 651 overlay door number 28 flag */
{"N"}, /* line 652 overlay door number 29 flag */
{"N"}, /* line 653 overlay door number 30 flag */
{"N"}, /* line 654 overlay door number 31 flag */
{"N"}, /* line 655 overlay door number 32 flag */
{"N"}, /* line 656 overlay door number 33 flag */
{"N"}, /* line 657 overlay door number 34 flag */
{"N"}, /* line 658 overlay door number 35 flag */
{"N"}, /* line 659 overlay door number 36 flag */
{"N"}, /* line 660 overlay door number 37 flag */
{"N"}, /* line 661 overlay door number 38 flag */
{"N"}, /* line 662 overlay door number 39 flag */
{"N"}, /* line 663 overlay door number 40 flag */
{"0"}, /* line 664 key to start door number 1 */
{"0"}, /* line 665 key to start door number 2 */
{"0"}, /* line 666 key to start door number 3 */
{"0"}, /* line 667 key to start door number 4 */
{"0"}, /* line 668 key to start door number 5 */
{"0"}, /* line 669 key to start door number 6 */
{"0"}, /* line 670 key to start door number 7 */
{"0"}, /* line 671 key to start door number 8 */
{"0"}, /* line 672 key to start door number 9 */
{"0"}, /* line 673 key to start door number 10 */
{"0"}, /* line 674 key to start door number 11 */
{"0"}, /* line 675 key to start door number 12 */
{"0"}, /* line 676 key to start door number 13 */
{"0"}, /* line 677 key to start door number 14 */
{"0"}, /* line 678 key to start door number 15 */
{"0"}, /* line 679 key to start door number 16 */
{"0"}, /* line 680 key to start door number 17 */
{"0"}, /* line 681 key to start door number 18 */
{"0"}, /* line 682 key to start door number 19 */
{"0"}, /* line 683 key to start door number 20 */
{"0"}, /* line 684 key to start door number 21 */
{"0"}, /* line 685 key to start door number 22 */
{"0"}, /* line 686 key to start door number 23 */
{"0"}, /* line 687 key to start door number 24 */
{"0"}, /* line 688 key to start door number 25 */
{"0"}, /* line 689 key to start door number 26 */
{"0"}, /* line 690 key to start door number 27 */
{"0"}, /* line 691 key to start door number 28 */
{"0"}, /* line 692 key to start door number 29 */
{"0"}, /* line 693 key to start door number 30 */
{"0"}, /* line 694 key to start door number 31 */
{"0"}, /* line 695 key to start door number 32 */
{"0"}, /* line 696 key to start door number 33 */
{"0"}, /* line 697 key to start door number 34 */
{"0"}, /* line 698 key to start door number 35 */
{"0"}, /* line 699 key to start door number 36 */
{"0"}, /* line 700 key to start door number 37 */

- 203 -

FX-BBS Installation and User's Guide

{"0"}, /* line 701 key to start door number 38 */
{"0"}, /* line 702 key to start door number 39 */
{"0"}, /* line 703 key to start door number 40 */
{"NONE"}, /* line 704 function key definition 1 */
{"NONE"}, /* line 705 function key definition 2 */
{"NONE"}, /* line 706 function key definition 3 */
{"NONE"}, /* line 707 function key definition 4 */
{"NONE"}, /* line 708 function key definition 5 */
{"NONE"}, /* line 709 function key definition 6 */
{"NONE"}, /* line 710 function key definition 7 */
{"NONE"}, /* line 711 function key definition 8 */
{"NONE"}, /* line 712 function key definition 9 */
{"NONE"}, /* line 713 function key definition 10 */
{"NONE"}, /* line 714 function key definition 11 */
{"NONE"}, /* line 715 function key definition 12 */
{"NONE"}, /* line 716 function key definition 13 */
{"NONE"}, /* line 717 function key definition 14 */
{"NONE"}, /* line 718 function key definition 15 */
{"NONE"}, /* line 719 function key definition 16 */
{"NONE"}, /* line 720 function key definition 17 */
{"NONE"}, /* line 721 function key definition 18 */
{"NONE"}, /* line 722 function key definition 19 */
{"NONE"}, /* line 723 function key definition 20 */
{"NONE"}, /* line 724 function key definition 21 */
{"NONE"}, /* line 725 function key definition 22 */
{"NONE"}, /* line 726 function key definition 23 */
{"NONE"}, /* line 727 function key definition 24 */
{"NONE"}, /* line 728 function key definition 25 */
{"NONE"}, /* line 729 function key definition 26 */
{"NONE"}, /* line 730 function key definition 27 */
{"NONE"}, /* line 731 function key definition 28 */
{"NONE"}, /* line 732 function key definition 29 */
{"NONE"}, /* line 733 function key definition 30 */
{"NONE"}, /* line 734 function key definition 31 */
{"NONE"}, /* line 735 function key definition 32 */
{"L"}, /* line 736 Local/echo/Net flag for sec 41 */
{"L"}, /* line 737 Local/echo/Net flag for sec 42 */
{"L"}, /* line 738 Local/echo/Net flag for sec 43 */
{"L"}, /* line 739 Local/echo/Net flag for sec 44 */
{"L"}, /* line 740 Local/echo/Net flag for sec 45 */
{"L"}, /* line 741 Local/echo/Net flag for sec 46 */
{"L"}, /* line 742 Local/echo/Net flag for sec 47 */
{"L"}, /* line 743 Local/echo/Net flag for sec 48 */
{"L"}, /* line 744 Local/echo/Net flag for sec 49 */
{"L"}, /* line 745 Local/echo/Net flag for sec 50 */
{"L"}, /* line 746 Local/echo/Net flag for sec 51 */
{"L"}, /* line 747 Local/echo/Net flag for sec 52 */
{"L"}, /* line 748 Local/echo/Net flag for sec 53 */
{"L"}, /* line 749 Local/echo/Net flag for sec 54 */
{"L"}, /* line 750 Local/echo/Net flag for sec 55 */
{"L"}, /* line 751 Local/echo/Net flag for sec 56 */
{"L"}, /* line 752 Local/echo/Net flag for sec 57 */
{"L"}, /* line 753 Local/echo/Net flag for sec 58 */
{"L"}, /* line 754 Local/echo/Net flag for sec 59 */
{"L"}, /* line 755 Local/echo/Net flag for sec 60 */

- 204 -

FX-BBS Installation and User's Guide

{"L"}, /* line 756 Local/echo/Net flag for sec 61 */
{"L"}, /* line 757 Local/echo/Net flag for sec 62 */
{"L"}, /* line 758 Local/echo/Net flag for sec 63 */
{"L"}, /* line 759 Local/echo/Net flag for sec 64 */
{"L"}, /* line 760 Local/echo/Net flag for sec 65 */
{"L"}, /* line 761 Local/echo/Net flag for sec 66 */
{"L"}, /* line 762 Local/echo/Net flag for sec 67 */
{"L"}, /* line 763 Local/echo/Net flag for sec 68 */
{"L"}, /* line 764 Local/echo/Net flag for sec 69 */
{"L"}, /* line 765 Local/echo/Net flag for sec 70 */
{"L"}, /* line 766 Local/echo/Net flag for sec 71 */
{"L"}, /* line 767 Local/echo/Net flag for sec 72 */
{"L"}, /* line 768 Local/echo/Net flag for sec 73 */
{"L"}, /* line 769 Local/echo/Net flag for sec 74 */
{"L"}, /* line 770 Local/echo/Net flag for sec 75 */
{"L"}, /* line 771 Local/echo/Net flag for sec 76 */
{"L"}, /* line 772 Local/echo/Net flag for sec 77 */
{"L"}, /* line 773 Local/echo/Net flag for sec 78 */
{"L"}, /* line 774 Local/echo/Net flag for sec 79 */
{"L"}, /* line 775 Local/echo/Net flag for sec 80 */
{"0"}, /* line 776 is dest net for section 41 */
{"0"}, /* line 777 is dest net for section 42 */
{"0"}, /* line 778 is dest net for section 43 */
{"0"}, /* line 779 is dest net for section 44 */
{"0"}, /* line 780 is dest net for section 45 */
{"0"}, /* line 781 is dest net for section 46 */
{"0"}, /* line 782 is dest net for section 47 */
{"0"}, /* line 783 is dest net for section 48 */
{"0"}, /* line 784 is dest net for section 49 */
{"0"}, /* line 785 is dest net for section 50 */
{"0"}, /* line 786 is dest net for section 51 */
{"0"}, /* line 787 is dest net for section 52 */
{"0"}, /* line 788 is dest net for section 53 */
{"0"}, /* line 789 is dest net for section 54 */
{"0"}, /* line 790 is dest net for section 55 */
{"0"}, /* line 791 is dest net for section 56 */
{"0"}, /* line 792 is dest net for section 57 */
{"0"}, /* line 793 is dest net for section 58 */
{"0"}, /* line 794 is dest net for section 59 */
{"0"}, /* line 795 is dest net for section 60 */
{"0"}, /* line 796 is dest net for section 61 */
{"0"}, /* line 797 is dest net for section 62 */
{"0"}, /* line 798 is dest net for section 63 */
{"0"}, /* line 799 is dest net for section 64 */
{"0"}, /* line 800 is dest net for section 65 */
{"0"}, /* line 801 is dest net for section 66 */
{"0"}, /* line 802 is dest net for section 67 */
{"0"}, /* line 803 is dest net for section 68 */
{"0"}, /* line 804 is dest net for section 69 */
{"0"}, /* line 805 is dest net for section 70 */
{"0"}, /* line 806 is dest net for section 71 */
{"0"}, /* line 807 is dest net for section 72 */
{"0"}, /* line 808 is dest net for section 73 */
{"0"}, /* line 809 is dest net for section 74 */
{"0"}, /* line 810 is dest net for section 75 */

- 205 -

FX-BBS Installation and User's Guide

{"0"}, /* line 811 is dest net for section 76 */
{"0"}, /* line 812 is dest net for section 77 */
{"0"}, /* line 813 is dest net for section 78 */
{"0"}, /* line 814 is dest net for section 79 */
{"0"}, /* line 815 is dest net for section 80 */
{"0"}, /* line 816 is dest node for section 41 */
{"0"}, /* line 817 is dest node for section 42 */
{"0"}, /* line 818 is dest node for section 43 */
{"0"}, /* line 819 is dest node for section 44 */
{"0"}, /* line 820 is dest node for section 45 */
{"0"}, /* line 821 is dest node for section 46 */
{"0"}, /* line 822 is dest node for section 47 */
{"0"}, /* line 823 is dest node for section 48 */
{"0"}, /* line 824 is dest node for section 49 */
{"0"}, /* line 825 is dest node for section 50 */
{"0"}, /* line 826 is dest node for section 51 */
{"0"}, /* line 827 is dest node for section 52 */
{"0"}, /* line 828 is dest node for section 53 */
{"0"}, /* line 829 is dest node for section 54 */
{"0"}, /* line 830 is dest node for section 55 */
{"0"}, /* line 831 is dest node for section 56 */
{"0"}, /* line 832 is dest node for section 57 */
{"0"}, /* line 833 is dest node for section 58 */
{"0"}, /* line 834 is dest node for section 59 */
{"0"}, /* line 835 is dest node for section 60 */
{"0"}, /* line 836 is dest node for section 61 */
{"0"}, /* line 837 is dest node for section 62 */
{"0"}, /* line 838 is dest node for section 63 */
{"0"}, /* line 839 is dest node for section 64 */
{"0"}, /* line 840 is dest node for section 65 */
{"0"}, /* line 841 is dest node for section 66 */
{"0"}, /* line 842 is dest node for section 67 */
{"0"}, /* line 843 is dest node for section 68 */
{"0"}, /* line 844 is dest node for section 69 */
{"0"}, /* line 845 is dest node for section 70 */
{"0"}, /* line 846 is dest node for section 71 */
{"0"}, /* line 847 is dest node for section 72 */
{"0"}, /* line 848 is dest node for section 73 */
{"0"}, /* line 849 is dest node for section 74 */
{"0"}, /* line 850 is dest node for section 75 */
{"0"}, /* line 851 is dest node for section 76 */
{"0"}, /* line 852 is dest node for section 77 */
{"0"}, /* line 853 is dest node for section 78 */
{"0"}, /* line 854 is dest node for section 79 */
{"0"}, /* line 855 is dest node for section 80 */
{"DC"}, /* line 856 is flow flag for section 41 */
{"DC"}, /* line 857 is flow flag for section 42 */
{"DC"}, /* line 858 is flow flag for section 43 */
{"DC"}, /* line 859 is flow flag for section 44 */
{"DC"}, /* line 860 is flow flag for section 45 */
{"DC"}, /* line 861 is flow flag for section 46 */
{"DC"}, /* line 862 is flow flag for section 47 */
{"DC"}, /* line 863 is flow flag for section 48 */
{"DC"}, /* line 864 is flow flag for section 49 */
{"DC"}, /* line 865 is flow flag for section 50 */

- 206 -

FX-BBS Installation and User's Guide

{"DC"}, /* line 866 is flow flag for section 51 */
{"DC"}, /* line 867 is flow flag for section 52 */
{"DC"}, /* line 868 is flow flag for section 53 */
{"DC"}, /* line 869 is flow flag for section 54 */
{"DC"}, /* line 870 is flow flag for section 55 */
{"DC"}, /* line 871 is flow flag for section 56 */
{"DC"}, /* line 872 is flow flag for section 57 */
{"DC"}, /* line 873 is flow flag for section 58 */
{"DC"}, /* line 874 is flow flag for section 59 */
{"DC"}, /* line 875 is flow flag for section 60 */
{"DC"}, /* line 876 is flow flag for section 61 */
{"DC"}, /* line 877 is flow flag for section 62 */
{"DC"}, /* line 878 is flow flag for section 63 */
{"DC"}, /* line 879 is flow flag for section 64 */
{"DC"}, /* line 880 is flow flag for section 65 */
{"DC"}, /* line 881 is flow flag for section 66 */
{"DC"}, /* line 882 is flow flag for section 67 */
{"DC"}, /* line 883 is flow flag for section 68 */
{"DC"}, /* line 884 is flow flag for section 69 */
{"DC"}, /* line 885 is flow flag for section 70 */
{"DC"}, /* line 886 is flow flag for section 71 */
{"DC"}, /* line 887 is flow flag for section 72 */
{"DC"}, /* line 888 is flow flag for section 73 */
{"DC"}, /* line 889 is flow flag for section 74 */
{"DC"}, /* line 890 is flow flag for section 75 */
{"DC"}, /* line 891 is flow flag for section 76 */
{"DC"}, /* line 892 is flow flag for section 77 */
{"DC"}, /* line 893 is flow flag for section 78 */
{"DC"}, /* line 894 is flow flag for section 79 */
{"DC"}, /* line 895 is flow flag for section 80 */
{"50"}, /* line 896 is pack level for section 41 */
{"50"}, /* line 897 is pack level for section 42 */
{"50"}, /* line 898 is pack level for section 43 */
{"50"}, /* line 899 is pack level for section 44 */
{"50"}, /* line 900 is pack level for section 45 */
{"50"}, /* line 901 is pack level for section 46 */
{"50"}, /* line 902 is pack level for section 47 */
{"50"}, /* line 903 is pack level for section 48 */
{"50"}, /* line 904 is pack level for section 49 */
{"50"}, /* line 905 is pack level for section 50 */
{"50"}, /* line 906 is pack level for section 51 */
{"50"}, /* line 907 is pack level for section 52 */
{"50"}, /* line 908 is pack level for section 53 */
{"50"}, /* line 909 is pack level for section 54 */
{"50"}, /* line 910 is pack level for section 55 */
{"50"}, /* line 911 is pack level for section 56 */
{"50"}, /* line 912 is pack level for section 57 */
{"50"}, /* line 913 is pack level for section 58 */
{"50"}, /* line 914 is pack level for section 59 */
{"50"}, /* line 915 is pack level for section 60 */
{"50"}, /* line 916 is pack level for section 61 */
{"50"}, /* line 917 is pack level for section 62 */
{"50"}, /* line 918 is pack level for section 63 */
{"50"}, /* line 919 is pack level for section 64 */
{"50"}, /* line 920 is pack level for section 65 */

- 207 -

FX-BBS Installation and User's Guide

{"50"}, /* line 921 is pack level for section 66 */
{"50"}, /* line 922 is pack level for section 67 */
{"50"}, /* line 923 is pack level for section 68 */
{"50"}, /* line 924 is pack level for section 69 */
{"50"}, /* line 925 is pack level for section 70 */
{"50"}, /* line 926 is pack level for section 71 */
{"50"}, /* line 927 is pack level for section 72 */
{"50"}, /* line 928 is pack level for section 73 */
{"50"}, /* line 929 is pack level for section 74 */
{"50"}, /* line 930 is pack level for section 75 */
{"50"}, /* line 931 is pack level for section 76 */
{"50"}, /* line 932 is pack level for section 77 */
{"50"}, /* line 933 is pack level for section 78 */
{"50"}, /* line 934 is pack level for section 79 */
{"50"}, /* line 935 is pack level for section 80 */
{"NONE"}, /* line 936 mail section 41 */
{"NONE"}, /* line 937 mail section 42 */
{"NONE"}, /* line 938 mail section 43 */
{"NONE"}, /* line 939 mail section 44 */
{"NONE"}, /* line 940 mail section 45 */
{"NONE"}, /* line 941 mail section 46 */
{"NONE"}, /* line 942 mail section 47 */
{"NONE"}, /* line 943 mail section 48 */
{"NONE"}, /* line 944 mail section 49 */
{"NONE"}, /* line 945 mail section 50 */
{"NONE"}, /* line 946 mail section 51 */
{"NONE"}, /* line 947 mail section 52 */
{"NONE"}, /* line 948 mail section 53 */
{"NONE"}, /* line 949 mail section 54 */
{"NONE"}, /* line 950 mail section 55 */
{"NONE"}, /* line 951 mail section 56 */
{"NONE"}, /* line 952 mail section 57 */
{"NONE"}, /* line 953 mail section 58 */
{"NONE"}, /* line 954 mail section 59 */
{"NONE"}, /* line 955 mail section 60 */
{"NONE"}, /* line 956 mail section 61 */
{"NONE"}, /* line 957 mail section 62 */
{"NONE"}, /* line 958 mail section 63 */
{"NONE"}, /* line 959 mail section 64 */
{"NONE"}, /* line 960 mail section 65 */
{"NONE"}, /* line 961 mail section 66 */
{"NONE"}, /* line 962 mail section 67 */
{"NONE"}, /* line 963 mail section 68 */
{"NONE"}, /* line 964 mail section 69 */
{"NONE"}, /* line 965 mail section 70 */
{"NONE"}, /* line 966 mail section 71 */
{"NONE"}, /* line 967 mail section 72 */
{"NONE"}, /* line 968 mail section 73 */
{"NONE"}, /* line 969 mail section 74 */
{"NONE"}, /* line 970 mail section 75 */
{"NONE"}, /* line 971 mail section 76 */
{"NONE"}, /* line 972 mail section 77 */
{"NONE"}, /* line 973 mail section 78 */
{"NONE"}, /* line 974 mail section 79 */
{"NONE"} /* line 975 mail section 80 */

- 208 -

FX-BBS Installation and User's Guide


FX-BBS Program Registration:

Upon registration, floppy diskettes containing copies of the most
recent versions of the FX-BBS program and utilities, along with
documentation, will be sent to you. No manual other than the one
included on diskette is provided. A version of the program
compiled to use the 80186/80286 instruction set is provided,
along with a version which employs overlays. Registration also
entitles the registering individual (non-business/noncommercial)
to receive a $15.00 referral fee when other new users register
and mention them as the source of the program.

Two forms are provided for your use on the next pages, one for
registering the program, and another for obtaining the source
code. You *must* include these forms as required when
registering the program.

The registration fee is $85.00, which includes unlimited updates
to the program via download as well as technical support through
BerthaBoard BBS. This fee also includes a site license for
noncommercial users of the program. The registration fee for
business or other commercial users of the program is $85.00 for
the first copy of the program, and $25.00 for each additional
copy of the program to be used when supporting a multi-line BBS.

- 209 -

FX-BBS Installation and User's Guide

I/we hereby request registration of the FX-BBS program. I/we
agree not to distribute the FX-BBS program in registered form to
other persons, nor to make the registered version or registration
program available on a computer Bulletin Board or in any other

I/we understand that ownership of the FX-BBS program remains with
the author, and that registered versions of the program are for
use only by the registering person or firm. I/we understand as
well that, when the program is used for non-business purposes,
the program may be used on all systems I/we personally own, and
no additional site license is required. It is also understood
that business or commercial users of the FX-BBS program are
required to pay $25.00 for each additional copy of FX-BBS in use.

Version Number Being Registered: ____________

Number of Copies to be Used: ________________

Name: _______________________________________

Business Name: ______________________________

Address: ____________________________________

City: _______________________________________

Phone: ______________________________________

Signature: __________________________________

Date: _______________________________________

Mail the completed form and check or money order for $85.00 to:

Kenneth R. Roach
PO Box 2271,
Manteca, Ca. 95336


- 210 -

FX-BBS Installation and User's Guide

Obtaining the Source Code:

The source code for this program is available only to registered
users. The cost is an additional $150.00. This is felt to be a
nominal fee and is requested for two reasons. First, revenues
received from this program are not likely to be that great. This
isn't a commercial spreadsheet or word processing program
available at the local software store for example. Its appeal
will be to a smaller audience. Secondly, and most importantly,
the fee is charged to discourage casual hackers (vandals) from
poking around too much.

To obtain the source code, you must first be a registered user.
If registered, or if you are registering at this time, you then
must include the form on the following page, correctly filled
out. This form must also be notarized.

If you are not registered, or fail to include the form as
requested, additional delays will result.

- 211 -

FX-BBS Installation and User's Guide

I hereby request the source code for the FX-BBS program on 5 1/4"
IBM PC 360K diskettes.

I agree not to distribute the source code in any form, modified
or as is, to other persons, nor to make it available on a
computer Bulletin Board. I understand that I will not own the
source code or any rights to it, that the source code is for my
personal use only, and that I alone will be responsible for the
correctness or lack thereof of any changes made to the program by

Name: _______________________________________

Address: ____________________________________

City: _______________________________________

Phone: ______________________________________

Signature: __________________________________

Date: _______________________________________

Mail the completed form and check or money order for $150.00
(plus registration as required) to:

Kenneth R. Roach
PO Box 2271,
Manteca, Ca. 95336


- 212 -

  3 Responses to “Category : BBS Programs+Doors
Archive   : FXB31.ZIP
Filename : FX-BBS.ASC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: