1387 lines
53 KiB
Plaintext
1387 lines
53 KiB
Plaintext
Volume 3, Number 6 10 February 1986
|
|
+----------------------------------------------------------+
|
|
| _ |
|
|
| / \ |
|
|
| - Fidonews - /|oo \ |
|
|
| (_| /_) |
|
|
| Fido and FidoNet _`@/_ \ _ |
|
|
| Users Group | | \ \\ |
|
|
| Newsletter | (*) | \ )) |
|
|
| ______ |__U__| / \// |
|
|
| / FIDO \ _//|| _\ / |
|
|
| (________) (_/(_|(____/ |
|
|
| (jm) |
|
|
+----------------------------------------------------------+
|
|
Editor in Chief: Thom Henderson
|
|
Chief Procrastinator Emeritus: Tom Jennings
|
|
|
|
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
|
|
110 Baud and More History
|
|
2. ARTICLES
|
|
Why Not to Use ANSI.SYS
|
|
Looking for Old Talkies
|
|
Confessions of a Fido Tyro
|
|
A Suggestion For a New File Transfer Protocol
|
|
A solution for using the new O(utside) command in FIDO
|
|
3. COLUMNS
|
|
You Can dTUNE A Program But You Can't dTUNE a Fish
|
|
Notes from Abroad
|
|
4. WANTED
|
|
S.I.G administrators for Financial TeleShare.
|
|
5. FOR SALE
|
|
Entertainment Software for your PC!
|
|
6. NOTICES
|
|
The Interrupt Stack
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
============================================================
|
|
EDITORIAL
|
|
============================================================
|
|
|
|
Josh Gordon, 125/93
|
|
|
|
110 Baud and More History
|
|
|
|
Boy do I remember 110 baud! I guess I am about the same
|
|
generation as the Editor; let me elaborate a bit further on
|
|
the setup I had in my first days with a microcomputer. At
|
|
the time, I was a newly appointed Graduate Teaching Fellow
|
|
in C.S. at the U. of Oregon. There was no office for me, so
|
|
they stuck me in the room with the mini and microcomputers;
|
|
a brier patch! Fun stuff. The newest acquisition was a
|
|
remarkably well-stuffed IMSAI 8080, with (to stir up some
|
|
nostalgia!) a Cromemco Dazzler, a TDL Z80 card, a Cyclops
|
|
CCD camera (also by Cromemco, I seem to recall), an IMSAI
|
|
VDM, a whopping 64K of RAM, and some or another serial card.
|
|
Also resident: a trusty old Teletype. No disk drive, of
|
|
course; as I was leaving, a Processor Tech disk drive was
|
|
just being received.
|
|
|
|
So: To use the IMSAI effectively, I had it down to
|
|
this sequence: First I would key in a small boot program to
|
|
the front panel. (I miss front panels! On the IMSAI, you
|
|
could put the colored keys in whatever order you wanted;
|
|
either RRRR BBBB RRRR BBBB if you were a HEX man, or if you
|
|
were an OCTAL buff, R BBB RRR BBB RRR BBB.) This program was
|
|
an absolute paper tape loader. I would then load in a more
|
|
sophisticated hex checksum loader on paper tape. Now comes
|
|
the fun part. In the same building lived a nice PDP-10. In
|
|
the room with the micro were several serial ports. So, I
|
|
would call up the PDP-10 operator, and say, "Hey John!
|
|
Please connect line 39 at 19200". He would blanch a bit:
|
|
19200 was only used for this purpose, and put a somewhat
|
|
disproportionate load on the Ten. Once it was hooked up, I
|
|
had two things: either a remarkably fast PDP-10 terminal,
|
|
the only one around, or an IMSAI 8080 with one hell of a
|
|
peripheral (the 10).
|
|
|
|
We actually got some pretty sophisticated stuff
|
|
going, rudimentary image processing with the Cyclops, nice
|
|
games with the Dazzler, that sort of thing. We had much more
|
|
memory than any of our friends with micros; and the huge
|
|
capacity of the 10, in comparison, gave us quite a nifty
|
|
setup.
|
|
|
|
As a result of my experience in that lab, and by
|
|
virtue of the fact that an SF bookstore in Eugene was owned
|
|
by the soon-to-be-ex-wife of a somewhat high muckamuck at
|
|
IMSAI, my first job out of college was replacing a certain
|
|
Rob Barnaby when he left IMSAI to work on an odd little
|
|
program at that time NED, which evolved into WordStar. But
|
|
the story of IMSAI is for another time, assuming someone is
|
|
interested.
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
Fidonews Page 2 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
============================================================
|
|
ARTICLES
|
|
============================================================
|
|
|
|
WHY NOT TO USE ANSI.SYS
|
|
by Richard Ellis (Fido 102/509)
|
|
|
|
|
|
This may sound heretical but if there's one thing I can't
|
|
stand, it's a PC with ANSI.SYS installed. I have had this
|
|
feeling since IBM first introduced it with DOS 2.0. Why
|
|
must people feel that having something blessed by the
|
|
American National Standards Institute makes it good and
|
|
wonderful?
|
|
|
|
The first problem is the memory ANSI.SYS takes. It takes it
|
|
permanently; not just until you reboot. You have to edit
|
|
the CONFIG.SYS file and reboot to recover the memory.
|
|
|
|
The second problem is related to the first. You can't turn
|
|
ANSI.SYS off! There is no way a program can say "Leave me
|
|
alone, I'll do it myself!" I have been working on an energy
|
|
conservation analysis system for over two and a half years.
|
|
It does lots of screen manipulation. It doesn't work quite
|
|
right if ANSI.SYS is installed. I use no ESC sequences at
|
|
all but ANSI.SYS still interferes. The problems are subtle
|
|
but they are there and they are problems.
|
|
|
|
Finally, let's pretend we can live with the first two
|
|
problems. The ANSI CRT standard has received much criticism
|
|
due to its wordiness. To put it bluntly, it's SLOW!
|
|
|
|
I don't think ANSI.SYS would be so bad if it could be turned
|
|
on and off as needed by programs. I see no need to have it
|
|
sitting around all the time taking memory when it's not
|
|
needed or wanted. This would solve the interference problem
|
|
and anyone that didn't mind their software running slow
|
|
could use it.
|
|
|
|
In conclusion I would like to plead to all software authors
|
|
to not use ANSI.SYS.
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fidonews Page 3 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
Looking for Old Talkies
|
|
|
|
It occured to me that a LOT of radio stations are switching
|
|
from commercial two way gear to cellular mobile phones.
|
|
Makes sense, faster, better quality, easier to put on the
|
|
air, less maintenance. And I know that right now, anyway,
|
|
used two-way gear is a drag on the market. Well, if your
|
|
station is making the switch and you'd like to get rid of
|
|
the old walkie-talkies and get a nice tax deduction,
|
|
consider giving them to the American Council of the Blind.
|
|
|
|
Every year we have to rent them for our annual convention at
|
|
rip-off prices, but we just don't have the free cash right
|
|
now to buy our own. Our annual convention has grown to the
|
|
point where we have to have 'em just to keep functioning.
|
|
Going to look for someone, or sticking a message up on a
|
|
cork board just doesn't work when you are dealing with a
|
|
meeting of 3,000 people, 95% of them blind. Plus our next
|
|
convention, in Knoxville, Tennessee, in July, will be spread
|
|
out between two major hotels!
|
|
|
|
We are interested in most any kind of used commercial two-
|
|
way gear, VHF or UHF. We also would be interested in
|
|
chargers, batteries, cases, spare rubber duckies, etcetera.
|
|
Just send Fidomail to Vernon Henley, Fido 147/1 and I will
|
|
get right back to about your donation. Also, be watching
|
|
down in this direction for a burst of interest in Fido from
|
|
blind users. Our monthly magazine, the Braille Forum, will
|
|
soon carry an article about Fido, and there are several
|
|
other projects in the works. If you or someone you know
|
|
would like a free subscription, just drop me a line at the
|
|
same address. You need not be blind to receive the
|
|
magazine. Please specify large print, cassette or Braille
|
|
(the cassette requires a special type player that usually
|
|
only a blind person would have.)
|
|
|
|
I would be pleased to answer any or all questions concerning
|
|
ACB or blindness in general for you, your users or their
|
|
friends, relatives or acquaintances. If I don't know the
|
|
answer, I usually know someone who does, and I love sending
|
|
and receiving letters, so please feel free to direct any
|
|
inquiry this way, no matter how off the wall it might be.
|
|
(No matter what it is, I've heard it before, probably.)
|
|
Thanks for your consideration, and ask your boss about those
|
|
talkies. It might be just the push he finally needs to make
|
|
the jump to cellular.
|
|
|
|
---Vernon Henley, Fido 147/1
|
|
Chair, Board of Publications
|
|
American Council of the Blind
|
|
800-424-8666 (voice)
|
|
|
|
Call after 5:30 pm Eastern time for a free, pre-recorded
|
|
update on legislative, administrative and judicial action
|
|
concerning the blind and handicapped.
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
Fidonews Page 4 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
Bruce A. White
|
|
Fido 109/612
|
|
|
|
Confessions of a Fido Tyro
|
|
|
|
|
|
Is WASH-A-RUG (109/483) a carpet laundry? That was my first
|
|
thought, especially after I discovered that FIDO-FHLMC
|
|
(109/456) really IS related to Freddie Mac. Just what is
|
|
the story behind these electronic bulletin boards with
|
|
cutesy illustrations of dogs on them?
|
|
|
|
I was initiated to the world of Fido by an announcement in a
|
|
publication of an organization I belong to. Having some
|
|
experience as a subscriber to CompuServe, I was able to
|
|
connect myself to the BBS listed in the announcement. After
|
|
a few minutes I said to myself, this is very interesting,
|
|
but what's it for? Also, knowing how the minutes add up to
|
|
$$$s at CompuServe, I wondered how much this diversion was
|
|
costing me.
|
|
|
|
My state of perplexity wasn't aided by reading the sysop's
|
|
editorial, in which HE was expressing some doubts about the
|
|
usefulness of his new BBS. All of a sudden my monitor took
|
|
on a life of its own, and I slowly realized that he was
|
|
"chatting" with me. He reassured me that it was costing me
|
|
nothing, but that made me even more leery. If it's free,
|
|
then how can he afford the required time and equipment to do
|
|
this? And though it seemed a bit dumb to be typing at each
|
|
other, when we could have picked up the phone and talked
|
|
much more quickly, I played along and enjoyed the
|
|
conversation.
|
|
|
|
I'm afraid now I'm hooked. A person who has always hated to
|
|
use the phone, I now find myself dialing BBS numbers when I
|
|
could be doing more constructive things. In the few days
|
|
since I made my first Fido contact, I have graduated myself
|
|
to Expert help-level status (even if I have to occasionally
|
|
resort to "?"), and learned my way around several boards.
|
|
I'd like to share some impressions and suggestions.
|
|
|
|
I think the possibilities of sharing and communicating are
|
|
what appeal most to me. I use my micro primarily for word-
|
|
processing, and will probably never become a programmer. I
|
|
admit that it is great to be able to download a file here
|
|
and there, and obtain utilities or programs for free, but
|
|
there are only so many utilities and programs one can use;
|
|
beyond a certain point one approaches overkill or obsession.
|
|
|
|
Because of the potential for communication, then, FidoNet
|
|
and FidoNews are fascinating developments, and I hope more
|
|
people will get modems and participate in BBS networking.
|
|
Any use of technology that furthers interpersonal
|
|
communication should be utilized to the fullest. But how
|
|
can new participants in Fido networking best be obtained?
|
|
|
|
As I groped my way around the boards, I got the impression
|
|
that everyone else on the board was already a computer and
|
|
|
|
|
|
Fidonews Page 5 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
Fido expert; it was as though they had all gone through the
|
|
same class together. Most Fido users seem to be into
|
|
"heavy" technical stuff, and talk about hardware the same
|
|
way guys used to talk about their cars and accessories. How
|
|
does an outsider get into this seemingly closed group?
|
|
|
|
I was able to see what Fido DOES to some extent, but I had
|
|
no idea where it came from, why and when it was developed,
|
|
and its guiding philosophy and goals (if any). On one board
|
|
(The Trading Post) I was happy to find a "FIDO TUTORIAL"
|
|
area, and a downloadable Fido User Manual. The sysop of
|
|
this board obviously had the new user in mind when he
|
|
designed it, and perhaps other boards should also take into
|
|
consideration the fact that some users will know very little
|
|
about what they are doing, and will need some coaching.
|
|
|
|
I realize, though, that most sysops, being well advanced in
|
|
computer and Fido usage (or else, I'm assuming, they
|
|
wouldn't be sysops), don't want to clutter or slow up their
|
|
boards by making them more "user friendly" for a Fido tyro.
|
|
Consequently, perhaps there should be some boards that are
|
|
set up EXPRESSLY for beginners. Such boards can have mostly
|
|
".TXT" files to be typed and downloaded, and a very non-
|
|
threatening and supportive environment. Such boards could
|
|
also have general information about Fido, or explain where
|
|
such information can be obtained. Perhaps these boards
|
|
could be operated by sysops who are not very far from being
|
|
tyros themselves, and they could build up experience and
|
|
expertise before tackling a more sophisticated BBS.
|
|
|
|
I'd appreciate feedback (partly to prove that FidoNews
|
|
really DOES get read). I think I'll go call another BBS--I
|
|
wonder what the NASA Gas Net is all about?
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fidonews Page 6 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
Frank Mayhar
|
|
12/29/85
|
|
Stephen F. Austin State University
|
|
FIDO 124/16
|
|
|
|
|
|
A Suggestion For a New File Transfer Protocol
|
|
|
|
|
|
This article addresses the problems inherent in Ward
|
|
Christensen's original XMODEM protocol, which are not
|
|
entirely solved by any of the new protocols that have been
|
|
introduced since. It then proposes a new protocol that
|
|
would be a natural successor to the XMODEM protocol, and
|
|
that may provide more effective long-term solutions to
|
|
those problems.
|
|
|
|
|
|
I. Introduction
|
|
|
|
I have used Ward Christensen's XMODEM protocol for several
|
|
years. In that time I have become aware of (actually, I
|
|
have run head on into) several problems with it. These
|
|
problems are mostly solved, to a greater or lesser degree,
|
|
by many of the current new crop of protocols that have been
|
|
introduced in the past few years. However, the methods by
|
|
which they have been solved are less than might be desired,
|
|
and introduce new problems, mostly of compatibility with
|
|
existing file transfer methods.
|
|
|
|
II. The Problems
|
|
|
|
The problems I am referring to are (1) the total lack of a
|
|
way to transfer file information (file name, length,
|
|
creation date), (2) relatively poor data throughput, and
|
|
(3) very poor performance of most software at high data
|
|
rates (i.e. rates greater than about 1200 to 2400 baud).
|
|
|
|
The first problem is self-evident in the protocol
|
|
definition itself. Ward Christensen provided no way to
|
|
transfer file information.
|
|
|
|
The second problem has to do both with the theoretical
|
|
efficiency of the protocol, and with the efficiency (or
|
|
lack thereof) of the implementation. The theoretical
|
|
efficiency of a protocol is determined by dividing the
|
|
number of bits of actual data by the total number of bits
|
|
transmitted. The obvious way to increase such efficiency,
|
|
then, is to increase the amount of data transmitted
|
|
relative to the amount of control information transmitted.
|
|
The straight XMODEM protocol (using 128-byte blocks) ranges
|
|
from about 95% efficient in the worst case, to about 96%
|
|
efficient in the best case. (The best case occurs when the
|
|
number of data bytes fits evenly into the transmitted
|
|
blocks [the file length is evenly divisible by the block
|
|
length, 128 in this case]. The worst case is when the last
|
|
block transmitted contains only one actual data byte plus
|
|
filler for the rest of the block.) The efficiency of the
|
|
|
|
|
|
Fidonews Page 7 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
same protocol using 1024-byte blocks ranges from 99% in the
|
|
best case to 93% in the worst case. Efficiency is lowered
|
|
in any case, of course, if errors occur. The average
|
|
XMODEM efficiency is, therefore, around 96%. The average
|
|
efficiency when using 1024-byte blocks is also around 96%.
|
|
So increasing the block length is no solution to the
|
|
theoretical efficiency problem. A better solution would be
|
|
to use variable-length blocks (say varying between 128 and
|
|
1024 or 2048 bytes). This may also help solve another
|
|
problem.
|
|
|
|
The major problem with the actual effective data throughput
|
|
of most XMODEM-type file transfers has to do with the
|
|
efficiency of the software doing the transfer. In any
|
|
transfer, the throughput of the transfer is controlled by
|
|
the speed of the least efficient side of the transfer.
|
|
Usually, at 300 or 1200 (or even 2400) baud, the
|
|
inefficiency of most software is not noticeable. However,
|
|
when the data rate is increased, the inefficiency of most
|
|
of the software make the effective throughput stay around
|
|
1200 or 2400 baud, at best. (There are notable exceptions
|
|
to this, particularly Greg Gilley's TERM terminal emulator
|
|
program for the TI Pro, which is the absolute best I've
|
|
seen at this. There may be others that I'm not aware of.)
|
|
Although the best solution to this problem would be to
|
|
optimize the efficiency of the software, this may not be
|
|
feasible in all cases. Longer or variable block lengths,
|
|
which increase the efficiency of the protocol and make the
|
|
software spend more time actually transmitting blocks
|
|
rather than processing, would undoubtedly help, even if it
|
|
wouldn't completely solve the problem.
|
|
|
|
In addition, there is a problem that stems from the
|
|
attempts by a very large number of programmers to solve the
|
|
problems outlined above. This can be summed up in the
|
|
statement that none of the current file transfer protocols
|
|
provide any convenient way for the receiving and trans-
|
|
mitting programs to reconcile what extensions to the XMODEM
|
|
protocol will be used in the current transfer. (These
|
|
extensions include CRC error checking [rather than the
|
|
checksum method used in the original XMODEM], and larger
|
|
data packets [as in the relatively new YMODEM protocol,
|
|
which provides 1024-byte data packets to increase through-
|
|
put].) A compatibility problem also exists between
|
|
different XMODEM-based protocols, such as Telink, MODEM7,
|
|
and YMODEM.
|
|
|
|
The current methods to accomplish some reconciliation
|
|
between receiver and sender range in most new XMODEM-based
|
|
protocols from nonexistent to the "C-instead-of-a-NAK"
|
|
method for establishing CRC error checking, and different
|
|
characters (instead of SOH) as packet prefixes in protocols
|
|
that use a "packet zero" and non-128-byte-packets (see the
|
|
descriptions below of the Telink and YMODEM protocols).
|
|
Different implementations use different features, and
|
|
future implementations may use still different features.
|
|
There is really no way, currently, to accomplish this
|
|
reconciliation, in any existing protocol.
|
|
|
|
|
|
Fidonews Page 8 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
There is another problem with most XMODEM-based protocols,
|
|
having to do with CRC error checking. In most implemen-
|
|
tations, a "C" is sent by the receiver instead of the first
|
|
NAK, to signal CRC mode. If the transmitter hasn't
|
|
responded by the third "C", the receiver switches to
|
|
checksum mode, and sends a NAK. The transmitter presumably
|
|
responds to this by sending the first data packet, and the
|
|
transfer continues in checksum mode. The timeout for
|
|
response to the "C" is three seconds. Thus, the start of
|
|
the transfer may be delayed by as much as nine or more
|
|
seconds, if the transmitter doesn't support CRC error
|
|
checking.
|
|
|
|
|
|
III. Some Existing Protocols
|
|
|
|
There is currently a proliferation of new protocols, all
|
|
more-or-less loosely based on Christensen's protocol. Most
|
|
have features that are desirable. However, none of them
|
|
have provided any really effective, long-term solution to
|
|
the problems enumerated above, most of them are to some
|
|
degree incompatible with Christensen's original protocol,
|
|
and most, if not all, have added a level of complexity, to
|
|
an originally simple protocol, that prevents them from
|
|
really taking hold in the user community the way XMODEM has
|
|
done. Some examples of these protocols include MODEM7
|
|
(originator unknown), YMODEM (originated by Chuck
|
|
Forsberg), and Telink (originated by Tom Jennings). There
|
|
are good and bad points about each of them.
|
|
|
|
MODEM7 uses a very clumsy and error-prone method of trans-
|
|
ferring the file name, although this does allow batch file
|
|
transfers.
|
|
|
|
YMODEM, used primarily on CP/M and UNIX systems, allows CRC
|
|
error checking (using the "C-instead-of-a-NAK" method),
|
|
1024-byte data packets, and the transfer of file infor-
|
|
mation (filename, length, and date) in a "packet zero",
|
|
allowing batch file transfers. A problem exists in the
|
|
YMODEM protocol, however, in the area of the 1024-byte
|
|
packet length. According to the definition of the
|
|
protocol, a 1024-byte packet is prefixed with a STX rather
|
|
than a SOH, and the receiver must be able to handle any mix
|
|
of 128- and 1024-byte packets. This use of STX as a
|
|
data-packet prefix is inconsistent with the original
|
|
simplicity of the XMODEM protocol.
|
|
|
|
Telink uses the same clumsy method of transferring the file
|
|
name that is used in MODEM7, which is ironic, as Telink
|
|
transfers the file name again in a "packet zero", which
|
|
also contains the file size and date, and is prefixed with
|
|
a SYN rather than an SOH (see the description, above, of
|
|
the YMODEM protocol). Telink also provides CRC error
|
|
checking, using the "C-instead-of-a-NAK" method.
|
|
|
|
Another protocol, which is not based on the XMODEM
|
|
protocol, and which solves most of the problems in that
|
|
protocol (at the expense of a lot of added complexity), is
|
|
|
|
|
|
Fidonews Page 9 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
the Kermit protocol. This protocol uses "command packets"
|
|
to set various parameters between the receiver and the
|
|
sender. This protocol is commonly used in university
|
|
settings, between microcomputers and mainframes. The
|
|
protocol is Unix-based. The primary reason that Kermit has
|
|
not taken hold is because of that added complexity. Kermit
|
|
can be difficult and tedious to implement, and the protocol
|
|
has features that are unneeded by most microcomputer users,
|
|
as well as some restrictions not present in the XMODEM
|
|
protocol.
|
|
|
|
|
|
IV. A New Protocol?
|
|
|
|
Fine, you say. Problems exist. But is a new protocol
|
|
required, when there is a huge (well, maybe not huge, but
|
|
certainly large) proliferation of protocols. Wouldn't a
|
|
new protocol just add to the existing mess? I say that a
|
|
new protocol is needed. It should not try to be all things
|
|
to all people, as some existing protocols do, and it should
|
|
not compromise the essential simplicity of the original
|
|
Christensen XMODEM protocol, except where absolutely
|
|
necessary. It should, however, allow the use of the new
|
|
features of XMODEM-based file transfer, such as CRC error
|
|
checking and large packet lengths. It should attempt to
|
|
allow file transfers with virtually any XMODEM-based file
|
|
transfer protocol implementation, using the straight XMODEM
|
|
protocol. It should also be as easily expandable as
|
|
possible, in order to meet possible future needs.
|
|
|
|
I propose a new protocol that would incorporate the
|
|
following features:
|
|
|
|
1) NO IMPLEMENTATION SHOULD BE REQUIRED TO SUPPORT
|
|
MORE THAN THE MINIMAL XMODEM FILE TRANSFER
|
|
PROTOCOL, in terms of CRC error checking and
|
|
packet lengths. This excepts the transfer of file
|
|
information.
|
|
|
|
2) Transfer of file information, including filename,
|
|
file size, and file date. The "packet zero"
|
|
method? "Command packets", as in Kermit?
|
|
|
|
3) An easy way to let the receiver and transmitter
|
|
agree on what features will be used in the current
|
|
transfer. This is the major problem that I see
|
|
with most of the current XMODEM-based protocols.
|
|
This might be accomplished several ways. One way
|
|
would be transmitter-driven, using a "packet zero"
|
|
containing file info and several bytes devoted to
|
|
what features are supported. Another method might
|
|
use Kermit's solution to the problem, which
|
|
involves the receiver and the transmitter
|
|
exchanging some kind of packet (a "command
|
|
packet") containing "feature-present" flags. The
|
|
features used would be the exclusive-or of the
|
|
"feature-present" flags. The packets might
|
|
contain other information, as well.
|
|
|
|
|
|
Fidonews Page 10 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
4) The capability to support CRC error checking, with-
|
|
out requiring such support. (That is, it should
|
|
allow CRC error checking, but it should not pro-
|
|
hibit the checksum method.)
|
|
|
|
5) The capability of using longer or variable packet
|
|
lengths to increase data throughput.
|
|
(Variable-length packets would be easily
|
|
implemented by adding a control word to each
|
|
packet containing the length of the packet.)
|
|
|
|
6) Batch file transfers. This should be accomplished
|
|
easily, if item 2 is successfully accomplished.
|
|
|
|
7) Full minimal XMODEM compatibility, as the default.
|
|
This means no file information transfer, no CRC
|
|
error checking, 128-byte packets, and no way for
|
|
the receiver and transmitter to communicate what
|
|
features will be used (this last is obvious).
|
|
This might be accomplished using the
|
|
"C-instead-of-a-NAK" method, using some other
|
|
character than C. Read "C" as NAK.
|
|
|
|
8) The protocol should be receiver-driven, as much as
|
|
possible. However, a method should exist to
|
|
exploit the full capabilities of each end of the
|
|
transfer. This requirement may be changed or
|
|
removed, as it and item 3 may prove to be mutually
|
|
exclusive.
|
|
|
|
9) Easy expandability. The protocol should include
|
|
some method (such as reserved fields in command
|
|
packets or in a "packet zero") for future
|
|
expansion.
|
|
|
|
The full definition of the protocol would include all the
|
|
enhancements outlined above. As shown, the protocol would
|
|
also allow subsets (including a subset consisting of the
|
|
original XMODEM protocol), and would define a way to
|
|
specify which set of enhancements would be used for each
|
|
transfer.
|
|
|
|
There are a number of methods of satisfying these require-
|
|
ments. I can see none that exactly fit the spirit of the
|
|
original XMODEM implementation and that completely
|
|
eliminate all the problems mentioned in this document.
|
|
However, it may not be possible to do both. I can see
|
|
several possible solutions that do satisfy these require-
|
|
ments, using features from several of the existing proto-
|
|
cols, and some new features.
|
|
|
|
|
|
V. Conclusion
|
|
|
|
The problems mentioned in this document are real, and the
|
|
great proliferation of file transfer protocols are not
|
|
helping the matter. As I see it, some new protocol is
|
|
needed that is a logical successor to XMODEM, that incor-
|
|
|
|
|
|
Fidonews Page 11 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
porates most of the most-used features of the current
|
|
protocols, and that is as compatible as possible with
|
|
existing protocols. I think that the the general outline
|
|
above may provide such a protocol.
|
|
|
|
I have not started implementing this protocol, primarily
|
|
because I don't want to go to all that work and have it be
|
|
completely ignored. I would like to see the people most
|
|
directly affected contribute their opinions and expertise
|
|
to the solution of the problems I've mentioned. This means
|
|
you, the public BBS user. By no means am I saying that the
|
|
protocol I've outlined is THE solution. It is merely a
|
|
suggestion for one possible solution. However, I do
|
|
believe that a solution is needed, and soon. Obviously no
|
|
one protocol can be completely satisfactory to every person
|
|
in every situation. But we can come up with a solution
|
|
that solves most of the problems I've mentioned, and is
|
|
also easy to use and implement.
|
|
|
|
As I mentioned above, I would like to see a lot of people
|
|
get involved. My hope is that we, the user community, can
|
|
get together and design and implement a good new protocol,
|
|
standardize it, and get it into common use. If we can, per-
|
|
haps the computer industry, which has for the most part
|
|
ignored us (although there have been a few notable excep-
|
|
tions recently), will begin to view us a a real innovative
|
|
and productive force in computing.
|
|
|
|
Let me hear your opinions.
|
|
|
|
I can be reached on the following BBS's:
|
|
|
|
JimNet (Austin) RBBS at (512) 837-0953 -- This is the one I
|
|
use most.
|
|
|
|
The Warbler (Warble2 FIDO, Dallas area) at (214) 521-8689
|
|
|
|
Leave mail for Frank Mayhar at those BBS's, or send Fido-
|
|
Mail to me at FIDO 124/16 (the Warble2 FIDO, above).
|
|
|
|
|
|
My address:
|
|
|
|
Frank Mayhar
|
|
P.O. Box 14963 SFA
|
|
Nacogdoches, TX 75962
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fidonews Page 12 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
Don Daniels
|
|
Sysop, Fido 107/211
|
|
|
|
OUTSIDE
|
|
|
|
|
|
In Version 11q of FIDO, a new command was added called
|
|
O(utside). Similar to the Sysop-only "0" command, this
|
|
command is available to any level of user (as set by the
|
|
Sysop) and causes FIDO to terminate without dropping the
|
|
phone connection. A specific ERRORLEVEL is returned that
|
|
can be tested in the batch file that initiated FIDO in order
|
|
to determine further action. (If you have recently upgraded
|
|
to 11q, you must delete your old MAINPRIV.BBS, enter FIDO as
|
|
a Sysop, and issue a "3 O priv-level" command for the
|
|
O)utside command to work properly at the access level(s) you
|
|
wish.)
|
|
|
|
Just what such further action may be implemented is totally
|
|
of no concern to FIDO, as it is left to the individual
|
|
Sysops. This brings up the questions, "Just what should
|
|
this facility be used for on my system?" and "How do I make
|
|
sure that only the right people are running it and that they
|
|
are not gaining control of the whole machine?"
|
|
|
|
Well, the answer to the second question may well be in the
|
|
form of a new program called, appropriately enough, OUTSIDE,
|
|
which allows you to place several levels of control on what
|
|
is executed and by whom.
|
|
|
|
OUTSIDE is kind of like a miniature FIDO that displays a
|
|
welcome message (OUTSIDE.WEL) on the screen, validates the
|
|
users (again) by checking their names and passwords against
|
|
USER.BBS, and then displays a small menu of options for user
|
|
selection. These include:
|
|
|
|
L List the services available to this particular user
|
|
X Execute a service
|
|
R Return to FIDO (via the batch file)
|
|
? Display contents of a Help file (OUTSIDE.HLP)
|
|
|
|
The Services that are available to users are specified in a
|
|
Service Control File called OUTSIDE.SRV which is created
|
|
off-line by the Sysop. It allows for an identification and
|
|
description of each service, optional passwords, specifica-
|
|
tion of which of four levels of security should be used, the
|
|
method of Service initiation, and, for those entries for
|
|
which it is necessary, a list of authorized users.
|
|
|
|
Depending on the nature of the Services, several Services
|
|
may be executed by the user before returning to FIDO. A
|
|
log, OUTSIDE.LOG, is maintained which keeps track of all
|
|
OUTSIDE users, the Services they use, and certain anomalies
|
|
which may occur.
|
|
|
|
|
|
OUTSIDE.ARC is available for downloading from:
|
|
|
|
|
|
|
|
Fidonews Page 13 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
D2-FIDO (107/210) 516-682-8525
|
|
evenings or weekends at 1200-300 bps
|
|
|
|
DANIELS-FIDO (107/211) 516-367-9626
|
|
most any time of day at 2400-300
|
|
|
|
It is distributed under the "Shareware" concept. Further
|
|
documentation is available within the package.
|
|
|
|
|
|
Actually, there are many potential uses for this feature
|
|
that has been provided by Tom Jennings. I am willing to
|
|
serve as a clearing-house for propositions, problems,
|
|
programs, and what-all related to the use of the O(utside)
|
|
command and the Services provided thereunder. Address all
|
|
messages and files to Don Daniels, Sysop, FIDO 107/211
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fidonews Page 14 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
============================================================
|
|
COLUMNS
|
|
============================================================
|
|
|
|
You Can dTUNE A Program
|
|
But You Can't dTUNE a Fish
|
|
by
|
|
Ben Silverstein
|
|
|
|
|
|
Some of you may be familiar with a bulletin board system
|
|
called The Lost Dutchman's Gold Mine RCP/M. It is based in
|
|
Phoenix, Arizona and is run by James A. Gronek. If the
|
|
board isn't familiar, Jim's name should be to anyone who has
|
|
more than a passing acquaintance with public domain
|
|
software. Jim has written several original and updated many
|
|
existing public domain programs, mostly in the realm of
|
|
dBASE II applications. One that will ring a bell with most
|
|
users is DBSHELL, the .CMD file that makes dBASE more user
|
|
friendly.
|
|
|
|
Some time ago, Jim wrote a utility for dBASE command files
|
|
called dTUNE. This little gem allowed dBASE programmers to
|
|
write their files with liberal comments, proper indentation,
|
|
and all the other habits essential to good programming, and
|
|
then "detune" it to a file that was the absolute bare-bones
|
|
that dBASE needs to run, and no more. All commands are
|
|
reduced to their minimum 4 character representations,
|
|
comments and unneccessary blank lines, tabs, and spaces are
|
|
deleted. This reduces the space needed on disk for the
|
|
files, increases execution time by eliminating number of
|
|
lines that dBASE must parse, and makes it harder for someone
|
|
to follow the program listing. The source file is not
|
|
changed; all changes are written to a new file and the
|
|
original renamed to type .SRC.
|
|
|
|
The original public domain version was written in the dBASE
|
|
language itself and tokenized with one of the commercial
|
|
RUN-TIME(c) clones. This didn't allow listing, but could be
|
|
run by the user with no difficulty. Jim has now rewritten
|
|
the program in TURBO Pascal and is offering the latest
|
|
version as a commercial product. As a beta tester, I have
|
|
had the oppurtunity to try out the new version over the last
|
|
couple of months. Several new features have been added to
|
|
dTUNE, and execution time is much improved thanks to the
|
|
speed of Turbo.
|
|
|
|
With the package, Jim has included a terminal installation
|
|
program so that dTUNE may be customized to run on a number
|
|
of different terminals. This part was created using the
|
|
GINST portion of the Turbo Toolbox utility disk from Borland
|
|
that installs an application program with the same routine
|
|
used to install Turbo itself.
|
|
|
|
When the program is invoked, you are presented with a well
|
|
laid out menu showing the program choices and their current
|
|
condition. Most are toggles, and pressing the appropriate
|
|
key will turn them on or off. Several combinations of
|
|
|
|
|
|
Fidonews Page 15 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
functions and outputs are available.
|
|
|
|
|
|
Some of the high points of dTUNE are that it:
|
|
|
|
- Prints a nested and indented listing of your command file
|
|
with lines connecting the IF/ENDIF, DO WHILE/ENDDO, and DO
|
|
CASE/ENDCASE pairs. This makes debugging easier in that
|
|
is is readily apparent if you have an open-ended function.
|
|
|
|
- Alters the case of your command file. Text may be changed
|
|
to upper or lower case as you wish, with delimited fields
|
|
left untouched.
|
|
|
|
- Produces a trimmed file as described above that will have
|
|
a faster execution time.
|
|
|
|
- Produces a nested and indented version of the trimmed
|
|
file. Handy in case you lose the original file and must
|
|
reconstruct it from the dTUNEd version.
|
|
|
|
- Produces a cross-referenced listing of all memory
|
|
variables. Two files are produced: a .PRN file containing
|
|
line numbers, and a .XRF file with all variables listed
|
|
alphabetically.
|
|
|
|
- Allows a listing of any of the above files to be sent to
|
|
the printer, saving the trouble of printing them manually
|
|
later.
|
|
|
|
A status window is updated during processing, allowing you
|
|
to monitor the progress of dTUNE. This program works very
|
|
quickly, and I have found no bugs in the times that I have
|
|
used it. I have a small wish list, but that is always the
|
|
case. dTUNE will run on any Z-80 based computer with a
|
|
miminum 48K TPA. A smaller (40K) TPA version is available
|
|
for those who need it.
|
|
|
|
The public domain version (v3.1) of dTUNE can be found on
|
|
many remote systems around the country, or on Jim's board at
|
|
the number below. Check drive A2: for the CP/M version, and
|
|
A9: for the MS-DOS edition. dTUNE 4.0 is in beta testing now
|
|
and will be available soon. The price will be approximately
|
|
$35.00 from Jim through his company, UCS, Inc. You may
|
|
order by mail to the following address:
|
|
|
|
Jim Gronek
|
|
UCS, Inc.
|
|
P.O. Box 23866
|
|
Phoenix, AZ 85063
|
|
|
|
The number for the Lost Dutchman's Gold Mine RCP/M system
|
|
is:
|
|
|
|
(602) 848-6708
|
|
24 hrs, 300/1200/2400 baud
|
|
|
|
There is also a second system on line dedicated to ZCPR-
|
|
|
|
|
|
Fidonews Page 16 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
related items. Check the first system for details.
|
|
|
|
------------------------
|
|
|
|
You might not know that dTUNE is (C) UCS, Inc., but if you
|
|
don't already know that dBASE II and RUN-TIME are (C)
|
|
Ashton-Tate and that TURBO Pascal and Turbo Toolbox are (C)
|
|
Borland International, don't expect me to tell you.
|
|
|
|
|
|
Also, acknowledgements to REO Speedwagon for the inspiration
|
|
for the title of this piece.
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fidonews Page 17 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
Editor's note: We've recently received a set of back issues
|
|
to the European counterpart of FidoNews. We'll be running
|
|
articles from them for the next several issues. I apologize
|
|
to our European readers for printing what is to you old
|
|
news, but it's new to many of us here in the Colonies.
|
|
|
|
Notes from Abroad
|
|
|
|
|
|
Hello, Good-Evening, and Welcome.
|
|
|
|
Unlike my continental counterparts I am not multilingual, I
|
|
have trouble with English! I will apologize now if you
|
|
cannot translate this!
|
|
|
|
There is so much public domain software around that a new
|
|
medium for distribution must be found. I have a DC-600 tape
|
|
backup (25 Meg) and I am willing to let any Fido sysop who
|
|
has a DC-600 tape backup have a copy of my tapes. This
|
|
makes much more sense than sending hundreds of floppy disks
|
|
through the post. The tape is not finished yet and I am
|
|
still looking for more software, please send me any new
|
|
public domain software or anything that is not listed in my
|
|
catalog. I am currently negotiating with several UK
|
|
hardware houses to supply me with various types of tape
|
|
streamers, cassette backups, and removable hard disks. I
|
|
suggest that any Fido sysop who has not yet got a tape
|
|
backup that they contact their local hardware houses and put
|
|
this idea to them:
|
|
|
|
There are approximately 500 Fido systems throughout the
|
|
world, each with the same problem as me; lots of public
|
|
domain software, (I have 500 disks, 60 Meg) and no fixed
|
|
standard for distribution except the floppy disk. If the
|
|
same tape streamers were supplied to all Fido's (DC-600, or
|
|
DC1000) that in itself should establish that particular unit
|
|
as the de-facto standard for exchange of an ever increasing
|
|
supply of public domain software. If we can work together
|
|
on this one I think we would all be better off.
|
|
|
|
Just think what a bonus it would be to various tape
|
|
manufacturers. They could tell potential customers that if
|
|
they bought their backup system that they could ask the
|
|
various user groups and bulletin boards for a copy of their
|
|
public domain software library on tape!!
|
|
|
|
If anyone has tried this approach, or has any ideas or
|
|
suggestions please let me know. I think it would be a good
|
|
idea to conduct a census on all Fido nodes to see what sort
|
|
of backup we use. It may be that we have a standard already
|
|
without knowing it. Is anyone willing to conduct the
|
|
aforementioned census?
|
|
|
|
Please send all ideas to me, Fido 4403.
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
Fidonews Page 18 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
============================================================
|
|
WANTED
|
|
============================================================
|
|
|
|
Gary W. Aili
|
|
Fido 104/3
|
|
|
|
WANTED! S.I.G administrators for Financial TeleShare.
|
|
|
|
Financial TeleShare is the first exclusively dedicated on-
|
|
line financial information and education forum!
|
|
|
|
Our members receive a variety of benefits including: in-
|
|
depth education, counseling, conferencing, practical
|
|
assistance, personal and business planning, extensive market
|
|
data & services, monitored product performance, free
|
|
personal message network, U.S. and Internat'l telex, 50
|
|
state local call access, and more.
|
|
|
|
HELP! We need FINANCIAL S.I.G. ADMINISTRATORS with
|
|
professional expertize and experience in financially
|
|
oriented subject fields including: planning, investments,
|
|
banking, insurance, entrepeneurship, collectibles, business
|
|
services and others. S.I.G. formation and management
|
|
experience preferred. MUST enjoy on-line WORK!
|
|
|
|
As a S.I.G. administrator, you and/or your business can
|
|
benefit from our NATIONAL membership. To respond, send a
|
|
message via FidoMail to Gary Aili (Fido 144/3) describing
|
|
your interest, experience and contact information.
|
|
|
|
Financial TeleShare is Fido 144/3. We may not yet be on
|
|
your node list, but your can still reach us through 144/0.
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fidonews Page 19 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
============================================================
|
|
FOR SALE
|
|
============================================================
|
|
|
|
ENTERTAINMENT SOFTWARE FOR YOUR PC!
|
|
|
|
SUPERDOTS! KALAH!
|
|
|
|
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
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fidonews Page 20 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|
|
============================================================
|
|
NOTICES
|
|
============================================================
|
|
|
|
The Interrupt Stack
|
|
|
|
|
|
22 Feb 1986
|
|
Submissions deadline for the CROBOTS competition. Ask
|
|
Andy Foray at 107/7 for details.
|
|
|
|
1 Mar 1986
|
|
The Next Occasional MetroNet Sysop Meeting, to be held at
|
|
Matt Kanter's apartment. Check with Matt at 107/3 for
|
|
details.
|
|
|
|
1 Mar 1986
|
|
European mail hour shifts to 0230-0330 GMT. Summer time
|
|
will no longer be observed.
|
|
|
|
11 Apr 1986
|
|
Halley's Comet reaches perigee.
|
|
|
|
19 May 1986
|
|
Steve Lemke's next birthday.
|
|
|
|
24 Aug 1989
|
|
Voyager 2 passes Neptune.
|
|
|
|
|
|
|
|
|
|
|
|
If you have something which you would like to see on this
|
|
calendar, please send a message to Fido 1/1.
|
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fidonews Page 21 10 Feb 1986
|
|
|
|
|
|
|
|
|
|
|