Category : BBS Programs+Doors
Archive   : FXB31.ZIP
Filename : VERS31C.DOC

Output of file : VERS31C.DOC contained in archive : FXB31.ZIP
Version Description File for FX-BBS Version 3.1C
June 15, 1990

A. Changes to Version 3.1C:

For the most part, this is simply a 'cleanup' version of the program.
A few new features have been added, but generally, changes concern
bug fixes for the most part.

1. Added a bit of screen output displayed during the process of searching
for new messages, and in the statistics functions which search for most
popular downloads, and top uploaders and downloaders. The purpose of this
is simply to indicate that some activity is occurring when processing
unusually large files.

2. Corrected a minor problem with internode chat.

3. Deleted logic which displayed the total number of messages for all
message sections at caller logon to cut down on delay and disk activity.

4. Found a recently introduced error in management of the size of the
file FX-BBS.LOG. Please check any existing FX-BBS.LOG file for integrity
by listing recent callers using the statistics function. If data output
by statistical functions looks incorrect, delete the file FX-BBS.LOG and
it will be rebuilt.

5. The EDITUSER program has seen several changes, large and small. Found
a few problems relating to printer output in the program, then gave it to
Peter Koch who performed a general code walkthrough, correcting any problems
he found and added a few new features. From a user's viewpoint, some of these
changes will not be obvious but you might notice slight speed improvements
in some functions.

- Corrected minor problems associated with purging users who have not
called since a particular date. A wierd little bug was discovered
that prevented the function from working correctly.

- Added capability to abort printing of user file. When using the LIST
option with EDITUSER, you are now able to abort the printing process at
any time.

- Added capability to pack the user file. Over the course of time,
deleting user records and purging old users will result in empty
records in the user file. Of course, FX-BBS will use these empty
records first when adding a new user, but you may feel that you have
too many blank records in the file. There is a new PACK option that
will scan the user file and remove all empty records. I don't
imagine that you will have to use this option very often, but it is
available when needed.

- Added capability to sort user records. A new option, SORT, is now
available that will allow you to sort the records in the user file on
one of seven fields. These fields are:

1) User Name 5) City/State
2) Password 6) Number of Uploads
3) Subscription Date 7) Number of Downloads
4) Last Date On

When the sort process is complete, you will be able to print the sorted
file, and make the sorted file permanent. Making the sorted file
permanent will replace the existing user file with the sorted file. You
might use this option in the case where you sort by Last Date On, in
which case, the records of your most recent callers would be at the beginning
of the user file so that they will be found sooner.

Ideally, the user file should be packed before it is sorted so as to
prevent all empty records from being shuffled to the beginning or end of
the file, as is possible. Of course, you can manually pack the user file
before sorting it by using the PACK option. The sort process will,
however, remind you that the file sould be packed first and offer to do so
prior to sorting.

All sorting is performed on disk using a quick-sort algorithm. It has
been optimized for speed. Benchmarks have been performed on a 25MHz
80386 computer with a 26ms hard disk. A 450 record file in fairly
random order will be sorted in 15 seconds. Of course, sorting time
will vary from machine to machine depending on cpu and disk type. If you
start a sort operation and then decide it will take too long, you do have
the option of aborting the sort. When a sort is aborted, you will not be
given the option to print the sorted file or make it permanent.

6. Observed that noise was sometimes output at the start of a caller's
session, and that often callers call with modems that have long delays
built into them before issuing "CONNECT" messages and such. The upshot
of this latter situation is that they end up having to bang on the
keyboard ultimately, and miss the initial question, "Do you want graphics?".
I don't really like having to deal with this sort of problem, but feel
that I should. The fixes added for these problems are first, addition of
a five second delay at logon when the program is not being re-entered from a
door, when no front-end program is in use and when the caller isn't logging
on locally form the keyboard, and secondly, addition of some calls to empty
the transmit and receive buffers following the delay. I'm again, not
thrilled with the initial five second delay added, but feel it was

7. Found and corrected a bug that sometimes caused Fidonet file requests
generated by FXMAIL to be dishonored by the called system.

8. Corrected a problem inadvertently introduced in the last version,
which caused logic involved in searching for new files to fail part
of the time.

9. Logic allowing usage of a portion of screen ram for internode chat
support has been disabled. This logic relates only to multiline
systems, and proved to be unreliable with some monitors and software.
To support internode chat, you _must_ now use the FXCOMM or FXCOMML
TSR programs.

10. Corrected a long standing problem which prevented FX-BBS from running
on many XT class machines. The source of this problem was quite elusive,
and proved to be the result of a change to the compiler introduced by
Borland in Turbo-C version 2.0.

11. Corrected problems relating to the ability of doors to be exited to.

12. Modified logic for checking dates and times of 'new' messages to
improve the accuracy (removed some inaccuracies).

13. At the moment, it appears that Peter Koch is going to become a partner
in the development and support of FX-BBS. Peter is a fairly good programmer,
and fairly diligent as well. While he's only been using FX-BBS for some
6-7 months, he's been a sysop for some time, previously running RBBS. He
can probably offer assistance to anyone who might be considering such a
conversion. The partnership has not yet been completely finalized, but
does appear as if it will be. Peter will be available to support FX-BBS
via his BBS system, at 805-937-4512 (1200-14400 HST). I will continue to
offer support as well, of course.

B. Hardware Available from us for Users of FX-BBS:

Certain types of different specialized hardware are often desirable for
use with FX-BBS, and may be difficult to find depending on where one may
look. While not engaged in the full time sale and support of systems and
such, it seems reasonable to offer such hardware to users of the FX-BBS
program as a part of providing customer support. The hardare in question
includes modems, serial cards, UARTS and Local Area Network hardware and
software. These types of products may be obtained directly from us by
registered users of FX-BBS, at varying costs. For the most part, costs
are not listed herein, since they fluctuate, and can vary according to
quantity required. Call either my own system at (209) 239-9853, or
Peter Koch's system at 805-937-4512, and leave a message or comment to
obtain current costs.


A wide variety of modems are available, and there's no real reason why a
user should not obtain them locally. High speed modems in particular, are
not offered here, since usually, one can find a manufacturer offering a
sysop discount plan which is better than any retail operation might be able
to offer. A few inexpensive and reliable 300-2400 baud units have been
examined however, and are recommended or provided as follows:

EasyData 2400: Internal versions of this modem are available from the
manufacturer, but the unit we offer is a fairly low cost
external 2400 baud modem. External 2400 baud modems
usually cost significantly more than an internal 2400
baud unit. The EasyData modems are fairly average as
low cost modems go. There's no MNP-5 or anything such
as that. It's simply an average, serviceable clone.
The unit becomes outstanding when the cost of it is
factored in. Cost will vary slightly, but at the
present time, is around $100-120, quantity one. Better
modems might be had, with MNP-5, faster baud rates,
the ability to function synchronously or asynchronously
and so on. That is, one can spend as much on modems as
one wishes. There's always a dealer somewhere willing
to sell things for as much as possible. The EasyData
on the other hand is simply a low-cost, no-frills,
servicable modem. The unit has a one year warranty.
These modems are manufactured by GCH Systems, in
Mountain View, Ca. Remember, external modems will
require an internal serial card. This adds to the
overall cost, but eliminates concern over the types of
UARTs which may be used. Call for current price.

CompuCom 2400. Internal only, supports four separate UART port
addresses as well as IRQs 2-5, five year warranty.
These modems must be obtained directly from CompuCom,
and only a recommendation is provided here. Byte
Magazine reviewed their "plain" 2400 baud unit a while
back, and found it to be serviceable. That's different
from "state of the art" or such. However, CompuCom
offers another modem which they're quite proud of, with
something they call "DIS". This is a noise canceling
sort of thing, and I think, patented. I've tried this
modem, asking callers to comment on any improvement or
deterioration in their connections. Not all callers
experience line noise, but a few who do have reported
an improvement in the quality of the connection. Must
work! CompuCom has pending, two additional modems which
you might want to look at. One is a 2400 baud unit
with MNP-5, the other is a 14400 baud unit with MNP-5.
They're talking a really good offer for sysops on
the 14400... Their 14400 won't talk to anyone
else's, but the suggested list on it is $299, with a
far lower proposed sysop price. You might want to
look into it. All CompuCom modems at present, are
internal. You can obtain them directly from CompuCom
in Sunnyvale, Ca.

2400 baud only: $95
2400 baud DIS noise correction $119

Note: CompuCom modems use an ASIC to emulate UART
functions. Because of this, it is not possible to
upgrade to the NS16550 UART, a consideration for
multi-line installations.

Standard Serial Cards:

We can supply standard serial cards which can be configured to support
COM1 through COM4 as required by FX-BBS. Current costs are around $40 or
so for a card equipped with a single UART, usually an NS16450. The cost
is higher with dual NS16550 UARTs installed and the appropriate cables
and such. All cards provided will have socketed UARTS so that you
can upgrade them at some point or another as you wish, should you not
request them with NS16550 UARTs to begin with.

You of course, can probably find serial cards like these in your own
neighborhood for about the same cost, and this might be the preferred way
to obtain them. An important consideration however, is that many clone
type cards are being introduced which emulate the UART(s) with whatever
weird sort of chip might be at hand. Buy these or not as you see fit, but
you will not be able to use 16550 UARTS in them at any time. Note too that
when using internal modems, serial cards such as those in question here
are not required for them. On the other hand, when using external modems,
internal serial cards are required.

Enhanced Serial Cards:

"Normal" serial cards and many "normal" modems can be used for supporting
COM1 through COM4. That is, for supporting four modems from a single
system. To support more than four lines in a single computer system, FX-BBS
will require you to use a serial card which can be configured to support
more than the standard number of IRQs, and allow the UARTs to be placed
at more than the normal four addresses. The matter of expansion slots in
the system also becomes a factor. Each internal modem will require one
slot. Serial cards however, typically offer two COM ports or more in each
slot. Using such cards, four slots are required to support eight lines.

Finding a serial card which is capable of supporting more than COM1 through
COM4 can be a difficult task. It is unlikely that you will find such in
your neighborhood, unless you live in NYC or Chicago or such and really
dig around looking. You may be able to find such mail order, again if
you look carefully.

A 16-bit serial card which provides two ports, supports about a dozen
different IRQs and all sorts of different UART port addresses has been
located and is made available to users of FX-BBS. This card is offered
only with the NS16550 UART, which adds a bit to the cost (the card normally
comes with NS16450 UARTs). One such card, in conjunction with two other
"normal" serial cards, would allow for six lines to be supported from a
single system. Two such cards then, again with two other "normal" serial
cards, would allow a total of eight lines to be driven by a single system.

Quite simply, these are very nice cards, and as configurable as you
could want. High quality, and hard to go wrong with. But they're not
inexpensive, and it's hard to justify putting four of these things into
a system when the previously mentioned "normal" cards can be used for
some of the ports required, unless perhaps you've already used all your
"normal" serial ports for other devices, such as a mouse, printer or what
have you. And remember too, that these cards will not work in XT class
systems. If you're interested in this card, leave a message or comment
for Peter or I on the appropriate BBS. Or should you wish, you can obtain
this card directly from Qua Tech, with or without NS16550 UARTs. Their
cost, as of June 1, 1990, was $200 for a board equipped with NS16450s,
and $220 for the same board equipped with NS16550s.

NS16550 UART:

Subject to availability, we can provide these to you. The virtue of
using an NS16550 UART is simply that it provides buffering of interrupts,
thus allowing the system greater flexibility in servicing them at
different times, thereby improving performance noticeably in multiline
systems, or in systems which are shared with a local non-communications
program. While this UART is recommended on any system which is being
used in a multitasking manner, it is highly recommended for 80386 based
systems running in virtual 8086 mode, due to the amount of time which
can be required to service interrupts in that environment. Before asking
for one, be certain your modem or serial card is socketed to accept one.
The NS16550 is a plug in replacement for the NS16450 or 8250 UART, so if
you find chips such as these on your modem or serial card, the 16550
should work. Cost will vary, but can be expected to be on the order of
$15. A couple of support chips may be required if you're adding the
16550 as a second serial port to a card which previously provided only
one port.

Local Area Networks:

LANs are typically available in most medium and larger cities across the
country. Different types of LANs may be had, and at different costs.
The categories available include Token Ring, ArcNet and Ethernet
configurations, as well as various proprietary configurations.

Artisoft's LAN products are recommended as well as made available for
purchase by users of FX-BBS. Artisoft's Lantastic system is a low cost
true peer-to-peer network. It has been reviewed in Byte magazine, as well
as several times in PC Magazine, where it has often been the "editor's
choice". You should be able to find such reviews at the local library.

Lantastic is a very simple system to use, and works very well. The file
server portion of the Network Operating System (NOS) is actually a
multitasking program. Any system on a LAN can be configured as a file
server system, and multiple file server systems can be specified easily
(type "server" on any system which needs to be one). File server software
is essentially a TSR, and requires about 40Kb of memory as a minimum.

When a given system has been designated as a file server, any remote
system on the LAN may connect to that system, and use any printers or
disk drives pretty much as if they were physically installed in the
remote system. One can for example, "pretend" that drive D: on a
file server system is drive F: on a remote system (or drive C:, for
that matter). Following this, one can change to drive F: on the remote
system as easily as one could change to drive A:, and then change
directories and run programs located on drive F: as required. Again,
however, drive F: in this case is actually located on the file server
system. In the LAN system used to develop FX-BBS, a single tape drive
is installed in one system. That tape drive is often used to backup
other systems connected to the LAN in the manner described here
("pretending" a remote drive is actually installed locally).

While a file server system's drives and printers may be being accessed
by remote systems, the file server system continues to be available for
use as a normal Dos system. That is, since the NOS is a multitasker,
it can run in the background. The Dos prompt continues to be displayed
on the file server system, and one can run programs there as one normally
would. One can edit files, run FX-BBS, or whatever, though when this is
done, it can tend to degrade performance at the remote systems when
they are accessing the file server's devices. On 386 equipped systems,
it is sometimes possible to run both the Lantastic file server program as
well as DesqView, though this is not usually recommended, and can cause
problems depending on hardware installed in the file server system. On
286 or 8088 based systems, it is not possible to run both Lantastic and
Desqview at the same time.

For small installations running FX-BBS, involving from two to four
systems, or say, 4-6 telephone lines, Artisoft's proprietary 2mbps LAN
package is adequate and cost effective. 2mbps doesn't sound all that
fast, but really can be. You need to keep in mind that the speed at
which a LAN is rated is the AGGREGATE speed of the LAN cable system
as used by the LAN protocol. No single LAN card for example, can drive
10mbps of data across an Ethernet LAN, even though Ethernet is rated at
10mbps. To actually place anything close to 10mbps of data on an Ethernet
LAN would require several systems, and even then, 10mbps couldn't really
be delivered due to technical considerations. It's also the case that no
single system can place 2mbps of data onto Artisoft's slower LAN, nor could
three systems. Systems won't usually get in each other's way until four
or more systems are connected and active, and even then, not often. Each
LAN card in this configuration is also equipped with its own Z80 processor
and memory, helping speed things along. For small installations, or for
persons wanting to simply share peripherals among multiple systems, this
is an excellent choice.

For larger installations, Ethernet is recommended, which has a bandwidth
of 10mbps. Artisoft's slower LAN may often prove acceptable, but the
rating of Ethernet is after all, five times faster, and it is the case
that the Ethernet cards will be able to place more data each second onto
a LAN than the slower cards could. Starting with Ethernet may also be
justifiable if you're really certain that you'll need the greater
bandwidth in the future (assuming you'd want to avoid later upgrade costs).
Artisoft's Ethernet cards are 16-bit cards, but are designed to allow
usage in an 8-bit slot. A sufficient number of IRQs are supported by
these cards so as to not interfere with any modems installed. Data
transfer rates which might be achieved will vary depending on the systems
in use. Rates approaching those of RLL disk controllers have been
observed when using Compaq 386/25 systems equipped with ESDI drives
(81KBytes per second during a LAN Xcopy). For an 8mHz AT clone, a rate
of 42KBytes per second was observed for the same operation.

Artisoft's products may be available from a dealer in your area. You can
call Artisoft in Tucson, Az, to inquire about the nearest dealer. A
two-node Ethernet starter kit (two 16-bit Ethernet cards and the required
software) has a list price at present, of $725, with each additional card
listing for $349. A similar 2mbps package from them has a list price of
$525, with each additional card costing $249. Call either Peter's system
or my own and leave a message of comment to obtain our current price.

You are not, of course, restricted to using Artisoft LAN products, nor
even Ethernet, with FX-BBS. Novell products might be used, and while
not tested, there should be no reason why Token Ring and ArcNet wouldn't
work. Generally, anything supporting NetBIOS may be considered.

C. Documentation Changes:

Documentation for FX-BBS has not been revised for the current version of
the program, but will be for version 4.0A. In the meantime, it seemed
apporpriate to include here, a few general sorts of changes planned for
the next version of the documentation.

1. Registration Costs: Registration costs have been lowered for commercial
use of FX-BBS. The documentation will read as follows:

Registering FX-BBS:

Non-business use of FX-BBS: This includes any installation where the
system is run by a private individual and the system is not used to
support or operate a business. Additionally, callers must not be
required to pay any access or subscription fee to make full use of the
system in question (this includes only systems requiring payment; donations
which might be made are not included here, so long as again, such donations
are not required). Charitable organizations are also classified as non-
business users, so long as they are again, charitable, and are nonprofit.
In these cases, a one-time fee of $85 is required and allows unlimited
usage of FX-BBS to support as many lines as desired. Should the user
later begin using FX-BBS to support a business, or require callers to
subscribe, then that person's unlimited license is no longer valid and
FX-BBS must be licensed under the terms described for business use

Registered non-business users are also provided a referral fee. That is,
new users registering FX-BBS who list a previously registered non-business
user as the person who provided them with FX-BBS will cause that person to
receive $15 for the referral. The referral fee offered sysops using FX-BBS
applies only to persons who maintain themselves as non-business users of
the program.

Business usage of FX-BBS: Persons using FX-BBS to support or conduct
business, or in a system where callers are required to pay any form of
access or subscription fee (the key word is "required"), must license
the program as follows:

Single line installation: $85
Two to sixteen line installation: $195
Seventeen to thirty-two line installation: $295
Thirty-three lines and greater: $395

3. A revised essay on multiuser considerations: Previously, the
documentation has been somewhat wishy-washy in describing exactly how
many lines one can expect to support in which situations with what
hardware. I've done a bit of analysis recently to try and pin this
matter down a bit better. I need to double check all my numbers, but
will include here what I've come up with thus far since it may be

Multiline Timing Information, or, Waiting for Godot:

Ah, high performance! There's nothing quite like the thrill of seeing
your own system churning away at 33mHz, talking on a bunch of modems
connected at 38,400 baud, while driving a 1024x768 graphics display
and recalculating a spreadsheet in the background. Nothing quite
like it, because you suddenly realize you need a 100mHz cpu... Things
are running reeaaallll slooowwwww. It's great to say that one can do
all this sort of stuff, and on some level, it's true. Sometimes. I'm
certain though, that you realize you're not going to do all that stuff
on a Commodore 64, don't you? Read on, and we'll discuss reality.
Just a bit.

FX-BBS is again, intended to operate well in a multiuser environment,
specifically, with the DesqView and QEMM programs. Every attempt is
made to make the program as flexible as possible, including allowing
you to run door programs as well as external file transfer programs.
Such programs as these are of varying quality. Some external programs
are really quite good. But others may only barely run when one modem
is being supported. Some give the appearance of running, but weren't
written with 386 processors in mind and will crash the moment you turn
your back, though it's hard to really pin blame sometimes. After all,
the screen is either completely cleared, or has all sorts of crap on it
with some of it blinking, and the caller hung up long ago. Other
external programs weren't written with multitasking in mind, and so use
an awful lot of cpu time just waiting for things to happen, such as a
character to arrive at the com port, or for a key to be depressed, and
while doing so, preventing other programs from running as well as they

While FX-BBS makes every effort to allow multiple lines to be supported
and provides several hooks so that external programs can be used, it is
important to realize that the number of telephone lines (users) which can
actually be supported well will vary depending on first, the baud rate of
*each* line in use, second, the overall speed of the system (clock speed as
well as drive speed and such), and third, the kinds of external programs
and BBS activities you might be trying to let callers access. In a
multiuser installation, all of these things must be juggled "just so",
or performance will suffer (and callers will notice).

Consider a reasonably fast disk drive. We'll say a drive with a 19ms
average seek time and a transfer rate of 750,000 bits per second (RLL
transfer speed, as well as close to the transfer rate of a single Western
Digital WD8003 8-bit Ethernet card). If eight users were all searching
for new mail, there would be heavy disk activity indeed, perhaps the
heaviest load generally encountered. So the seek time can be multiplied
by the eight users, to now be at an average of 152ms. The transfer time
can be divided by the eight users, or about 93,000 bits per second each.
Now, it's not anticipated that a condition such as this would occur often,
but it could occur none-the-less. Imagine what it would be like if instead,
you were using a Seagate ST225 drive. The maximum transfer rate for an
MFM drive would be 500,000 bits per second, so each of the eight callers
would get only 62,500 bits per second, or about 7,800 bytes, less than
the size of some messages! Worse, a Seagate ST225 usually benchmarks
with a transfer rate of about 72ms, so eight callers would result in an
average seek time for each of 576ms, more than 1/2 second! Lest you
might think that's still "fast enough, sorta," consider a search of 200
messages for a specific subject. Even assuming that we could get one
message per second into the system, we're talking three minutes and 20
seconds at the least. Add a little overhead for actual processing of the
messages, and we're easily looking at four minutes. That's a *long*
time. If you don't think so, go watch a clock for four minutes. Now,
what if you've got 2,000 messages to search?

It seems all of a sudden, that FX-BBS's ability to multitask is being
faced with reality and coming up short! What to do, what to do??? Well,
a couple of things might be done. FX-BBS *can* multitask, and does it
reasonably well. Clearly though, it requires powerful and relatively
fast hardware to do it. To start with, don't use that Seagate ST225
mentioned in the previous paragraph. That was simple, wasn't it? You
might for example, run an ESDI or SCSI hard drive. Spec sheets for these
kinds of drives usually report transfer rates in excess of 10,000,000
bits per second, 20 times faster than the ST225, or more. Try to get a
drive with a lower seek time. If running lots of lines on a LAN talking
to a file server, you might consider installing two LAN cards in the
server, for twice the LAN transfer rate. Perhaps some things could be
put into a ram disk, such as menus.

You should of course, reduce the amount of usage each caller can impose
on the system as the number of callers to be supported increases. This
might be done by having local copies of menus and such, in a LAN config-
uration, and/or by reducing the maximum number of messages available as
the number of callers increases. If for example, you make 2,000 messages
available to two callers, you might make only 1,000 available for four,
or 500 available for eight. That is, attempt to strike a balance between
resource needs and callers, based on the number of callers to be supported.
Yes, this is a limitation, of sorts, of the FX-BBS program. And it's a
limitation of any other program as well. Resources are resources.
Regardless of the software you use, you only have so much power. Eight
users searching 2,000 messages is eight users searching 2,000 messages.
Thirty-two users searching 2,000 messages is thirty-two users searching
2,000 messages. More simply, bandwidth is bandwidth, *regardless* of
the software being used. Bring more system, and balance the need for
its resources, and things will work better.

But wait! We've only talked about disk drives so far. We really need
to talk about modem and processor speeds too. We need to try to
understand better, exactly what's happening when you draw the GIF file on
screen to ooh and ahh at, while you're performing that spreadsheet
recalculation in the background. With four callers online...

A 2400 baud modem is capable of delivering about 2,400 bits per second.
A byte is composed of eight data bits, along with one stop bit. For
simplicity, we'll say here that a 2400 baud modem can deliver about 240
bytes of data each second. We can also divide other baud rates by ten
to estimate the number of bytes per second which will be delivered in
those cases. So 1200 baud callers will process about 120 bytes per second,
9600 baud callers would process about 960 bytes, and callers at 14400
would present a load of 1440 bytes each second. Other modems communicate
at different and varying rates. US Robotics' HST modems, for example,
can be "locked" at baud rates of 19200 and 38400. At the speed of 19200,
at most, 1920 bytes per second would be processed. The HST can't really
deliver data at 38400 baud, even though it may be talking to your
computer at that speed. Through data compression and such, HSTs are
capable of going at about 25,000 baud (more or less, and for simplicity,
let's save the discussion of the definition of "baud" vs. "bits per second"
for another time). In this case, characters processed per second would
run at about 2500. At that speed, a system with a single HST would be
processing more than ten times the data which would come from a single
2400 baud modem. Hopefully, that difference is enough to get a 'hmmm'
started in your mind...

FX-BBS always uses interrupts to receive data. The program will also
use interrupts to transmit data when you set communications optimization
to a nonzero value. "Polling" for data from the Comm port instead,
would represent less overhead to the system. Due to the varying types
and durations of activity in a given system (disk reads, screen updates
and so on), polling cannot be used with any reliability for receiving
data. The use of interrupts to transmit data in the DesqView environment
is also faster than polling would be (that is, "brute force" stuffing of
data into the UART), since interrupts can occur at any time and so data
can be transmitted any time, while the "brute force" logic could only be
done during time slices when the program (or any copy of it) was actually
running. Think about this and you'll see that you really shouldn't run
under DesqView or DoubleDOS at all, unless using transmit interrupts.

The time required by FX-BBS to process a single interrupt on an 8086 is
on the order of 125 clock cycles (exact number can vary in the future
depending on code changes, as well as subtle differences between different
processors). On an 80286 equipped system running four copies of FX-BBS
(about the most which can be accommodated on a 286 system) servicing 2400
baud modems, we can see that on average, 120,000 clock cycles will be
spent handling interrupts, whether for transmit or receive (240 characters
per second, times 125ms for each, times four modems). This number
can be compared directly to the clock speed of the cpu. An 8mHz AT
system has available, 8,000,000 clock cycles each second, and four
2400 baud modems running at full speed then, could require 120,000 of
those 8,000,000 cycles for interrupt processing. If the system's clock
runs at 16mHz, FX-BBS would still require 120,000 cycles for the four
modems (their speed hasn't changed), but there would be many more clock
cycles left for other kinds of processing. Driving four HST modems
on the other hand, each going at 2500 characters per second, will
require 1,250,000 clock cycles, a much larger percentage of total cpu
time available.

On 80386 equipped systems, things aren't quite so simple. When running
DesqView and QEMM, each copy of FX-BBS will be running in "virtual 8086"
mode. Many "fake" 8086 cpus can be established, with each thinking it's
the only task in the system. The 386 chip supports much of the activity
required for this internally via hardware functions, in essence, pretending
that all programs reside in the same area of memory. Clearly this can't
be the case in fact, so the cpu must also devote some time to accommodating
this idea. A small program is also required to manage virtual 8086
programs (a part of DesqView or QEMM, in this case), and this represents
additional overhead (non-BBS activity). In addition to "simple" 80386 cpu
support, some software somewhere must be running to manage the user inter-
face and can take different amounts of time depending on what it's told to
do (swapping all interrupt vectors with every task switch, for example, or
temporarily moving executing programs to disk, or displaying output from
multiple programs in little windows on the same screen instead of being
told to let each running program have the entire screen, or worse, mixing
text and graphics). Many of these kinds of things are under your control,
and depending on how you configure it all, will impact any callers to
varying degrees.

Shoot. I've digressed. Let's get back to interrupts and clock cycles.
On 80386 systems running QEMM, interrupts can occur at any time, just as in
any other system. However, interrupts are vectored through 80386 protected
mode code and tables before arriving at the actual interrupt routine. If
the interrupt handler is not in the currently executing virtual 8086
(whether the interrupt handler was loaded before or after DesqView was
started), the cpu must do a bit of fancy work before switching to the
required handler. This will be the case any time a system is running in
virtual 8086 mode, that is, anytime someone boots with the line "DEVICE =
QEMM.SYS" in their autoexec.bat file, regardless of what type of programs
they might be running, and regardless of whether DesqView is running or not.
Intel manuals indicate that the overhead time for this can be up to about
314 clock cycles. All Intel estimates of interrupt and exception overhead
in the virtual 8086 mode, regardless of activity, are greater than 300
clock cycles. QEMM is a great product, highly useful, and I'd hate to
run without it. But if you've loaded QEMM just to get emulation of EMS
memory, you're getting this additional interrupt overhead as a "bonus,"
whether the interrupt is coming from a modem or anywhere else. When your
program reads the disk drive, it generates an interrupt. To access
the disk read code, that interrupt must again be vectored through the
virtual 8086 logic. From the time you first see the Dos prompt, you're
in virtual 8086 mode. Wow, huh?

So now, instead of taking only 125 or so clock cycles to service interrupts
for a 2400 baud modem, the time required could conceivably be up to 440
clock cycles, almost four times longer! To service four 2400 baud modems
now requires some 422,000 clock cycles. Servicing eight such modems (which
we can do on a 386) requires 844,000 clock cycles.

On a 16mHz 80386, we could be using almost 1/16th of the processor's
time to service interrupts, assuming only 2400 baud callers and all
lines active at the same time. Doesn't look too bad, huh? No, not bad
at all. Not great either. Of course, were the system in question a
25mHz system, it would look better, since the system must be doing much
more than just servicing interrupts (in this case, we would be using only
1/25th or so of the system's total clock ticks available). Remember that
for eight users, each user is getting to run only 1/8 of each second, and
that's not really a great deal of time! If a 16mHz system has some-
thing like 15,000,000 clock cycles left for accessing files, switching
tasks and such, then that's about 1,875,000 cycles for each caller's
support activities. If a 20mHz system driving the same eight modems
would have 19,000,000 cycles left over, then that's 2,375,000 cycles
left for each caller's support requirements. A 25mHz system would have
24,000,000 cycles free, or 3,000,000 cycles for each caller, and a 33mHz
system would have 32,000,000 cycles to devote to other activities, or
4,000,000 per caller. For comparison to all these different numbers,
consider that one user on a 4.77mHz XT class system gets 4,770,000
cycles per second to take care of everything they might want to do,
and a 33mHz 386 driving eight callers isn't capable of providing each
with quite that much.

So much for 2400 baud modems, but what if you're trying to drive a bunch
of those high speed modems we mentioned earlier? Let's take the extreme
case of driving modems which will deliver about 25000 baud, or 2500 bytes
each second. 2500 bytes times 440 clock cycles each under DesqView with
QEMM is 1,100,000 cycles to service a single caller's interrupts, more than
the eight 2400 baud callers combined, resulting in the use of more than
1/16th of the resources available on a 386SX alone. Driving two such
high speed modems could result in as much as 1/8th of the system's time
being devoted to interrupts, and trying to drive four modems at this speed
could require 1/4th of the system's time, just to handle interrupts! To
say the least, each of the callers WILL notice one another in such a case.

Yes, the situation would again be helped by going to a faster cpu... The
386SX processor itself, is inherently slower than the 386DX, due to smaller
prefetch queues, different memory bus widths and so on, such that more
of the SX processor's time will be required for anything, be it a disk
read or task switch. It's as if a 16mHz 386SX were really operating at
a speed of 15mHz, compared to the other types of 386 processors available.
A 25mHz system servicing two such modems would have a bit less than
23,000,000 clock cycles left for other things, and a 33mHz system would
have more than 30,000,000 cycles free. Still, you should be able to see
that the higher baud rates will introduce much higher demands on the
system in question, and may or may not be practical. Taking the extreme
case of trying to drive eight modems at 25000 baud, we could consume
8,800,000 cycles per second trying to service their interrupts, or 1/3 of
the clock cycles available on a 25mHz system. Not a good idea, since this
would leave just a bit more than 2,000,000 cycles available for each caller,
and we're trying to drive each of these modems at speeds more than ten
times greater than was required for 2400 baud modems.

Consider using the DSZ program in conjunction with eight such modems...
DSZ is not known for its ability to operate well in a multitasking
environment. Running even one copy of DSZ in a system trying to drive
eight lines would likely result in consumption of more than half the
system's available time. Running two copies might consume as much as
2/3 of the system's time... This would truly be unacceptable. Many of
the processes internal to FX-BBS, while optimized, can require much time.
Should the above situation actually be allowed to occur, and should
one user ask to check for any messages, callers would almost certainly
begin hanging up, if they hadn't already!

A thing to consider when using high speed modems: It's possible that
overhead associated with interrupts can be reduced on 386 systems by
*not* using QEMM (that is, by not running in virtual 8086 mode). When
this is done, the overhead of each interrupt drops back to 125 cycles
for each. 2500 bytes times 125 cycles required each second is 312,500
cycles required per second. Four times this amount (assuming four high
speed modems) 1,125,000 cycles, representing about the same overhead as
one high speed modem operating under virtual 8086 mode. Not using QEMM
however, means that you'll have less memory available for running doors,
or external file transfer programs or such. Of course, you should be able
to see from the discussion above that as the number of modems being
supported increases, the less you'll want to give another program control
of the system, especially if the program in question can require extensive
amounts of processing time.

FX-BBS *does* support up to eight lines per system, and *will* let you
network as many as 100 users together. And FX-BBS *does* support multiple
high speed modems. And FX-BBS *does* support echomail. And FX-BBS *does*
let you run all sorts of doors. And FX-BBS *does* make good use of QEMM.
But clearly there are limits with regard to how much of which you can
expect to run well when and where. Fast hardware, and/or more hardware,
can be required more rapidly when using doors, processing echomail and
so on.

Again, when adding lines, think about what you're asking the system to
do for each caller. If you look at some of the other multitasking BBS
programs around, you'll find that as more and more users are supported,
these programs offer fewer and fewer features, in an effort to keep
resources from getting too bogged down to do anything. Support for
external programs in many cases disappears completely. And just as
with FX-BBS, severe drain on resources will impact each caller. Just
because a manufacturer states that you can run 32 lines on an XT by
adding their custom hardware/modem support box doesn't mean you'd want
to do so. An XT's 4,770,000 cycles per second, divided by 32 users, is
about 150,000 cpu cycles available per caller, without processing any
interrupts from modems. At that speed, the system would be slow even
if everything (and I mean everything: messages, downloadable files,
access lists, *everything*) was memory resident.

D. Things Which May or May Not Appear in Version 4.0A of FX-BBS:

Both Peter and I are working on changes for the next version of the
program. Lots of little things are planned, some of which may or may
not be noticable. However, I can tell you that we're working on addition
of code to support Zmodem file transfers internally, and may include
Jmodem support as well. Beyond this, I can say that several and
substantial improvements are planned for the FXMAIL program, but will
abstain from describing them in detail so that we don't get into a
situation of promising something that doesn't appear... Hopefully,
version 4.0A will appear before the end of the year.

Kenneth Roach

  3 Responses to “Category : BBS Programs+Doors
Archive   : FXB31.ZIP
Filename : VERS31C.DOC

  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: