Fidonews is published weekly by SEAdog Leader, node 1/1.
You are encouraged to submit articles for publication in
Fidonews. Article submission standards are contained in the
file FIDONEWS.DOC, available from node 1/1.
Disclaimer or don't-blame-us:
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them.
Everything here is subject to debate.
Table of Contents
1. EDITORIAL
IFNA and You
2. ARTICLES
Software Tools in Pascal available on Fido 143/12
Exploring MSDOS file structures
Where Oh Where Can that Interrupt Be?
Announcing two new newsletters
Encryption, Public Keys and Otherwise
XMODEM protocol benchmark
3. COLUMNS
Notes from Abroad
4. FOR SALE
DEC 11/23 Minicomputer for sale
Entertainment Software for your PC!
File Security and Secret*File
5. NOTICES
The Interrupt Stack
Higher Education Net proposed
New Host for MetroNet
Orange County is no longer part of SoCalNet
New Version of Rovermsg Available
IFNA? Wazzat? Well, maybe I should explain a bit first.
There's been some idle chatter (idle typing?) lately about
IFNA, but most people probably don't know what it's all
about. For that matter, nobody really knows what it's all
about yet, because it doesn't exist yet. At the moment, it
is nothing more than a dream.
Ken Kaplan and Ben Baker have been coordinating FidoNet
activities for quite some time now. I'm not sure just how
long, since they started doing it before I joined the net,
and well before I started editing this newsletter. In all
that time they've seen it grow from a handful of hobbyists
to a major electronic mail system.
Yes, yes, I'm talking about the FidoNet we all know and
love. You may not realize it, but we (all of us, you too)
are now running an international network on par with the
major commercial nets. We're getting noticed, too. Refer-
ences to Fido and FidoNet are becoming more and more common
in the trade journals.
We're also a public service, now. Those articles about
FidoNet for the deaf and blind weren't just hot air. There
are deaf people right now using FidoNet as a means to
contact the rest of the world.
Even this modest little publication is becoming widely read
among those in the know, much to my surprise. Awhile back
an article here stimulated, in a matter of days, a response
by phone from the president of a major corporation (I won't
say who, except to note that it's a Fortune 500 company),
just to mention one incident. I must admit that I am not
used to having my words quite so widely read, immortal prose
though they may be.
But back to Ken and Ben. They've watched all this grow, and
have been thinking (and worrying) about how to handle it if
it keeps growing. Perhaps I should say "when it grows even
larger", as it shows every sign of growing bigger and bigger
as time goes by.
One thing they saw right off. FidoNet would soon (say about
last Tuesday) get big enough that it would require someone
working full time to hold it all together. This is no sur-
prise to me; I've seen much the same situation in other
groups I belong to. The big question, of course, is how to
finance such a thing, particularly without reducing or
charging for the many services we already enjoy.
Fidonews Page 2 17 Feb 1986
This is where the International FidoNet Association (IFNA)
comes in. The general idea is to set up a not-for-profit
service organization to provide services to FidoNet sysops
and users. There are three main ways that this can be
financed:
1. Voluntary contributions from individuals and corpora-
tions. There is a trickle of this now, and we can
expect it to grow once IFNA is registered as a non-
profit organization.
2. Fees for new services not currently provided, such as
the printed FidoNet magazine.
3. Fees for providing commercial services to outside
companies.
As you can see, they're trying to come up with ways of
paying for our hobby that don't call for coercing anyone
into paying for things they don't want.
Probably all three methods will be used, but the one that
really interests me is number three. One example I've heard
of it is collecting data for market research companies. The
general idea is that participating sysops use the question-
naire ability of Fido to collect the data, which is then
sent to a central collection point that bills the outside
company. Participating sysops get money back, depending on
the amount of data collected. Sysops who don't want to
participate don't have to.
And THAT I like. Nobody is forced to do anything they don't
want, and everybody has a chance to make a few bucks while
helping out. All winners, no losers. That's really the
whole point of IFNA, to figure out ways to benefit everyone
on the net.
Programs From
"Software Tools in Pascal"
Now Available on the
Wyrld Wyrm BBS, Fido 143/12
"Software Tools in Pascal", by Kernighan and Plauger
(Addison-Wesley, 1981, $16.95) is a book on programming
techniques that demonstrates good coding by building up a
set of useful programming tools. These include an editor, a
find-and-replace utility, a text formatter, and a number of
smaller utilities, all useful.
The authors have granted permission for noncommercial use
and distribution of the software presented in the book. A
version of the software, modified slightly to run under
Turbo Pascal, appeared on the USENET (in mod.sources) a few
months ago.
These files, (edited slightly by me to eliminate a few
glaring bugs) are available on my BBS, the Wyrld Wyrm BBS,
Fido 143/12 (408) 263-8134. My BBS run 22 hours per day,
with the two hours between 00:30 and 2:30 taken up by
FidoNet. The file is about 50k long, and can be downloaded
in under ten minutes at 1200 baud.
While the programs are useful in themselves, they're
invaluable as a Pascal source code library. Many routines
that people tend to reinvent (sorting, string searching,
etc.) are right there for the taking.
I should warn you, though, that you'll need the book if
you want to use these programs. The command line syntax,
while simple, isn't obvious, and the person who typed in all
the code left out the comments (assuming that you had the
book in front of you, I suppose). The book is really good,
though, so it's money well spent.
-- Robert Plamondon
Sysop, Wyrld Wyrm BBSs
Fido 143/12
Disks (floppy as well as hard) are formatted or initialized
under MSDOS Version 2.0 to allow fast and convenient access
to files. MSDOS supports several methods of accessing
files. The handle method, the File Control Block method,
and the direct access method through directory and the File
Allocation Table (FAT) search. The handle and FCB methods
require you to access files through the operating system and
their respective function calls, while the direct method
enables you to access files as it implies, directly. To
access files directly, a little knowledge of the way MSDOS
formats the disk is required. MSDOS disks after formatting
contain the following structures in sequence:
o Reserve boot loader area.
o First copy of the FAT.
o Second copy of the FAT (for recovery purposes).
o Root directory.
o Data area.
Utility programs read the reserved boot area where disk
media data may be found. This data provides the program with
information about the device. Typically byte offsets 11
through 29 have been set aside to define all the necessary
attributes required.
Disk space is allocated in the data area only when required
and is accomplished in one allocation unit at a time. An
allocation unit is referred to as a cluster and is represen-
ted by one or more consecutive sectors. A sector is usually
512 bytes. A cluster will contain from 1 to x sectors depen-
ding upon the media. Some typical allocations are:
o Double sided floppies 2 sectors/cluster.
o 10mb hard 8 sectors/cluster.
o 20mb hard 16 sectors/cluster.
This method of storage presents some problems to the user
(especially those running BBS systems) who store many small
files. Consider storing 100 files of text containing ap-
proximately 200 bytes each file on a 10mb hard disk (Like
Fido stores messages). Figuring 8 sectors/cluster X 512
bytes/sector = 4096 bytes per allocation unit. 100 alloca-
tion units would be needed (providing each file only needs
one allocation unit each) at 4K per representing 400K bytes
of storage for 100 files. You are only actually storing 200
bytes X 100 files or 20K bytes of data ( a very big waste of
space). DOS 3.1 attempts to solve this problem by allowing
Fidonews Page 5 17 Feb 1986
the user to define the cluster size. Enough about problems,
back to file storage techniques using the direct method
(reference back Fido news issue).
When information is written to the disk, the system looks
for the cluster that is closest to the beginning of the data
area and available. This criteria can easily be fulfilled
by checking the FAT. The FAT maps every cluster of the data
area and is in fact a large linked list to files occupying
more than one cluster. FAT data is stored 1.5 bytes per
cluster, with cluster #2 defined as the start of the data
area. The first two FAT entries represent system data, entry
3 through X actually map the entire disk. The value of each
FAT entry could be one of the following:
o 000H Unused cluster.
o 002H-ff6H Next cluster of data.
o ff7H Bad cluster.
o ff8H-fffH Last cluster of file.
The root directory is initially built at the time of disk
format. It is a fixed value of clusters depending upon the
size of the media. Each directory entry is 32 bytes in
length and contains information required by the system to
locate files. Since directories other than the root direc-
tory are actual files, there is no limit to the number of
entries they may contain. Reference the DOS manual for a
complete description of the fields of a directory entry.
For now all that you should know is that fields 00-07H
contain the file name, 08-0aH contain the extension, and 1a-
1bH contain the starting cluster number.
The following brief discussion describes file access using
the direct method (assume root directory only):
1. The media data is read to obtain the necessary informa-
tion as to number of sectors, where the root dir starts,
how big it is, etc.
2. The Root directory is read.
3. Each 32 byte entry is scanned until the correct file is
located.
4. The starting cluster number at offset 1a/1bH of that
directory entry is obtained and converted to logical
sector number.
5. X number of sectors per allocation is read to a transfer
address starting at the sector calculated above. (X
sect/allocation unit is a function of the media).
6. Next the FAT map is checked to see if additional
clusters must be read. This is accomplished by conver-
ting the cluster just read from the directory entry to
Fidonews Page 6 17 Feb 1986
an offset value into the FAT. If the 1.5 bytes represen-
ting the starting cluster contains data pointing to
additional clusters, the system will read that cluster.
This next mapped cluster entry will be checked and the
process will continue until the last cluster is read.
The conversion of cluster number to logical sector and
determining the byte offest into the FAT is simple. The
method is written in any DOS manual near the system calls
section. One trick which is not mentioned is that the
formula to determine offset into the FAT table will only
work if you operate on the table as if each byte were an
entry ( that is if you read the table as bytes, and not
words).
I hope this small article has been of some help to the
readers in understanding some of the file storage techniques
of the MSDOS operating system. One example of using this
method of file access is depicted in the public domain 'C'
program DSKRPK.ARC located on Fido 107/29.
I need some help, please. Maybe I am looking at the wrong
elements in my system, but I have had a rash of
communications problems lately.
My system is a PCXT with a Hayes 1200b and fully populated
Quadram Quadboard installed. My comm port is COM2: My
problems is this:
Since installing the Quadboard, I have had problems with
telecommunications. I had installed the Quadram print
spooler and clock device driver. When I would connect, the
modem would return strange baud rate values, such as 20, or
120, etc. I am using Pibterm as a comm program. Removing
the print spooler from CONFIG.SYS solved this, I think.
Now, I occasionally will have connection problems. Connec-
tion is made, the remote tone is audible, but my system
doesn't respond. This is rare and may be an artifact of a
noisy non-Bell long distance service. Modem testing
revealed no problems. Could it be a problem with the clock
driver?
I have removed it from CONFIG.SYS and am only using the
clock setting .EXE file in my AUTOEXEC.BAT. A colleague
thinks it is a conflict between the interrupts used in the
clock device driver and the communications system.
If you have any ideas please let me know. If you know of a
print spooler that doesn't cause problems with communica-
tions, please let me know about it, too.
Two New Newsletters for Fidonet
Fidonet PCNews
and
Fidonet Languages
Fidonews is an excellent way of getting news and information
across the network to both the sysops and users of Fido
boards. The nature of the articles though usually relates
to Fido itself or to BBS's in general. The articles are
also written primarily by sysops, perhaps because of the
restriction of file attaches to users with sysop or extra
privileges. There is nothing really wrong with this focus
of Fidonews, the newsletter serves a very needed purpose in
the network. Something more is needed though.
What I propose is a concept similar to the news groups of
Usenet. I would like to see one or more new newsletters
built from netmail messages instead of from file attaches,
thus making the newsletters more accessible to all users.
The content of each newsletter would be focused on one
specific subject, not necessarily having anything to do with
computers. As an experiment, I am going to try and get the
first of these going from The Ark Tangent. The two
newsletters I'm going to be putting together are Fidonet
PCNews and Fidonet Languages. The first will be concerned
with IBM PC's and clones, while the second will have
programming languages as its focus.
Getting information into the newsletters will be simple.
Send a netmail message to node 137/19 addressed to the name
of the newsletter you are contributing to, either Fidonet
PCNews or Fidonet Languages. Weekly, on Tuesday morning,
the mail for each newsletter will be converted to straight
text and concatenated into a text file to be distributed
across the network. Responses to the messages in the
newsletters could be directed back to the newsletter or the
author of the message, whichever suits.
In order to receive the newsletter on your node you will
need to poll The Ark Tangent (137/19) to pickup an archived
copy of the file. Send me a note requesting one or both of
the newsletters and I'll set you up to pick up the files on
a weekly basis.
Wes Cowley
Sysop, The Ark Tangent
Fido 137/19
------------------------------------------------------------
Fidonews Page 9 17 Feb 1986
Encryption, Public Keys and Otherwise
PART One.
If you know what "Public Key Encryption" is then feel
free to skip to part two.
Public Key Encryption is a special form of encryption
which uses different keys for encryption (or scrambling) of
a message and decryption (unscrambling, the reverse
operation).
The separate keys for each operation have several
advantages. The first is that the encryption key can be
distributed much more easily by less secure means without
compromising the security of future encrypted messages.
Simple knowledge of the encryption key does not enable
decryption of encrypted messages. The decryption key is
required to recreate the original message. For this reason
the encryption key is commonly called the "public key" and
the decryption key is the "private key".
In operation, everyone who wants to receive secret
messages creates their own pair of keys, one private and one
public. The public key is them communicated to everyone who
may want to send them a secret message. Perhaps a central
key distribution center could be established. The private
key is kept secret and never told to anyone.
For example ... Art wants to send Beth a secret message.
He would look up Beth's public key or ask her to send him
one (in the clear). He would then use Beth's public key to
encrypt his message and send her the encrypted message. Beth
receives the message and decodes it with her private key. No
one else can decrypt the message even if they get a copy of
the encrypted message AND the public key. They need the
private key.
In 1978 the CACM journal published a way of doing this
on computers. The system they described has come to be known
as the "RSA" encryption system.
The RSA system has an additional property beyond the
general Public Key Encryption system described so far. With
the RSA system the keys are interchangeable so you can use a
private key to encrypt a message and then only the
corresponding public key will unscramble the message. This
is in effect a "digital signature" which "signs" a message
showing that the encrypted message could only have been
created with knowledge of the private key.
Messages can also be encrypted more than once. For
example you can sign a message with your private key and
then encrypt the result again with the intended receiver's
public key to make a signed, secret message. The receiver
would then need to do the reverse two steps in the reverse
order to get the original message back.
Fidonews Page 10 17 Feb 1986
Even more complex interaction can be used for special
purposes. Articles have appeared on how to play poker over
the phone and how to hold a secret ballot election over the
phone and others.
PART Two.
I have recently completed a Public Key Encryption system
based on the RSA system. It runs on MS-DOS using files for
keys and messages. I am distributing the system as
freeware/shareware. (PKSCrypt 0.0 or 0.01)
There may be some legal or political considerations in
this.
I have heard rumors that this sort of stuff comes under
certain restrictions for export of high tech (or something)
from the USA. I don't think this quite applies to me because
I am exporting the system TO the USA. (I live in Canada).
I have also heard rumors that some intelligence
organization (unnamed) is discouraging public discussion
(let alone utilization) of these systems. I have trouble
believing this because I had no trouble finding all the
information I could ever desire on the subject. There was
even an article in Byte magazine and a couple follow-up
letters.
Anyone who has any solid info on this, I would like to
hear from you. I especially would like to hear directly from
any government organization(s) (in any country) who may
think they are involved.
Interested parties may contact me via Fido node 134/1.
Thom Henderson, node 107/8
System Enhancement Associates
XMODEM protocol benchmark
SEA recently performed a series of benchmarks aimed at
producing a formula for the realistic prediction of file
transfer times. This report presents the results of that
benchmark, along with some conclusions about the XMODEM
protocol and file transfer protocols in general.
The raw data for the benchmark was collected by transferring
files of different sizes at different baud rates over local
phone lines and timing the transfer periods. Files were
transferred between a Fido BBS system and a PC running
Minitel, using the XMODEM file transfer protocol with CRC
error detection. No errors were reported during the
transfers used in the benchmark study. The raw data may be
summarized as follows:
From this data we deduced the following formula for predic-
ting file transfer times using integer variables:
Blocks*1340 Blocks
Time in seconds = ----------- + ------
Baud rate 4
For 50 blocks at 300 baud this would yield 50*1340/300 = 223
seconds, plus 50/4 = 12 seconds, for a total of 235 seconds.
The formula varies with the measured times from being 2.6%
low to being 3.8% high, with an average error of 0.5% low.
This is considered to be within observational errors.
Construction of the formula was primarily based on this
assumption: that file transfer time will be split between
the time required to send the 134 bytes per block that the
protocol requires (we are including the ACK sent by the
receiver), plus overhead time required for each block.
This gives us a variable time dependent on baud rate, plus a
fixed overhead which is independent of baud rate. The above
formula is based on an overhead of 0.25 seconds per block.
(The actual calculated figure was 0.27 seconds, but this is
within observational error.) This overhead time can be
Fidonews Page 12 17 Feb 1986
attributed to processing delays at either end, line "purge"
time, and propagation delays. Propagation delays would be
minimal in a local connection such as this, but would grow
significant in a long distance connection involving
satellite relays (at least an additional 0.25 seconds).
Using a larger block size would help reduce this by reducing
the number of blocks being transferred, as well as reducing
the percentage of bytes used for the protocol. The
percentage of slack time (based on the above formula) at
different baud rates follows:
* Formula not backed by benchmark data at this speed.
As you can see, the 128 byte block size is well suited to
300 baud transmission, and even acceptable at 1200 baud, but
rapidly becomes onerous at higher baud rates.
At first glance a larger block size seems to be an ideal
solution, since time spent on overhead is acceptable even at
the higher baud rates. It is my opinion that this is at
least partly illusory. The above figures are calculated
assuming a zero error rate. A connection that is even
moderately noisy will produce enough "hits" to quickly eat
up any improvements.
Conclusion: If you can't lick 'em, join 'em.
XMODEM protocol with CRC error detection achieves a trans-
mission reliability on par with the best of the major data
network services, but it suffers in transmission time at the
higher baud rates. A solution that would be viable at any
baud rate would be a "sliding window" protocol, something
like the X.PC protocol.
However, X.PC suffers from being excessively complicated,
but it does have the advantage that TymNet has released
sources for its implementation.
It may not be necessary to go as far as a full X.PC imple-
mentation. A sliding window algorithm based on a fixed
block size should not be difficult to implement.
As I'm sure all you sysops have already found out, this Fido
lark consumes a lot of time. On top of Fido I also run the
Compulink User Group, this takes up most of my time, but I
hope to be able to spend more time on the Fido side in the
future. I started Compulink just over a year ago and from
then I have been spending as much time as possible working
for the group, promoting the public domain software concept,
and also running Fido. There has always been more work than
I could squeeze into a day, but, unfortunately not enough
money was coming in to pay for itself. I have therefore
been forced to go out to work in the day to subsidize Fido
and the user group. I have got some pretty big plans for
Fido and the user group (I consider the two inseparable!),
but I don't have the money to see them through.
When I have to go out to work I don't have enough time to
work on both projects. Fortunately I have received a little
press coverage in the last few months and this has brought
in enough money for me to give up my day job. Now I'm not
making a fortune, in fact most of the money that comes in is
going straight out again, this is mainly because I
underpriced all the fees I charge for the user group.
Unfortunately I have to put up my prices for 86, if I don't
do this I wont be here this time next year. It's still a
very good deal joining Compulink, but next year I simply
can't afford to subsidize membership out of my own pocket.
In return for my higher fees I hope to be able to plow even
more of my time into the project and everyone will benefit.
The next major step I will take is to move into a small
office. At the moment I am renting my house and the
landlord won't allow me to install any more telephone lines.
I am running two Fido's concurrently at the moment,
eventually I hope to have about 6 incoming lines, a PSS
data-line and a true multi-user Fido. This will cost a
fortune but I'm going to do it, when I look at the services
offered by Telecom Gold, Easylink, et al; I think, Hell, I
could do better than that!
As Fido gets more and more powerful (which of course it
will!) I will be able to offer subscribers more and more for
their money. What I'm waiting for now is true multi-user
Fido, one that can support more than one input stream. The
RBBS-PC bulletin board software (also public domain) has
just gone multi-user, and I hope Fido will follow shortly.
I am not expecting Tom Jennings to do this, TJ has done more
than his share already, and if you haven't done so already;
I think you should buy the Fido software from Tom as
detailed in the new manual.
Any further innovation has to come from us, the Fido sysops,
Fidonews Page 14 17 Feb 1986
and of course our users. When a Fido clone has been
officially accepted as the public domain Fido we can all
start customizing our own Fido's to our own requirements.
Till then we take what we get and thank our lucky stars that
someone cares enough about what we are doing to make
improvements.
I'm sorry for going on like this, but I thought I'd tell you
all how I feel. What I'm really trying to say is this; OK I
charge people a fee or full access to my system, sure; I
charge people a fee for copying disks. If you read on
you'll see the charges I make, they're reasonable, I've also
sent a copy of the disk magazine I write to all the country
coordinators to do with what they will, I've also sent out
my disk catalog.
I REALLY believe in what I'm doing. If I could afford to do
all the things I've been talking about I wouldn't be writing
all this because I would have already done it! I don't
think it's wrong to charge people for what I'm doing. It's
the only way I can raise the capital needed to fulfill my
plans.
If you have any comments (good or bad) on the above I would
welcome them.
============================================================
FOR SALE
============================================================
FOR SALE OR TRADE!
DEC 11/23 Minicomputer as follows:
11T23 Computer
CPU card has MMU and FPU
(2) RL01 5MB Removable Disk Drives
(4) Disk Packs for RL01
LA-120 "DECwriter" printing terminal
(2) 4 serial port "J" cards
Latest version of RT-11M+ (5.1)
Misc documentation
This computer is about six years old, but was only used for
about a year of that time, so it's had VERY little use.
I'd be interested in:
A cash offer
Trade for:
(1) ea IBM-PC/AT system or
(2) ea DEC Rainbow (w/hard disk) systems or
(1) ea grand piano
This is available in Portland, OR and shipping would
probably be prohibitive (extremely heavy, like a small
refrig), but it's your nickel (FOB Portland).
Contact me for further information:
Doug Forman, Sysop
MacSystem/NW 105/8
(503) 233-6583 BBS
(503) 236-8160 Eves
(503) 357-6151 x2295 Days
Professional quality games include PASCAL source! From the
author of KALAH Version 1.6, SuperDots, a variation of the
popular pencil/paper DOTS game, has MAGIC and HIDDEN DOT
options. KALAH 1.7 is an African strategy game requiring
skill to manipulate pegs around a playing board. Both games
use the ANSI Escape sequences provided with the ANSI.SYS
device driver for the IBM-PC, or built into the firmware on
the DEC Rainbow. Only $19.95 each or $39.95 for both
exciting games! Please specify version and disk format.
These games have been written in standard TURBO-PASCAL and
run on the IBM-PC, DEC Rainbow 100 (MSDOS and CPM), CPM/80,
CPM/86, and PDP-11. Other disk formats are available, but
minor customization may be required.
BSS Software
P.O. Box 3827
Cherry Hill, NJ 08034
For every order placed, a donation will be made to the Fido
coordinators! Also, if you have a previous version of KALAH
and send me a donation, a portion of that donation will also
be sent to the coordinators. When you place an order, BE
CERTAIN TO MENTION WHERE YOU SAW THE AD since it also
appears in PC Magazine and Digital Review.
Questions and comments can be sent to:
Brian Sietz at Fido 107/17
(609) 429-6630 300/1200/2400 baud
Security is a frequent problem with computer use. If you
have a large number of personal computer users who need to
share files how do they insure that only the intended
receiver reads the file?
Secret*File from BYLS Press is a file encryption program for
everyone who wants to share secure MS-DOS files. Secret*File
is menu-driven and easy-to-use. Program requires an IBM-PC
compatible computer with MS-DOS 2.1 or higher, 128K RAM,
and one 5" disk drive.
Examples of uses:
1. Send a coded file to a friend via modem.
2. Upload a coded file. Let a friend download it.
3. Put a coded file on a disk. Send disk to a friend.
4. Send coded messages from field offices to home office.
Secret*File offers the following security features:
1. User name and password required to operate program.
2. User and receiver must know exact file name.
3. Two types of coding.
4. User may change random number files needed for coding.
5. File's password is not stored.
6. Decoy bytes and check digits make cryptoanalysis
difficult.
Secret*File codes and decodes at the rate of 50 bytes per
second. Disk is not copy protected and may be used on a hard
disk.
Single copies of Secret*File cost only $75 and include a
free copy of Print*File. Print*File is a printer control
utility to allow use of the fonts offered on an Epson
compatible printer.
Quantity and dealer discounts and site licenses are
available. A demo version and more information may be
downloaded from BYLS Fido board 312-262-8959 (11 PM - 9 AM
weekdays, all day Saturdays Central Time zone)
Fido 11/301, Fido Racer, Murray State University, and Fido
144/2, Fido CSU, Colorado State University, are interested
in forming a network of FIDO's at institutions involved in
advanced education -- colleges, universities, medical
schools, institutes, and the like. If you are interested,
drop a line to 11/301 expressing interest.
We may be able to get some interesting exchanges going in an
area that doesn't seem to be represented in a net at this
time. We look forward to hearing from you.
by
Bob Hartman
Sysop Fido 132/101
The UN*X Gateway
and Home of Rovermsg
Once again there is a new version of ROVERMSG available for
downloading from my board. The new version is Revision
2.16. This version has some small bug fixes, and also
allows faster video display on IBM PC's, DEC Rainbows, and
Sanyos. The new video display is about 2-3 times faster
than it used to be. Anyone who is using a previous version
of Rovermsg should update to the new version if possible.
