FidoNews · Vol 3, No 6 · 10 February 1986
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.
------------------------------------------------------------
Download original FidoNews · Volume 3 (1986) · ← Previous · Next →