informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido0412.nws

1296 lines
62 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Volume 4, Number 12 30 March 1987
+---------------------------------------------------------------+
| _ |
| / \ |
| /|oo \ |
| - FidoNews - (_| /_) |
| _`@/_ \ _ |
| International | | \ \\ |
| FidoNet Association | (*) | \ )) |
| Newsletter ______ |__U__| / \// |
| / FIDO \ _//|| _\ / |
| (________) (_/(_|(____/ |
| (jm) |
+---------------------------------------------------------------+
Editor in Chief: Thom Henderson
Chief Procrastinator Emeritus: Tom Jennings
FidoNews is the official newsletter of the International FidoNet
Association, and 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
ARTSPEC.DOC, available from node 1/1.
Copyright (C) 1987, by the International FidoNet Association.
All rights reserved. Duplication and/or distribution permitted
for noncommercial purposes only. For use in other circumstances,
please contact IFNA.
Table of Contents
1. EDITORIAL
Thanks from TJ
2. ARTICLES
Allied Health Teleconference Network
Proposed Bylaws for the Intergalactic Sysop Alliance
PROPOSAL: Another Addressing Scheme for FIDONET
Satellite Fido - Update
Announcing a New Mensa Echo!
3. COLUMNS
Column Without a Name
A Discussion on ASSEMBLER Language
4. NOTICES
The Interrupt Stack
Packet Switching Networks
Fidonews Page 2 30 Mar 1987
=================================================================
EDITORIAL
=================================================================
Tom Jennings
0/0
This is a long overdue letter of thanks to the people
who've nominated me for the Andy Fleugelman award. My long delay
in writing this probably comes across as rude, and for that I
apologize. I really do appreciate the nomination.
The timing is pleasantly odd; I'm suffering from plain
old programmer burnout, plus making major decisions as to what I
want to do with myself, etc not related to anything Fido. Also,
physical things like no computer (due to major construction for
the last few months - we stopped last week) makes it tougher.
Computers have lost all their fun for me, so it's time for a
*long* break. (skateboarding is much more interesting, and
everyone says it's foolish and a waste of time, enhancing my
enjoyment that much more.) It's nice to get this at a time when
things are becoming un-fun.
Rumor killing information: v12 is not dead, merely
excruciatingly late. It will be ready this summer (I think I'm
nearly a YEAR late at this point ...), the software is working
fairly well, I'm finishing some stuff in the Fido area, the
FidoNet stuff working fairly well. I'm backing out some major
features for a future minor rev, in the interests of getting out
a reliable program that meets all needs. Unlimited nodes (32767
cubed) much faster, etc. Manual is coming out nice. Details at a
later date.
When it's nearly ready, I'll announce to Fido Software's
customers by mail, and IFNA members via this, of what the full
story is, with all the details.
Anyways, things have obviously changed a lot in three
years, the net is nearly unrecognizable to me (not a complaint!),
and I'm glad to see things are changing and growing. One of these
days I'll run another Fido/FidoNet in the net, but not for a
while ...
And once again thanks to everyone for the nomination, and
to everyone else who makes the net run smoothly!
Tom Jennings
San Francisco
20 Mar 87
-----------------------------------------------------------------
Fidonews Page 3 30 Mar 1987
=================================================================
ARTICLES
=================================================================
Bill Hliwa, Sysop
The Med Tech FIDO (260/10)
State University of New York at Buffalo
The Allied Health Teleconference Network
========================================
The Allied Health Teleconference Network (AHTN) is in the
planning phase and participants are now being sought. This will
be a specialized EchoMail conference covering topics including
but not limited to:
Medical Technology (Laboratory Science)
Physical Therapy
Exercise Science
Occupational Therapy
Health Education
Biomedical Engineering
We would like to see as many participants as possible "state
side", but are also very interested in locating practitioners and
educators in other parts of the world. External funding is being
secured for this three year study, so that we plan to POLL all
participants for their mail (anywhere in the world!).
Discussions will be moderated and we hope to arrange for
"guest speakers" who will answer user's questions and add insight
to current topics.
o Is your board based in a clinical health
setting?
o Is your board at a university or college with
a school of Allied Health or programs in any
of the above disciplines?
o Do you have users with backgrounds in an
Allied Health field?
o Do you know of a local university, college or
hospital that might be interested in
participating through your board?
If you can answer `yes' to any of these questions, please
contact me, Bill Hliwa, at The Med Tech FIDO (260/10) or land
mail at:
William R. Hliwa, Jr., Cl. Asst. Prof.
State University of New York at Buffalo
Dept. of Medical Technology, AA107
462 Grider Street
Fidonews Page 4 30 Mar 1987
Buffalo, NY 14215
USA
-----------------------------------------------------------------
Fidonews Page 5 30 Mar 1987
PROPOSED BYLAWS
for the
INTERGALACTIC SYSOP ALLIANCE
This document contains the proposed bylaws of an organization to
be known as the Intergalactic Sysop Alliance, herein referred to
as ISA.
1. ISA shall exist solely to serve the Knights of ISA, and such
others as the Knights shall desire served.
2. The following orders of Knights are established:
A. The Order of the Golden Dawn. To be eligible, an
applicant must be the system operator in good standing of
a PUBLIC ACCESS node, and must have paid any tithes
required. A Knight of the Order of the Golden Dawn is
entitled to one vote.
B. The Order of Mercantile Grammarie. Any entity which
profits by the existence or operation of the Intergalactic
Sysop Alliance shall be eligible to join the Order of
Mercantile Grammarie by paying the required tithes. If
said entity would otherwise be eligible for the Order of
the Golden Dawn, then it shall be entitled to one vote.
C. The Order of the Rose and Cross. The Council of Lords may
award membership in the Order of the Rose and Cross to any
being which they feel worthy. Knights of the Order of the
Rose and Cross are exempt from paying tithes, but are not
permitted to vote.
D. The Order of the Garter. Any being wishing to be a
Knight, but not qualifying for any other order, may join
the ranks of the Order of the Garter by submitting an
appropriate contribution to the Keeper of the Exchequer.
A Knight of the Order of the Garter is not entitled to
vote.
3. Applications for knighthood shall be submitted to the Mundane
Interface. The Mundane Interface shall have the power to
grant knighthood to all qualified applicants.
4. The Council of Lords shall have the power to strip any knight
of his knighthood if his character, reputation or conduct are
such that he is deemed unsuitable to exercise the powers and
perogatives of knighthood.
5. Tithes shall be set by the Council of Lords, and be payable
in advance. For members outside the United States territorial
zone of the planet Earth, the Council of Lords shall assess
such additional costs as may be required.
6. The Mundane Interface shall notify all Knights of any tithes
required to keep their peerage not less than thirty days
Fidonews Page 6 30 Mar 1987
prior to the date the tithes are required. Any Knight who
submits his tithe within thirty days of the deadline shall
not be regarded as having lapsed.
7. No entity shall be a Lord of the Network or hold any other
position within the Intergalactic Sysop Alliance unless they
qualify under all applicable statutes.
8. The Council of Lords shall be five in number, and shall be
elected annually by the Knights. Each Knight may cast one
vote, consisting of five choices for Council of Lords.
9. The Council of Lords shall be elected by ballot cast at a
time selected by the previous Council of Lords, save that
they may not wait longer than eighteen months between
ballots.
10. The Mundane Interface shall notify the Knights of an
impending ballot not less than three months before the ballot
is scheduled to take place. The Mundane Interface shall also
take nominations for Council of Lords up to one month before
the ballot. Any Knight may be nominated for Lord of the
Network by submitting a petition endorsed by ten other
Knights.
11. The Mundane Interface shall close nominations and post the
list of candidates one month before the scheduled ballot. If
less than six Knights are nominated for the Council of Lords,
then the Mundane Interface shall consider them elected
without a formal ballot.
12. The Mundane Interface shall arrange for the counting of all
votes received, and shall post the result. Votes received by
the Mundane Interface after the close of balloting shall not
be counted.
13. At the first meeting of the Council of Lords each year they
shall elect one of their number to be the Emperor of the
Network, who will preside over all meetings of the Peers of
the Realm. They shall also appoint the following officers:
A. The Whipping Boy
B. The Chief Executioner
C. The Grand Wizard
D. The Mundane Interface
E. The Keeper of the Excequer
14. The Council of Lords shall meet when and as they please, and
shall conduct their business as they see fit.
15. A majority of the Council of Lords shall constitute a quorum
at any meeting.
16. Questions of order and procedure not otherwise determined by
these By-Laws or by the parties involved shall be settled by
private duel, or by Trial by Combat.
Fidonews Page 7 30 Mar 1987
17. The Whipping Boy shall, subject to instruction from the
Council of Lords and with the assistance of the Chief
Executioner, represent ISA in its relationships with the
public and the various governments, governmental agencies and
officials with which ISA may be concerned and shall be the
official spokesperson of ISA in regard to all matters of ISA
policy.
18. In the absence or disability of the Whipping Boy, the Chief
Executioner shall assume the duties of the Whipping Boy.
19. The Mundane Interface shall:
A. Be responsible for the maintenance of the corporate status
of ISA and the filing of all reports and certificates
which may be required of ISA under the corporation laws of
the State of Missouri.
B. Maintain the corporate membership and voting records of
ISA.
C. Perform other duties as described in applicable By-Laws,
of which there are plenty to keep any mortal occupied.
20. The Keeper of the Exchequer shall:
A. Be the recipient of all monies of ISA and shall deposit
the same in the name of ISA in a depository of his
choosing.
B. Sign checks drawn by the Whipping Boy in payment of
obligations known by him to be proper and authorized.
C. Post an annual finance report in FidoNews.
21. The Grand Wizard shall:
A. Be responsible for maintenance of the master NODELIST, and
the distribution of the weekly update file thereof.
B. Ensure the smooth operation of the ISA NETWORK as
prescribed by the Council of Lords.
22. There shall be an official publication maintained by ISA, in
the form of a weekly journal, the name of which shall be
FidoNews. A copy of this journal shall be available each week
to every Knight in good standing. The general management of
this journal shall be in the hands of the Lord Chancellor.
The policy of the journal shall be determined by the Council
of Lords.
23. These bylaws may be amended by a majority of the Knights who
are empowered to weild a vote.
24. Without changing their import, the Mundane Interface may from
time to time, on notice to the Council of Lords, renumber
these By-Laws so as to serve the purpose of ready reference.
References in these By-Laws to Articles shall be corrected,
when necessary, by the Mundane Interface to conform to the
renumbered Articles.
-----------------------------------------------------------------
Fidonews Page 8 30 Mar 1987
Steve Butler
SEAdog/OPUS 138/0
PROPOSAL:
Another Addressing Scheme for FIDONET
FidoNet has grown tremendously in the three years that I have
been a FIDO sysop. If the recent growth in REGION 17 is any
indication, the growth spurt isn't over yet.
With growth comes increased traffic which tends to plug up the
mail hour. The next 10,000 nodes will certainly change the way
we move messages through FidoNet. In fact, it should change the
addressing scheme in like manner as the last 1000 nodes took us
to a two layer address.
There is effort underway to patch the current scheme with ZONE
gating and POINT mapping. The mechanism should work, but it is a
bandage put onto an existing structure in an effort to allow
current software to coexist. The current methods for extending
the addressing scheme depend on two added pieces of information:
1) ZONE, and 2) POINT; but these should become an integral part
of the address. Even so, the two additions do not go far enough
to solve some current or future problems.
Since there are major programming efforts underway for nearly all
the FidoNet software, now is the time to discuss alternatives.
This should be done before any development group has committed
themselves to a particular scheme. This proposal is presented as
a basis for such a discussion. The ultimate implementation may
take several years; but having an identifiable long range goal
that all authors are working toward will be much better than the
current method of patching the system when necessary to make it
function for the next iteration.
A multilayered network is needed with an addressing scheme that
is extendable on both ends. In addition, every level could act
similar to today's HOST and HUB designations and take several
features of the proposed ZONE and POINT scheme. This proposed
scheme will use the current terms including ZONE and POINT.
Please look beyond the current meanings and attempt to find a
homogenous application for every term and substitute your own
verbiage for those at variance with your usage.
FUNCTIONAL PARTS
The functional parts of this new addressing scheme are:
term value
DIVISION 0-255
ZONE 0-255
NET 0-255
HUB 0-255
Fidonews Page 9 30 Mar 1987
NODE 0-255
POINT 0-255
This gives a 255 fan out factor at each level which may be too
big! When was the last time you attempted to contact 255
different nodes in one night?
The ZONE could become synonymous with our current REGION. The
DIVISION could initially be identified with the 7 geographical
continents; there could be lots of expansion at the top! The
current NODE (2 bytes) could be split to identify HUB and NODE.
EXAMPLE: Assume that REGION 17 becomes ZONE 17 in DIVISION 1,
my address of 138/0 would be 1\17:138/0'0.0
A shorthand method of entry (similar to today's NET default)
could be devised based on the unique delimiters. Thereby other
nodes in DIVISION 1, ZONE 17 could address 138/ (or either :138
or :138/). The software could default the left side to that of
the current system and default the right side to zero. In fact,
since message packets would never leave that address area, the
short form could be stored.
This would make the ZONE (REGION) and HUB identification an
integral part of the address. Each level could have a second
entry at the NODE level similar to today's method of HOST and HUB
duplicate entries. In fact, it would be constructive to restrict
the usage of the 0 entry such that a 0 would never appear to the
left of a non-zero number. This would facilitate the changing of
HOSTs at any and all levels.
DISTRIBUTED MANAGEMENT
Since the addressing to each level would be unique, each level
would act as the HOST to those immediately beneath (descendants).
This would include the assigning of address numbers and sending
the add, change, delete information to the next higher HOST
(ancestor) and delivering the incoming mail.
This would decentralize the creation of the master node list.
Each level would simply send a DIFF file of his layer (including
the descendants) up to the ancestor (up one level). The DIVISION
systems could exchange the divisional DIFF files and build a
master DIFF file for distribution down through the network to all
the descendants.
In fact, this mechanism could be automated so that each system
knew what changed about it during the past x period of time
(maybe daily at the low levels). It would send the appropriate
DIFF information up. This could start with the POINT informing
the NODE. The NODE's machine could collect all the DIFF
information sent by the POINTs, add the DIFF for the NODE and
send the package up to the HUB. The HUB would collect what was
delivered by the various NODEs and send the appropriate
information up to the HOST. Each level would send the packet IF
Fidonews Page 10 30 Mar 1987
AND ONLY IF there was something to report. Finally, the master
DIFF would be created and distributed back down through the
layers. An option would allow each layer to distribute that
layer's DIFF file. This is on the assumption that the
information within a given area is more critical than that from
down under, up over, or across the way.
The systems could detect the DIFF file and automatically update
the local copy of the nodelist on the fly rather than a batch
operation once a week.
DEFAULT ROUTING
Current routing principles could be extended to all levels.
The sender would route traffic to one level below the lowest
common address. Thus, traffic between POINTs of the same SPONSOR
could go direct, ie, between siblings. Traffic from a NODE would
flow down to the POINT.
Extend this concept up one level and include transient traffic.
NODEs within the same HUB would go direct sibling to sibling.
HUBs within a common NET, etc. Incoming traffic would flow down
one level to the NODE. Likewise, the NET, ZONE, and DIVISION
levels would repeat the concept at their address layer.
A system within a NET (say 1\17:138/) sending traffic to a system
in another NET of the same ZONE (say 105/) would route the
traffic to the INBOUND NET HOST (address 1\17:105/0'0.0 or 105/).
Similar action would happen at the ZONE level within a DIVISION.
Inter-DIVISION traffic is routed between the DIVISION siblings.
Thus, today's principle of routing could be extended to multi-
layer schemes.
In short, the routing could say:
1) Can the traffic be routed through one of my immediate
descendants? Otherwise,
2) Can this be routed through a sibling of mine, ie, we have
the same host? Otherwise,
3) Locate the lowest common ancestor. Go one address level
down and send the traffic to that system.
NOTE: All DIVISIONs are considered to have a common
ancestor (until the scheme is extended).
OUTGATE ROUTING
This routing could take place if the ancestor (next level up
host) has indicated a willingness to serve as an OUTGATE.
Perhaps a flag in the NODELIST is needed or an indication of some
sort to the software that the ancestor (or designee) is serving
Fidonews Page 11 30 Mar 1987
as an OUTGATE.
The default routing would happen until such time as the traffic
leaves the domain of the immediate ancestor. When that happens,
the traffic would be routed to the parent rather than one below
the lowest common ancestor. Thus, traffic going outside the NET
would be routed to the NET HOST (serving as OUTGATE). A similar
function could take place at the ZONE and DIVISION level. Since
the DIVISIONs don't have an explicit ancestor, they would by
definition be in the same "larger address scheme" and would
exchange packets as siblings.
INTER-LEVEL MAIL HOURS
The current NMH of 9:00 - 10:00 UCT for EVERY node in FidoNet
(North American) will become plugged somewhere in the growth to
10K nodes. Certainly by the time there are 100K nodes in North
America, the one hour sacred period will be a thing of history.
To facilitate that move the NODELIST of the future (next 5
years?) will need to support the software developers to a much
higher degree. Let us accept that the current authors will relax
the mail requirements and ask, "What will be the implications?"
This is one scenario. This author invites everyone to think it
through and discuss what changes would be needed to make it work.
Taking a lead from the current POLICY3 statement, the HOST at
each level could dictate the time period that the immediate
descendants MUST be in a MAIL ONLY slot. That is, the HOST has
declared the time period during which traffic will be sent
DOWNWARD. This is done at every level and would be different
time frames. We would assume that a rippling effect would be
seen and that a HOST at any given level could build in a delay of
a few hours to bring his system into low cost time periods (if
necessary).
The NODELIST would carry this information for each system:
1) Times that incoming mail can be accepted.
2) Times that MAIL ONLY is taking place.
3) Times that outbound DOWNLINK will happen.
Each system would observe the DOWNLINK period of the ancestor as
a MAIL ONLY period.
SEAdog 4.0 allows the mixing of outgoing MAIL with incoming BBS
callers. There is indication in the MEADOW echo that Wynn is
being asked to do something analogous. Again, accepting that
within the next five years the "standard" system will allow this
then we see a mechanism for a system to decide if it can place a
call to an intended recipient.
As each system came into its allowed outgoing time frame a check
Fidonews Page 12 30 Mar 1987
is made to see who is flagged to:
1) accept mail.
2) be MAIL ONLY.
3) be almost ready for downlink.
The system could then prioritize the outgoing packets:
1) Those almost ready for downlink. Try to get the bundle
there before the downlink starts.
2) Grab MAIL ONLY slots. (Why compete with BBS callers if
we don't have to?)
3) Whoever else can accept mail.
In this manner, the NMH could become a ZONE MAIL HOUR or even a
NET MAIL HALF-HOUR. HUBs and NODEs would set their own DOWNLINK
schedules independent of the layers above them.
LIMITING NODELIST SIZE
As FidoNet grows larger SysOps will ask themselves if it is
really necessary to carry all those phone numbers. Just as with
the phone system many of the numbers are never used by the
majority of systems. The current POINT talk indicates that
POINTs would not be carried. While the proposal above would
support the POINT entries (certainly, a NODE would need the
descendent POINTs), the general NODELIST could survive without
them. Perhaps an index file could indicate if the address was
valid and point to the entry in the NODELIST. A zero value for
the pointer would indicate that the local NODELIST did not carry
that entry.
Similarly, the current ZONE GATING would keep only the local
"ZONE" in the NODELIST. In the proposed scheme, this could be
correlated with the DIVISION level. Therefore, addresses outside
the local DIVISION might not be in the NODELIST. Albeit, the
structure would allow their presence. Again, a separate index
could indicate the validity of an address without requiring the
entry to be present.
This opens up some "tricks" the could be played. DIVISION level
entries could be added with the phone number of a "local" system
acting as a link to the specified DIVISION. Both the STANDARD
and OUTGATE routing would automatically send traffic to the
"link". The "link" would have the real phone number in it's
DIVISION entry and would forward the traffic.
This mechanism of substituting phone numbers would allow gating
type functions to occur at any layer.
Fidonews Page 13 30 Mar 1987
BENEFITS
The benefits then:
1) Make routing implicit within the address.
2) Negate the need for special node numbers within a DIVISION
to handle gateway functions.
3) Every level acts as HOST/HUB to the immediate descendants.
4) NODELIST preparation and maintenance is decentralized and
automated.
5. Mail Hour becomes a local item rather than an international
incident.
NODELIST ASSISTANCE
Just as with the phone system, occasionally the need arises for a
phone number not contained in the DIVISION nodelist. NODELIST
ASSISTANCE to the rescue. An additional feature could be
supplied whereby a system could send an ENTRY REQUEST and obtain
a NODELIST type entry in return. This request would be routed to
the asked about system. Any node along the path that knew the
complete answer would respond to the request. This response
would automatically be added to the personal nodelist of the
requesting system.
This may not provide all the solutions now being looked at or
for; but, we want to propose something that will bring all of the
current software writers together and to foster the exchange of
ideas throughout FidoNet.
A few nodes in REGION 17 have bounced this idea around. In
addition, certain ideas of the ZONE and POINT concept now being
explored by others were appropriated without giving due credit.
We apologize in advance to Bob Hartman, Thom Henderson and Randy
Bush and wish to credit them for much of the current exploratory
effort underway.
-----------------------------------------------------------------
Fidonews Page 14 30 Mar 1987
Equatorial Communications Company
Satellite Transcription Services
Ken McVay, Opus 340/20
Home of the Old Frog's Almanac
(Data) 604-758-3072
(Voice) 604-758-4137
The information which follows is the result of an article I wrote
some time ago in FidoNews, in which I discussed the exploration
of satellite tranceiver use for matrix mail. This article will
provide others interested in message tranceivers with as bit of
information about one company that provides both hardware and
services.
The company, Equatorial Communications, is based in Silicon
Valley. In Canada, the company's services are provided by
Telesat, a 50% government-owned monopoly. Telesat's use
eliminated the need for Equitorial to operate under Canadian law
as a public utility, with all the bureaucratic nonsense that
would have entailed.
Equatorial was founded to provide low-speed data links that would
be cheaper than telephone company wires, and to market such
network services. They did not wish to compete with high-speed
satellite services, such as those which transmit voice or
television signals.
The following information is taken from the San Jose Business
Journal, September 30, 1985, and is a bit out of date. The
article was sent to me by the company.
"Like Bell selling phones to use with its network, Equatorial
also sells low cost satellit stations for its customers, giving
it wo distinct parts -- a group that makes hardware and one that
provides network services."
"Its customers are primarily large companies that spend millions
of dollars a year on phone lines for computers. Equatorial has
little trouble getting their attention with a way to cut that
part of the phone bill by 20 percent to 50 percent."
"Equatorial sells two types of network services, which use two
kinds of satellite stations. Its first service was distribution
-- a central computer sending data to many sites that could only
receive data, not transmit. Its newer service can connect a
number of sites interactively -- each computer or terminal hooked
to the satellite can receive and send data to others."
I did not request costing data from the company when I spoke with
them - I felt it would be irrelevant at this point. The article
quoted above mentions that the "average investment" is "about
$10,000.00 per site." As that was some time ago, as computer
technology goes, it should now be somewhat lower....I believe
that we are not far from the day when such technology will be
Fidonews Page 15 30 Mar 1987
well within the reach of matrix sysops.
The following data relates to the C200 Series Micro Earth
Station, and was provided by the company upon request...
The system uses a small parabolic antenna, which permits easy
installation.
C Band Satellite performance "is not affected by different
environmental changes such as rainfall."
Receiving Rate: 19.2Kbps, with multiple protocol options.
Overview
The ECC C-200 series Micro Earth Station is a small
Transmit/Receive earth station, suitable for installation on any
premises, to provide data communications between a remote
computer, terminal or personal work station and a host computer
or another remote facility. It is configured as a part of an
Equatorial two way satellite data communications network, which
consists of a Master Earth Station, the satellite, and a number
of Micro Earth Stations. This networking capability is
PARTICULARLY SUITED TO LARGE NETWORKS OF REMOTE STATIONS USED FOR
INQUIRY/RESPONSE APPLICATIONS. (Emphasis mine)
Data Terminal Equipment Interface: The DTE interface has the
following major attributes:
* Two interface ports are provided. Each may operate
independently using the same data communications protocol.
Each can be used with either standard RS232 interfaces or with
RS422 signal levels. Standard RS232 modem control signals are
provided.
* Port Data Interface. Each port may be independently operated
simplex, half duplex or full duplex at any data rate up to
19.2Kbps.
* Port Protocol Interface. The system supports a number of data
communication protocols. The IBM 3270/SDLC family is supported
in a device emulation mode, in which the C-200 appears as a
3705 communications port. Other protocols are also available.
Network Interface: The C-200 receives data from the network at
the rate of 153.6Kbps. This datastream contains packets destined
for all stations on the network through use of broadcast or
individual station addressing....The return path from the Micro
Earth Station to the Master Eaarth Station operates at 1200 bps.
Further technical information may be optained from the company:
Equatorial Communications Company
189 N. Bernardo Avenue
Mountain View, California 94043
(415) 969-9500
Fidonews Page 16 30 Mar 1987
-----------------------------------------------------------------
Fidonews Page 17 30 Mar 1987
Christopher Baker
Metro-Fire Fido, 135/14(0), XP:
Another Mensa Echo:
MENSANS_ONLY
I am beginning a New Mensa Echomail conference for *Mensa members
only. MENSANS_ONLY is available from 135/14. Tie-ins will be
provided to Mensa Sysops upon request to this Node.
The only requirement for participation is verified membership
(past or present) in American Mensa, Ltd., or any of the
International Mensa organizations.
This Echo should not be confused with the General Mensa Echo
coordinated by The Flying PC, 109/612, and Jim Kay. Metro-Fire
also participates in that Echo. MENSANS_ONLY is provided to
augment the services provided in the General Mensa Echo and
differs in that Mensa membership is required for participation in
the MENSANS_ONLY Echo.
For more information on Mensa and the General and MENSANS_ONLY
Echos, SEAdog capable Nodes may GET the file, MENSA.ARC from this
Node. File requests by NetMail message will be honored by the
following NMW.
Mensan Sysops requesting tie-in must provide their Name, Mensa
membership number, date of qualification, and their Node number
for Echo routing. The AREAS.BBS name for the Echo is
MENSANS_ONLY.
Metro-Fire Fido, 135/14, is available at 305-596-8611, 1200 bps,
24 hrs. Access is by verification only. Weekend access is
available by on-line verification.
* Mensa is an international organization of individuals who
have scored in the top 2% of the general population on
various standarized intelligence tests. Mensa embraces no
political, religious, socio-economic, ethnic or racial views.
-----------------------------------------------------------------
Fidonews Page 18 30 Mar 1987
=================================================================
COLUMNS
=================================================================
Well this column has been going on for about a month now,
and I think it's going to be more regular than I initially
thought. It's is much easier to write a few pages every week
than I had originally thought, try it yourself if you don't
believe me! I would love to see someone else do some fairly
regular writing for FidoNews, and I'm sure the editor wouldn't
mind seeing some more contributions either. I had some time this
past week to go through some of the backlog that's been piling
up, so here goes.
First off, I've had a chance to look over some new (to me
at least) modems from US Robotics. The first of these is their
2400 baud internal (Microlink) in the VAR modem package. From
what I understand, this modem is meant for dealers who are
putting together complete packages for a specific application,
however you can usually find a few dealers who will sell it to
you separate. All you get is the internal modem, a registration
card, a FCC ID sticker/card, and one card summarizing the switch
settings and modem commands. This is definitely not the modem
for someone brand new to PCs and telecommunications, however it
may work out well if installing cards and using a modem is
nothing new to you. I paid $240 for mine, and it's been
performing beautifully for the past week. I put the Phonegate on
the shelf as a spare since it did have a few problems (speaker
was never fully off and it sometimes didn't take a command).
Since the modem can be configured for COM1 through COM4, you
should be able to squeeze it in somewhere. I have also been told
that it will work in an AT, many internal modems won't, although
I don't know how fast an AT can be before it stops working, but
it is probably over 8 megahertz. It doesn't have much in the way
of volume control, only a switch for high or low, but the
command set is very nice. One of the better additions to the
Hayes command set is ATI4, which displays the modem's current
settings. This could be very useful if you were having problems
with a program and thought it might be an improper modem
setting. It also has a few internal help screens for a command
summary, a dial command summary, and a S-register functions in
case you lose the card and need some help. US Robotics has also
added a new (to me at least) option on the speaker commands
(ATMx) which turns the speaker on after the last digit is dialed
and off when the carrier is detected, no longer do I have to
listen to the modem dial, yet I can still hear if a person
answers the phone or if the line has been disconnected. It seems
to be working very well, and I am pleased with it's performance.
Another new modem from US Robotics is the Sportster 1200,
an external 300/1200 modem. It's missing most of the status
light that I've come to expect from an external modem, although
it does have the most necessary ones. A power/carrier detect and
a send data/receive data light are just to the right of the
power switch which is on the front of the modem. I haven't given
it as thorough a workout as the VAR modem, but it worked very
Fidonews Page 19 30 Mar 1987
well on the occasions I did use it. One of the nicer things
about the modem is a quick reference to commands and switch
settings on the bottom of the modem, I've had too many problems
with other modems just because someone can't find the book that
came with the modem to not enjoy extra touches like this! To old
timers, the modem will look strange since it's turned sideways
to the way a Hayes is oriented, but as it works well and is
reasonably priced (I believe the list price is $149) I am
satisfied with it and would recommend it to someone looking for
a 300/1200 baud external modem.
I've finally gotten around to looking at TELIX, which I
mentioned a few weeks ago when I reviewed OPUS. I don't think it
will replace ProComm as my communication program, although it
does have the SEAlink protocol which is nice for downloading
from an OPUS board. I just received the latest version this
morning (I was using version 2.10), so I know the version I
looked at is a little out of date, but I everything should still
apply to the new version. The only reason I'll probably stay
with ProComm is because I am used to it, I can still access the
SEAlink protocol (I've got a straight SEAlink program that I
call through the independent editor feature of ProComm), but I
will admit it's easier to use TELIX when I need to use SEAlink.
I'll probably end up using TELIX whenever I call an OPUS, much
the same way as I use KERMIT when I call a UNIX system. Some of
the nice features in TELIX include multiple dialing directories
(each holding up to 150 phone numbers), all my favorite file
transfer protocols (Kermit, SEAlink, Telink, and YMODEM to name
a few), script files, and an automatic redial queue. TELIX only
needs 128K of free memory, which is less than many other
programs, so it may become quite popular with those of you
running a multitasker such a DoubleDos.
It run's very quickly, and if you're starting it up for the
first time it "guides" you through the initial installation
(which com port, what baud rate, monitor type, etc.) which is
very nice. One feature that may have me switch over to TELIX is
it's support of keyboard macros, which I used for my passwords
on different systems (you should NEVER use the same password on
all the systems you use). The manual is fairly easy to read, and
hackers will like the section describing the configuration
file's format. It's a nice program that works well, and I would
recommend it to anyone looking to change communication programs.
The latest version is available from The ASCII Exchange (148/1)
416/622-8254 (SEAdog file requests accepted) and The PC Pub BBS
416/487-2889 and 416/487-4134, both of which also have message
sections dedicated to TELIX. My net host who mailed me the
program is also trying to get the TELIX message section into our
net via echomail, so you may be able to read some more about on
boards in your own net.
As a side note, if you are running TELIX from something
other than it's home directory you must have an environment
variable set to tell it where to find it's support files (SET
TELIX=C:\BIN\TELIX\ in my case). Make sure however that you
include a backslash at the end of the pathname, I've seen too
Fidonews Page 20 30 Mar 1987
many messages in the TECH echomail area on ProComm, we don't
need repeat this bit of history with TELIX, do we?
That about ties it up for this week. Instead of a best book
I'm going to describe "Learning DOS" from Microsoft ($50).
Learning DOS is a disk based tutorial on MS-DOS (or PC-DOS) that
also includes a disk based DOS reference. If you are still new
to your MS-DOS machine or know of someone who is, this program
was written for you. It has 2 versions, one for people on a
floppy based system and another for hard disk users. The
tutorials are complete and include practice sessions and
summaries. It can also provide a hint while you're practicing.
Some of the topics covered include preparing a floppy disk, mode
settings for hardware, fixed settings (autoexec.bat, config.sys,
etc.), and organizing files with directories. It is one of the
best tutorial programs I've seen, and almost completely covers
the topics new users need most.
I'm still trying to beat StarFlight, and have almost
completed Leather Goddesses of Phobos. Hopefully next week I'll
have gotten around to looking at some new games. In the
meantime, I'd like to hear from anyone who has some comments on
anything I've written, so at the least send me some mail. Even
better then sending me some mail is to write something of your
own for FidoNews. My US mail, FidoNet, and USENET addresses are
listed below. If you are a user of a BBS, please mention to your
sysop that mail to me must be routed through 157/0, 157/502, or
157/1. Sysops who send me mail, just make note of the last
sentence. All of those systems are running SEAdog and will
accept a file to forward to me as well. Until the next
column.....
Dale Lovell
3266 Vezber Drive
Seven Hills, OH 44131
FidoNet: 157/504
USENET: ..!ncoast!lovell
-----------------------------------------------------------------
Fidonews Page 21 30 Mar 1987
TALKING ASSEMBLER
by
Ned Sturzer
OpusNODE 362/1 - Chattanooga, TN.
Assembler language has the reputation of being difficult to
learn and use. This is for the most part an unjustified label.
What is true is that a considerable knowledge of the computer
architecture is necessary - more so than in BASIC. It is also
true that I/O is a pain in assembler and it is often useful to
write assembler subroutines and leave the I/O to BASIC. In these
articles I will try to combine the necessary background with
specific programming examples without being too tedious.
As I have to start somewhere I will assume you already know
hexidecimal (hex) notation. It can be mastered in a short time.
Now -- the PC can be thought of as a magic box which performs
logical and arithmatic calculations. The input to and output from
this magic box are stored or pass through three types of waiting
areas: registers, memory locations, and ports. Best known are the
memory locations. Each location is assigned a name,the lowest
being 0 and the highest (in 8088 machines such as the Tandy 1000)
being FFFFF. Thus there are 1 meg of memory locations. Don't
worry about extended or expanded memory for the present. In each
location is to be found 1 byte=8 bits. The standard labeling of
the bits in a byte is
B B B B B B B B
bit # 7 6 5 4 3 2 1 0
You can see that it would require 2 1/2 bytes to store the name
of a location. Instead of worrying about half bytes the following
clever though clumsy ruse is used. A pair of two byte numbers is
used, XXXX:YYYY and this represents the address XXXX0+0YYYY. For
example, address 1A35E may be represented by 1A35:000E,
0C0D:E28E, and many other pairs besides. XXXX is called the
segment and YYYY the offset. In most cases when referring to an
address the segment will already have beeen established and only
the offset will be stored in a memory location. In this situation
the convention is to use the format LSB/MSB (least significant
byte/most significant byte). An offset of 4A87 would appear at
memory locations of say 1339F and 133A0 as 874A. Should it be
necessary to store a full segment:offset type address in a four
byte sequence of memory, the convention is
Offset Offset Segment Segment
LSB LSB MSB MSB
Thus the address 200F3 could appear stored somewhere in memory
as 0F200300, i.e. 200F:0003. In a later article we will discuss
what appears in memory where, that is, the memory map.
While the idea of memory locations will not be unfamiliar to
BASIC programmers, the concept of registers may. Registers are
simply special memory locations distinct from the memory
presented above. The 8088 has 14 such registers each with
Fidonews Page 22 30 Mar 1987
distinct though somewhat overlapping functions. The names of the
registers are AX,BX,CX,DX,CS,DS,ES,SS,SI,DI,BP,SP,IP, and the
last register which does not have a name but is referred to as
the flag register. All 14 registers are 2 bytes (= 1 word) long.
The high and low order bytes of AX,BX,CX, and DX may be addressed
independently and in this case are denoted AH,AL,BH,BL,etc.
Unlike memory, when memory locations are stored in resisters the
MSB/LSB convention is used. The reader should not dispair over
these complexities since the assembler instructions do all the
flipping and shifting themselves.
The details on the use of the registers will come later but a
quick overview is appropriate. The "S" registers are usually set
to contain the segment component of the location of the assembler
program in memory or the segment component of data areas used by
the program. The SS,SP pair usually point to the active stack
location. More on the stack later. The ES register is used in
certain instructions which loop through data areas. The IP
(instruction pointer) register is the offset component of the
next instruction to be executed. The "X" registers are general
notepads for data and are the workhorses of most programs. CX
also functions as a loop counter. The so-called base and index
resisters, BP,SP,SI, and DI, are used to access tables. The flag
register is a set of 9 one-bit switches which represent various
machine states. The remaining 7 bits are not used.
To be useful the computer must be able to read and/or write to
devices external to itself such as a keyboard or printer. This is
effected through the use of ports. There are 64K possible ports
on the 8088 labled 0 to FFFF. It is in the meaning of the port
assignments that the various IBM compatible computers show the
greatest distinctions.
I have covered a large canvas of topics in a short space of
time and have still not covered all the requisite background. If
these concepts are new to you do not be discouraged if they are
unclear in your mind. At this stage it is only important that you
be aware of these ideas, not that you be their master.
At least we may now begin to consider our main interest -
Assembler Language. The computer understands various sequences of
bits to represent operations to be carried out on the contents of
the several memory locations, registers, and ports. Needless to
say a programmer would quickly go bananas trying to write or
interrupt a sequence such as binary 101000111001011000101011.
Even if this sequence is represented by hex A3962B it is still
difficult to think in these terms. Writing in 8088 Machine
Language is obviously tedious and prone to error. Much of this
difficulty is overcome through the use of Assembler Language
which closely mimics Machine Language but is easier to grasp.
Just as important Assembler Language is functionally equivalent
to Machine Language. Consider the Assembler Language instruction
represented by mov [2B96],AX. This instruction tells the computer
to put into memory, starting at the location whose segment is
whatever is contained in the DS register and whose offset is
2B96, the same value as in the AX register. This is exactly the
Fidonews Page 23 30 Mar 1987
function performed by Machine Language A3962B as above. Indeed
the Assembler translates mov [2B96],AX into A3962B. However,
Machine Language 8906962B performs exactly the same function as
A3962B yet both are disassembled to our friend mov [2B96],AX.
Assemblers follow the rule that if two or more Machine Language
instructions perform the function intended by an Assembler
Language instruction then the Assembler will chose the shortest
instruction.
In the next article we will begin discussing the Assembler
instructions in detail. There also remain numerous side topics
which should be explored such as the stack, interrupts, the
memory and port maps, BIOS and DOS.
I'll conclude with a review of the tools you will want to acquire
if intend to write programs in Assembler. Naturally, you will
need an assembler and disassembler. The assembler converts your
Assembly Language program into Machine Language while a
disassembler converts a Machine Language program into Assembler
Language. In these articles I will always use the Microsoft Macro
Assembler 3.01. This package includes both assembler and
disassembler and the manual is complete though obtuse. The
disassembler provided by DEBUG in DOS 3.0 or higher is adequate
but DEBUG's assembler is not. As far as I know a linker is
included with all assembler packages. The Microsoft Macro
Assembler sold by Radio Shack is a low version number. Don't drop
below version 3.0.
A book detailing all the Machine Language instructions is
required. R. Rector and G. Alexy, The 8086 Book, Osborne, 1980,
is a standard. Two books all PC programmers should have
regardless of the language they write in are R. Davies, Mapping
the IBM PC and PCjr, COMPUTE!, 1985, and P. Norton, Programmer's
Giude to the IBM PC, Microsoft Press, 1985. There are a number
of books which assist in teaching you Assembler Language. By way
of example I mention P.Abel, Assembler for the IBM PC and PC-XT,
Reston, 1984. Somewhat more advanced is R. Jourdain, Programmer's
Problem Solver for the IBM PC, XT & AT, Brady, 1986. One of the
best sources for programming technique are the examples in PC
Magazine. Finally, every Assembler Language programmer will need
a DOS Technical Reference Manual (or equivalent). A Technical
Reference Manual for your computer is also useful.
OpusNODE 362/1 - (615) 892-7773 - The Last Resort
Chattanooga, Tennessee - 1200/2400
-----------------------------------------------------------------
Fidonews Page 24 30 Mar 1987
=================================================================
NOTICES
=================================================================
The Interrupt Stack
27 Apr 1987
Start of the Semi-Annual DECUS (Digital Equipment Corp. Users
Society) symposium, to be held in Nashville, Tennessee.
17 May 1987
Metro-Fire Fido's Second Birthday BlowOut and Floppy Disk
Throwing Tournament! All Fido Sysops and Families Invited!
Contact Christopher Baker at 135/14 for more information.
21 Aug 1987
Start of the Fourth International FidoNet Conference, to be
held at the Radisson Mark Plaza Hotel in Alexandria, VA.
Details to follow.
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 FidoNet node 1/1.
-----------------------------------------------------------------
Bill Allbritten, 11/301
I just spoke with a Mr. Mayer of the FCC-(14:30, 26MAR87) about
the decision on re-regulating packet switching networks known as
proposal computer III. He said that today's decision was to
leave things alone, that is to leave the enhanced packet
switcher's deregulated.
-----------------------------------------------------------------
Fidonews Page 25 30 Mar 1987
__
The World's First / \
BBS Network /|oo \
* FidoNet * (_| /_)
_`@/_ \ _
| | \ \\
| (*) | \ ))
______ |__U__| / \//
/ Fido \ _//|| _\ /
(________) (_/(_|(____/ (jm)
Membership for the International FidoNet Association
Membership in IFNA is open to any individual or organization that
pays an annual specified membership fee. IFNA serves the
international FidoNet-compatible electronic mail community to
increase worldwide communications. **
Name _________________________________ Date ________
Address ______________________________
City & State _________________________
Country_______________________________
Phone (Voice) ________________________
Net/Node Number ______________________
Board Name____________________________
Phone (Data) _________________________
Baud Rate Supported___________________
Board Restrictions____________________
Special Interests_____________________
______________________________________
______________________________________
Is there some area where you would be
willing to help out in FidoNet?_______
______________________________________
______________________________________
Send your membership form and a check or money order for $25 to:
International FidoNet Association
P. O. Box 41143
St Louis, Missouri 63141
USA
Thank you for your membership! Your participation will help to
insure the future of FidoNet.
** Please NOTE that IFNA is a general not-for-profit organization
in formation and Articles of Association and By-Laws were adopted
by the membership in January 1987. An Elections Committee has
been established to fill positions outlined in the By-Laws for
the Board of Directors. An IFNA Echomail Conference has been
established on FidoNet to assist the Elections Committee. We
welcome your input on this Conference.
-----------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink