World of Ham Radio 1994 January/AMSOFT_1994.iso/packet/docs/pd199006.doc

Text File | 1993-12-31 | 291.2 KB | 7,008 lines

Fri,  1 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #44
To: packet-radio


Packet-Radio Digest         Fri,  1 Jun 90       Volume 90 : Issue  44

Today's Topics:
         $10,000 cash offer for underground software.
           Comments/Opinions on setting up 4 packet
          How do I get on the TCP/IP mailing list??

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 31 May 90 04:59:56 GMT
From: dasys1![e-mail]  (michael)
Subject: $10,000 cash offer for underground software.
To: [e-mail]

Will pay $10,000 for audio-visual "Mind Control" radio/computer program.
Immediate cash deal.  Send a reply or call (212)-533-4351

------------------------------

Date: 31 May 90 17:08:58 GMT
From: usc!chaph.usc.edu![e-mail]  (Cliff Yamamoto)
Subject: Comments/Opinions on setting up 4 packet
To: [e-mail]

Greetings!

I'm about to purchase some equipment to get involved with packet.  I've
been reading the 10/89 issue of 73 (thanks Steve! - N6UNI) and found it
very informative.

I'm thinking about getting the DRSI PC Packet Adapter and running it with
an Icom IC-24AT.  The 56Kbit GRAPES modem also looks interesting, but I'd
like to solicit a few comments on some questions I have:

- Does anyone have any negative views about the DRSI package?  I'd like to
  get the type one board (one Bell 202 modem and one RS-232 port)

- Is there anyone is the Southern California area running the GRAPES modem?
  If so, what band/transverter is used?

- Can anyone recommend a outboard PA for my Icom HT that can be switched
  quickly enough for use on packet?  Probably something that allow the DRSI
  to control it as well as having a COR.

I'd appreciate any comments and opinions on the above.

Cliff Yamamoto - KA6JRG

------------------------------

Date: 31 May 90 15:41:31 GMT
From: [e-mail]  (Brian Kantor)
Subject: How do I get on the TCP/IP mailing list??
To: [e-mail]

The ham radio tcp/ip mailing list is a technical working group for
people actively involved in advancing the state of the art in amateur
radio networking, with particular emphasis on the use of the Internet
protocol suite.  It is *** NOT *** the place to get beginning
information on tcp/ip or the KA9Q software; you should ask those
questions HERE.

To subscribe from an internet or uucp site, check with your system
administrator to make sure your system isn't already getting the
mailings.  If it is, have your sysadmin add you to the list.

Otherwise, send mail to [e-mail],
with the line
    subscribe tcp-digest
in the body of the mail.  If you do not receive a confirmation of being
added to the list in a day or so, your mail probably has buggered up
headers and the listserver undoubtedly barfed.

Bitnet people should not subscribe in this way to avoid overloading the
internet-to-bitnet mail gateways.  Instead, please look around for
someone in your area who can redistribute it to you.
    - Brian

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat,  2 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #45
To: packet-radio


Packet-Radio Digest         Sat,  2 Jun 90       Volume 90 : Issue  45

Today's Topics:
         $10,000 cash offer for underground software.
            FAX NUMBER OF GRAPES ?
              Potentially dumb question

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 1 Jun 90 15:59:51 GMT
From: cs.utexas.edu!news-server.csri.toronto.edu!neat.cs.toronto.edu!omicron.cs.fsu.edu!fsucs.cs.fsu.edu![e-mail]  (Jim Groh)
Subject: $10,000 cash offer for underground software.
To: [e-mail]

In article <[e-mail]>, [e-mail] (michael) writes:
>Will pay $10,000 for audio-visual "Mind Control" radio/computer program.
>Immediate cash deal.  Send a reply or call (212)-533-4351

A few years back it seems that one of the "game" computers, atari,
commodore, or something had an attatchment, two electrodes to the
head and some software by which the user could control movement on
the screen.  You might check with some atari, etc. gurus on this.
Just make the check out to ;-)


--
+   Jim Groh            +  Worlds Oldest Gradual Student               +
+   Florida State Univ. +    "Where does he get those wonderful toys?" +
+   [e-mail] +                  -- The Joker --             +
+   voice 904-644-8721  + reduced to 4 lines, don't want to be rude    +

------------------------------

Date: 1 Jun 90 18:16:53 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!ousrvr![e-mail]  (Marko Wirtanen)
Subject: FAX NUMBER OF GRAPES ?
To: [e-mail]

Does anyone know the fax number of The Grapes ( if this kind of gadget
exists ) ?
Please send me mail or answer via this newsgoup.

73 Marko / OH8WM


--


 ------------------------------------------------------------------------
    Marko Wirtanen                     E-mail: [e-mail]
 Rakentajantie 5C 406                  Phone: [phone]
    SF-90570 Oulu                      Ham Radio Call: OH8WM / OH3MMW
      FINLAND

      "Once you are in communications, you will never be out of it"
 ------------------------------------------------------------------------

------------------------------

Date: 1 Jun 90 20:57:33 GMT
From: cunixf.cc.columbia.edu!lamont![e-mail]  (bob bookbinder)
Subject: Potentially dumb question
To: [e-mail]

    I've got to be missing something.  I've set up two stations
30 miles apart and both ends are running TCP/IP. I can successfully
run telnet and ftp although it seems to lock up when the link (2m) gets
marginal. When I try to telnet, ftp, ping or otherwise access another
TCP/IP station I don't get past the outgoing ARP. I never get a reply.
I have a valid route (just default to ax0) and I'm transmitting, but
although the station may peg my S-meter it never answers. I suppose the
stations I've tried could have all their servers turned off, but that's
pretty unlikely. I've also tried an arp entry pointed to a local Ax25
node and I've tried netrom routing although I admit I don't fully
understand if I can do that station to station without knowing if a
real (IP) gateway exists.

    Would someone explain the basics. I know I should be able to
get my packets a little further than I'm able to now. I can hear
three or four stations transmitting TCP/IP and my netrom routing table
has lots of stations listed as IPXXX.


                Bob Bookbinder

----------------------------------------------------------------------------------
Lamont-Doherty Geological Observatory of Columbia University
Palisades, New York 10964
Analog:         914-359-2900 X 498
Digital:        [e-mail]
Fax:            914-359-5215
RF:             WA2LWE@WB2COY
-----------------------------------------------------------------------------------

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon,  4 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #46
To: packet-radio


Packet-Radio Digest         Mon,  4 Jun 90       Volume 90 : Issue  46

Today's Topics:
          Field Day rules in re "packet QSO"
            G3RUH 9600 baud modems
        KA9Q for Xenix available on Internet?
               KA9Q information needed
              NET/Mac v2.0 Help
              Potentially dumb question
                 W0RLI help?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Sun, 3 Jun 90 18:25:24 -0700
From: Doug Faunt N6TQS 415-688-8269 <[e-mail]>
Subject: Field Day rules in re "packet QSO"
To: [e-mail]

So, what constitutes a "packet QSO"?  Does a contact with a BBS count,
or do I have to find someone to keyboard to keyboard with?
thanx, and 73, doug

------------------------------

Date: Sat, 2 Jun 90 22:28:55 PDT
From: sox![e-mail]
Subject: G3RUH 9600 baud modems
To: [e-mail]

Johnathan Vail writes:

>Or in the case of a repeater, the repeater can be tweaked to be as flat
>as possible and then each user station tweaks for good match to the
>repeater.  If the repeater is regenerating from the digital signal
>this should work well without having any real problems in trying to
>connect to any random station whose tx/rx characteristics may be
>different.
>
>"The death of God left the angels in a strange position."
> _____
>|     | Johnathan Vail | tegra![e-mail]
>|Tegra| [phone] | N1DXG@448.625-(WorldNet)
> -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

In the case you make here which reciever are you "pre-compensating" for?
The repeater Receiver? or the "random station"? Either way the G3RUH modem
needs to know the IF characteristics of the receiver to which it is transmitting. Otherwise just set the modem for "analog loopback" and forget "pre-compensation". Does your repeater have DC continuity between the Discriminator and the
Modulator? How are you planning to do your regeneration? The K9NG does not do
full duplex and as far as I can tell the G3RUH has problems with doing full
duplex because of clocks.  What I have put together is a G3RUH as a demod. and
a K9NG as a modulator. I still think that there are problems even with this
setup.  The best thing I have seen is a IF translator.  There is no distortion
introduced (if the passband of the translator is wider than the signal) but,
you still have the problem of having to know the "random station's" IF
characteristics to use the "pre-compensation" feature.

73's Tom
KA6SOX
ka6sox.ampr.orc
hub.ucsd.edu!sox!ka6sox

------------------------------

Date: 3 Jun 90 13:35:03 GMT
From: mcsun!cernvax!chx400!fatcat!acadch!impch!subch![e-mail]  (Maxim Samo)
Subject: KA9Q for Xenix available on Internet?
To: [e-mail]

Is there a KA9Q for Xenix available via ftp? Please mail responses to me.

 Maxim
--
        Maxim Samo, P.O.Box, 4125 Riehen, Switzerland
             e-mail: [e-mail]

------------------------------

Date: Fri, 1 Jun 90 12:52:44-050
From: emsca!intevep!servinst![e-mail] (Jose Zapico xt. 7109)
Subject: KA9Q information needed
To: [e-mail]

My name is Jose ZAPICO, working in the research center of oil industries
in the automation area. I'm a ham , and more specific a 'paketeer'.
My callsign is YV5FSF . You can contact me via AX.25 with the following
path [e-mail].

I would like to know how can i do, to contact KA9Q by this way. I need to
know if there is a new revision of the 890421.1 (the revision that I have)
in the KA9Q Internet Software Package. I want to connect to a ethernet 802.3
encapsulation via a 3com503 to one side, and to a KISS modem to the other
side.

Please respond by E-mail.  Can I have your path via some BBS in AX.25.

Thank you.
Jose Zapico.

------------------------------

Date: 2 Jun 90 17:54:49 GMT
From: cs.utexas.edu!ut-emx!lad-shrike![e-mail]  (R M Kriss)
Subject: NET/Mac v2.0 Help
To: [e-mail]

Help, I am looking for someone that has successfully been able to
attach a netrom interface to the Autoexec file for the Net/Mac v2.0
program.

Dick, KD5VU


=====================================================================
   Richard (Dick) Kriss: : ARPANET: [e-mail]
      904 Dartmoor Cove: : Packet Radio: KD5VU @ KB5PM.TX.USA.NA
    Austin, Texas 78746: : Phone: [phone] (O) or 327-9566 (H)
  My employer has nothing to do with this message! ...  _._
=====================================================================

------------------------------

Date: 2 Jun 90 09:13:09 GMT
From: uhccux![e-mail]  (Antonio Querubin)
Subject: Potentially dumb question
To: [e-mail]

My first guess would be that the other station's TXDELAY is a bit too short.
Try the following, open your squelch control and try pinging the other
stations.  If your station picks up the echo, then they either need to increase
their txdelay slightly or you need to leave your squelch open.  This cure will
work only if your receiver has a slow acting squelch gate which can be overcome
by just opening it up.  And it also applies to non-TCP/IP stations as well.

------------------------------

Date: 31 May 90 14:13:59 GMT
From: newstop!east!hienergy![e-mail]  (Jim Vienneau - CSS Project Manager)
Subject: W0RLI help?
To: [e-mail]

>>
>> It's totally amazing that a SW package as widely used and accepted as
>> the W0RLI BBS could be so poorly documented! Having gotten that off my
>
>You get what you pay for, y'know.

Yep, I know. Not meant so much as a flame, more as a puzzlement. With all
the users around the world I am just amazed that no one seems to have
documented it better. It seems to work well once you get it running. Hopefully,
I'll find out first hand one of these days...

Jim Vienneau, Sun Microsystems Inc - Billerica, MA
Email: [e-mail]   Amateur Radio: WB1B
Good old Ma Bell (well old anyway): [phone]

------------------------------

End of Packet-Radio Digest
******************************
Date: Tue,  5 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #47
To: packet-radio


Packet-Radio Digest         Tue,  5 Jun 90       Volume 90 : Issue  47

Today's Topics:
               BBS forwarding exchange.
             W0RLI Documentation.
                White Pages???

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 31 May 90 16:28:58 GMT
From: zephyr.ens.tek.com!tektronix!sequent!mntgfx![e-mail]  (Hank Oredson @ APD x1325)
Subject: BBS forwarding exchange.
To: [e-mail]

There have been several postings requesting information on
how the "BBS net" forwards messages.  There are a number of
different things to consider:  SID  (System ID), BID (Bulletin
ID), use of "OK/NO", the connect exchanges, and command
syntax.  These are all spelled out in my documentation, which
you can get from your local 'rli bbs sysop - via packet.

   ...  Hank - w0rli

------------------------------

Date: 31 May 90 21:14:15 GMT
From: zephyr.ens.tek.com!tektronix!sequent!mntgfx![e-mail]  (Hank Oredson @ APD x1325)
Subject: W0RLI Documentation.
To: [e-mail]

There have been several recent postings that indicate
there are folks out there who would like to write some
documentation for me.  i.e. they complained about the
existing documentation (what there is of it ...).

Please submit the additional / improved docs via packet.
It will be included in the release package.

   ...  Hank - w0rli

------------------------------

Date: 4 Jun 90 18:54:39 GMT
From: att!cbnewsj![e-mail]  (thomas.kenny)
Subject: White Pages???
To: [e-mail]

I have heard that there is such a thing called the "White Pages" which
exist on packet. To my understanding it a listing of people's home BBS.
I believe this data base resides at WA1IIE.ME.USA.NA and have sent
a couple of message to that station via packet and have yet to receive
any replies regarding my inquires on it's availability and functionality.
Is there anybody out there that can tell me more about the "White Pages".
Thanks and 73 DE KB2GLO.

--

  *--------------------------------------------------------------------------*
  |  Tom Kenny, KB2GLO                                                       |
  |  US mail: AT&T, 307 Middletown-Lincroft Rd, Lincroft NJ 07738            |

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed,  6 Jun 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #48
To: packet-radio


Packet-Radio Digest         Wed,  6 Jun 90       Volume 90 : Issue  48

Today's Topics:
               BBS Forwarding Exchange
               KA9Q -- Latest Revision
            Kantronics Data Engine
                  PE1CHL NET
            Questions regarding Kan-Nodes
    Supercharged GRAPE (was Re: Commercial Data Radios: followup.)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Tue, 05 Jun 90 19:00:48 PDT
From: "Roy Engehausen" <[e-mail]>
Subject: BBS Forwarding Exchange
To: [e-mail]

Unfortunately a lot of what's happening is passed by word of mouth (or
packet) between the BBS software developers.  I haven't seen Hank's
documentation but I have some on the "improved BID response" (SID
letter "R") and I have received information from G1NNA describing his
compressed "Packed Send" (SID letter "P").  There is also "Improved
SEND" (SID letter "S") which is being still worked on.

Trying to get a consensus among the 30-40 BBS writers on every
continent makes things go slowwwwwwww.

Roy, AA4RE...

------------------------------

Date: 6 Jun 90 02:20:15 GMT
From: netnews.upenn.edu!eniac.seas.upenn.edu![e-mail]  (James F. Kennedy)
Subject: KA9Q -- Latest Revision
To: [e-mail]

Hello All,
  I'm just getting into the world of TCP/IP on packet and was wondering
where one could pick up the latest revision of Net for the Macintosh.  I
know uunet.uu.net has v1.0 available via anonymous ftp, but I've
heard talk on this newsgroup of later revisions...any help would be
useful.  Please send replies via email to [e-mail] and
I will post a response if there is interest.


                    Thanks in advance,
                        de KB8DPV - James

--
James F. Kennedy - KB8DPV       Internet: [e-mail]
University of Pennsylvania      HAMNET: 146.895- (NE OHIO) 146.68- (Philly)

------------------------------

Date: 5 Jun 90 17:03:08 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Kantronics Data Engine
To: [e-mail]

>>      I am on the Kantronix Beta list... they sent me a "beta" copy of
>> the USERS manual for this beast.... It looks interesting, can can support
>> several types of external modems.   Kantronix even asks developers to let
>> them know if there is need for MORE support for other types of Modems.
>
>I was specifically told by the person who was head of technical development
>at Kantronics a couple years ago that there was no such program for people
>to do reviews or development.  I assumed that people who were developing
>other ROM code for the TNC's were doing so after doing their own reverse
>engineering.
>
>Has there in fact been an effort to allow certain people to develop code
>for these machines that they could have been lying to me about?

I was invited to be an alpha hardware tester for Kantronics, and strongly
encouraged to port the KA9Q NOS package to the box.  I have the code up and
running, albeit with some lingering bugs, and hope to be able to share by
late summer (a lot of business and personal travel planned in the next
couple of months, so not much time to work on things).

Kantronics has, in my opinion, made a 180 degree about-face in their policy
towards experimentation with the DE and their data radios.  The manuals are
and will ship with schematics, and some memory map information.

>Now the question is, has Kantronics in the past acted this way?  Is the
>future going to consist of them not holding back any technical information?

I wouldn't expect them to "not hold back any technical info", but they are
certainly providing more than enough info for anyone who cares to to write
code for the DE.

>Sorry, but I cannot imaging doing software development without worrying, or
>at least knowing, the hardware design.  This is probably because I do work
>with software at the very lowest level and perhaps most programmers never do.
>If Kantronics has the perception of this, and supplies "technical" data on
>how to make use of their low level code without giving me a chance to write
>better low level code, then this machine is not the developer's machine I
>need.  Running a PC and a TNC in KISS mode would serve this need well if I
>were restricted this way.

Calm, Phil... yes, I believe firmly that Kantronics is offering the kind of
documentation you're asking for.  If they don't, I certainly won't ever ship
any software for the box...

Bdale

------------------------------

Date: 5 Jun 90 17:05:29 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: PE1CHL NET
To: [e-mail]

>Is the newest version of PE1CHL NET Atari ST version available via FTP
>somewhere. I have found the MS-DOS version from numerous places, and
>even the revision history for ST(!) but not the ST executables...

I just got mail from Rob, telling me that he'd mailed floppies to me with his
latest work.  When they arrive, I'll put the bits on col.hp.com and announce
availability here... would expect the disks within a week or so.

Bdale

------------------------------

Date: 5 Jun 90 20:12:23 GMT
From: usc!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Questions regarding Kan-Nodes
To: [e-mail]

Me, a novice user to packet radio....  I want to know how Kantranics Network
Nodes work. I finally caved in and bought a PK-88 TNC, got on the air,
and found these Nodes. I figured out what they do.

  What I want to know is how they route. I've seen periodic broadcasts
addressed to 'NODES' about once an hour. Do other Kan-Nodes hear this and
do some form of dynamic routing tables?

  Also, I found that I generally got hung up on (DISCONNECTED) by the
local K6VE-10 (LANODE) when I try to connect with LVNODE, up in Las Vegas.
But if I connect first to BGBEAR (a site between hear and Las Vegas), he'll
connect me to LVNODE. I can also digipeat to BGBEAR and then Connect. Is there
some form of restriction on what the Kan-Nodes do?

  Anyway - a pointer to easily available docs or a simple outline of this
stuff would be interesting....

Dana


*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

Date: 5 Jun 90 17:09:07 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Supercharged GRAPE (was Re: Commercial Data Radios: followup.)
To: [e-mail]

>>transverter I located was priced at $599US.  You still need a controller
>>of some sort, of course, and I read that a street-legal TNC can't
>>cope with 56k on its radio port.  GRAPES uses a bored and supercharged
>>TNC2 - I don't know exactly what they do to it -
>
>Ok, here's our KISS racing secret.  We use a nitro-injected jumper to
>set the clock to a high illegal 8 mhz and then we install Dale's
>ported and polished KISS-56 rom.  A few RAD cuts and solders later,
>and shazam - a street-legal 56kb driver.  :-)
>
>Note that the link to the PC is still 19.2 kb so the thruput is limited
>to this.  We recommend going with one of the aforementioned driver
>boards but a souped up TNC-2 will work in a pinch.  We supply modifications
>and the ROM with the kit.
>
>John

Hi John!

However, note that even with faster chips, 56k is running a Z80-based TNC2
pretty close to the edge.  I modified two TNC's as per the instructions, and
got them finally into a state where they'd transmit fine, and each would
receive one frame and then no more.  I strongly encourage folks considering
playing with the DSY modems to go with PC plug-in cards like the DRSI PCPA or
one of the cheaper alternatives cropping up, or to talk to N4PCR about the
Grace PackeTen card shown for Dayton and available now...

Bdale

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu,  7 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #49
To: packet-radio


Packet-Radio Digest         Thu,  7 Jun 90       Volume 90 : Issue  49

Today's Topics:
            G3RUH 9600 baud modems
          hosts to domain conversion program
        KA9Q for Xenix available on Internet?
            KISS-mode on TNC-1270
               NOS Connections
           Replacement Packet Modem Recommendations
              Supercharged GRAPE

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 6 Jun 90 14:47:44 GMT
From: wang!tegra![e-mail]  (Johnathan Vail)
Subject: G3RUH 9600 baud modems
To: [e-mail]

In article <[e-mail]> [e-mail] writes:

   >Or in the case of a repeater, the repeater can be tweaked to be as flat
   >as possible and then each user station tweaks for good match to the
   >repeater.  If the repeater is regenerating from the digital signal
   >this should work well without having any real problems in trying to
   >connect to any random station whose tx/rx characteristics may be
   >different.
   >

    In the case you make here which reciever are you "pre-compensating"
    for?  The repeater Receiver? or the "random station"? Either way the
    G3RUH modem needs to know the IF characteristics of the receiver to
    which it is transmitting. Otherwise just set the modem for "analog
    loopback" and forget "pre-compensation". Does your repeater have DC
    continuity between the Discriminator and the Modulator? How are you

Obviously the repeater can't compensate for another's reciever since
there are many different recievers using it.  The repeater needs to be
set as you describe to a nominal setting with no pre-comensation.  The
user stations need to match their recievers to the repeater and their
modulators can be adjusted to match the repeater reciever.

    planning to do your regeneration? The K9NG does not do full duplex and
    as far as I can tell the G3RUH has problems with doing full duplex
    because of clocks.  What I have put together is a G3RUH as a demod.
    and a K9NG as a modulator. I still think that there are problems even

Hurrmm.  this is an area of concern.  I have't hooked it up yet but I
was planning on looping the clock and data back into the modem.  I was
running on the assumption that I could do this although I have to
facts to base this assumption.  I have put some thought into it and
the worst case is to add a second G3RUH card.  Easy to do and for a
repeater not too prohibitive.

    with this setup.  The best thing I have seen is a IF translator.
    There is no distortion introduced (if the passband of the translator
    is wider than the signal) but, you still have the problem of having to
    know the "random station's" IF characteristics to use the
    "pre-compensation" feature.

Not only would the repeater have the problem of matching the random
station's reciever but this would bring the problem to every user of
the repeater having to be matched to every other user.  At least with
regenerating each user has to tweak their own radios to mathc *only*
the repeater.



Not being very experienced in this yet I would like to hear more from
people using the G3RUH modem especially in a repeater.  I have a
feeling that by the time I have a working repeater I will have learned
a few things...

73s, jv, N1DXG

"Frisbeetarianism is the belief that when you die, your soul goes up on
the roof and gets stuck." -- button
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!n1dxg

------------------------------

Date: 6 Jun 90 22:53:34 GMT
From: ico!ism780c![e-mail]  (Robert Teeter)
Subject: hosts to domain conversion program
To: [e-mail]

I am posting this for a friend that can'nt do it himself.
This program will take a standard hosts.net file and convert it to
domain.net file.  It doesn't transfer the comments over but will convert all
entries to the new format, also the first entry is considered to be the
master entry.

You can reply to me and I can forward you comments.


------------------------------- cut here ---------------------------

/* hst2dom.c */
/*
**  HOSTS.NET to DOMAIN.TXT conversion program
**
**  Written by: Michael L. Hasenfratz WA6FXT @ K6CPTA.#SOCAL.CA.USA.NA
**              [44.6.0.129]
**
**              Copyright (c) 1990 Michael L. Hasenfratz - WA6FXT
**                        *** All rights reserved ***
**                  permission granted for NON commercial use
*/

#include <stdio.h>
#include <string.h>

#define MAXBUF 512                       /* maximum buffer length             */
#define YES 1                            /* TRUE                              */
#define NO 0                             /* FALSE                             */

/*
** input / output file names
*/
char INFILE[] = {"hosts.net"};
char OTFILE[] = {"domain.txt"};

/*
**  skip over WHITE-SPACE
*/
char *skipwhite( ptr )

char *ptr;
{
  while( *ptr == ' ' || *ptr == '\t' )
    ptr++;

  return( ptr );
}

/*
**  read WORD
*/
char *readword( ptr, iptr )

char *ptr;
char *iptr;
{
  iptr = skipwhite( iptr );              /* skip any white space              */
  while( *iptr != ' '  &&
     *iptr != '\t' &&
     *iptr != '\n' &&
     *iptr != '#' )
    *ptr++ = *iptr++;

  *ptr = (char) NULL;                    /* set EOF                           */
  return( iptr );                        /* return the updated iptr           */
}

/* ************************************************************************** */

/*
**  Main program
*/
main()

{
FILE *infile, *otfile;                   /* File pointers                     */
char *iptr, *ptr, fname[MAXBUF], name[MAXBUF], buf[MAXBUF];
int i, j, first, finish, ch, adr1, adr2, adr3, adr4;

/* open the files */

  if( (infile = fopen( INFILE, "r" )) == NULL ) {
    perror("hst2dom: Error during OPEN of INFILE - ");
    exit(1);
    }

  if( (otfile = fopen( OTFILE, "w" )) == NULL ) {
    perror("hst2dom: Error during OPEN of OTFILE - ");
    fcloseall();
    exit(2);
    }

/* read each line one line at a time */

  while( (ch = fgetc(infile)) != (int) EOF ) {
    if( ch != ' ' && ch != '\t' ) {
      if( ungetc( ch, infile ) == (int) EOF ) { /* put it back                */
    perror("hst2dom: Error during UNGETC - ");
    fcloseall();
    exit(3);
    }

      if( ch == '#' || ch == '\n' )  {   /* is it a comment line?             */
    fgets( buf, MAXBUF, infile);     /* get the string                    */
    if( ch != '#' ) {                /* we skip comments                  */
      fputs( buf, otfile );          /* copy it to OUTPUT file            */
      fputs( buf, stdout );          /* copy it to OUTPUT file            */
      }
    }

      else {
/* read the 4 address octets */
    fscanf( infile, " %u.%u.%u.%u", &adr1, &adr2, &adr3, &adr4);

/* read the rest of the line in */
    iptr = fgets( buf, MAXBUF, infile); /* get the rest of the string     */

/* read the LIST of names */
    first = YES;                     /* set the FIRST flag                */
    finish = NO;
    iptr = buf;                      /* set the buffer pointer            */

    while( !finish ) {
      iptr = readword( name, iptr ); /* read a word into 'name'           */

      if( name[0] != (char) NULL ) { /* check for comments                */
        if( first ) {
          first = NO;                /* clear the flag                    */
          strcpy( fname, name );     /* copy the name                     */
          fprintf( otfile, "%s.\tIN\tA\t%i.%i.%i.%i\n",
                             fname,
                              adr1,
                              adr2,
                              adr3,
                              adr4 );

          fprintf( stderr, "%s.", fname );
          for( i = 0; i < 30 - strlen( fname ); i++ )
        fprintf( stderr, " ");

          fprintf( stderr, "IN   A        %i.%i.%i.%i\n",
                            adr1,
                            adr2,
                            adr3,
                            adr4 );

          } /* endif */

        else {
          fprintf( otfile, "%s.\tIN\tCNAME\t%s.\n", name, fname );

          fprintf( stderr, "%s.", name );
          for( i = 0; i < 30 - strlen( name ); i++ )
        fprintf( stderr, " ");

          fprintf( stdout, "IN   CNAME    %s.\n", fname );

          } /* endelse */

        } /* endif */

      else
        finish = YES;

      } /* endwhile */
    } /* endelse */
      } /* endif */
    } /* endwhile */

  fcloseall();                           /* close ALL files                   */
} /* hst2dom.c */

---------------------------------EOF----------------------------------------


73's de Mike WA6FXT @ K6CPTA.#SOCAL.CA.USA.NA [44.6.0.129]

------------------------------

Date: 6 Jun 90 15:51:35 GMT
From: ogicse!littlei!foobar![e-mail]  (Jim Garver)
Subject: KA9Q for Xenix available on Internet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Maxim Samo) writes:
>Is there a KA9Q for Xenix available via ftp?
>
I am also interested in any packet software available for Xenix,
particularly TCP/IP stuff.  I have some Intel 310 systems and want to
set up a node.  I know that KA9Q exists in Unix source, but not being
a Unix wizard, I don't know the difficulty of porting to Xenix, let alone
making it work in the first place.  Thanks in advance.

--
Jim Garver     Intel Corp.   <tektronix!psueea | uunet!littlei>!foobar!jim
 WA7LDV     Hillsboro, Oregon              jim@foobar<.hf.intel.com|.uucp>

------------------------------

Date: 6 Jun 90 20:24:16 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!lth.se!lo-9![e-mail]  (Anders Sandberg)
Subject: KISS-mode on TNC-1270
To: [e-mail]

KISS-mode seems like a nice mode to use if you want to create your own
software for a TNC. For example using a PC as a host for a node or BBS.
However, this requires the knowledge of KISS-mode, something we haven't
got.
So if anyone has documentation of what the TNC recognizes as commands
, what you should feed it with and what kind of format the output comes in.
(Seems like some characters get the doubled ASCII-value.)
We at the Club at Lunds Institute of Technology ,Sweden would greatly
appreciate a e-mail of some kind.

Wishes from SK7PI,  (own call SM6/7ORZ)

------------------------------------------------------------------------------
Anders Sandberg       student in electrical engineering

email   [e-mail]       VAX 8530
    [e-mail]         SUN/VAX workstations
addr    Magistratsv. 55F-204     222 44 LUND    SWEDEN
phone   046 - 14 29 33


--
-------------------------------------------------------------------------------------
Anders Sandberg       student in electrical engineering

email   [e-mail]       VAX 8530
    [e-mail]         SUN/VAX workstations
addr    Magistratsv. 55F-204     222 44 LUND    SWEDEN
phone   046 - 14 29 33

------------------------------

Date: Mon 4 Jun 90 07:53:39-EST
From: [e-mail]
Subject: NOS Connections
To: [e-mail]

Why is it that when I run NOS that I cannot connect to my local NET/ROM
node, then connect back to myself to get a "mailer"?  I just get a Busy.
In addition, when one of my buddies (who is not running TCP/IP) tries to
connect to me, he also gets a Busy?

I used to use NET and this worked OK.  What is the major difference between
NET and NOS?

Len WF2V
-------

------------------------------

Date: 6 Jun 90 20:40:29 GMT
From: att!cbnewsh![e-mail]  (joseph.e.wilkes)
Subject: Replacement Packet Modem Recommendations
To: [e-mail]

I want to replace my GLB TNC-2 with a better modem.

I was all set to get the PK-232 when a friend at Dayton who was
selling his  PK-232 recommended the KAM.

Any opinions would be appreciated.

Also do I need the additional software for the modems?
I am currently using PTP with the TNC-2.
Are there better programs than the ones the modem manufacturers sell?

Joe Wilkes
att!hound!wa2sff

------------------------------

Date: Wed, 6 Jun 90 09:22:47 EDT
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: Supercharged GRAPE
To: [e-mail]

>>Ok, here's our KISS racing secret.  We use a nitro-injected jumper to
>>set the clock to a high illegal 8 mhz and then we install Dale's
>>ported and polished KISS-56 rom.  A few RAD cuts and solders later,
>>and shazam - a street-legal 56kb driver.  :-)
>>
>>Note that the link to the PC is still 19.2 kb so the thruput is limited
>>to this.  We recommend going with one of the aforementioned driver
>>boards but a souped up TNC-2 will work in a pinch.  We supply modifications
>>and the ROM with the kit.
>>
>>John
>
>Hi John!
>
>However, note that even with faster chips, 56k is running a Z80-based TNC2
>pretty close to the edge.  I modified two TNC's as per the instructions, and
>got them finally into a state where they'd transmit fine, and each would
>receive one frame and then no more.  I strongly encourage folks considering
>playing with the DSY modems to go with PC plug-in cards like the DRSI PCPA or
>one of the cheaper alternatives cropping up, or to talk to N4PCR about the
>Grace PackeTen card shown for Dayton and available now...

We've had better luck with hacked TNC-2's here (in most cases, running at
the usual 4.9 MHz clock rate, not 8 MHz, BTW)... but I certainly agree this
is not the way to go for interfacing the DSY modem to a PC.  However,
the DRSI board (with Phil's HS driver) is not really the way to go either,
especially if you want to be able to attach any interfaces in addition to
the 56kb modem (the driver has a one-track mind).  The PackeTen board is an
extremely impressive piece of work, but it's overkill if you just want to
hang a 56kb modem and a lower-speed port or two on a PC.

Here in Ottawa, we're working on one of those "cheaper alternatives".
Initial tests of the first prototypes indicate that they will easily
outperform the DRSI/HS combination.  So save those ducats for a little
longer, and stay tuned for further news...

Barry  VE3JF

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri,  8 Jun 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #50
To: packet-radio


Packet-Radio Digest         Fri,  8 Jun 90       Volume 90 : Issue  50

Today's Topics:
              G3RUH Full Duplex
               HD4040 assistance please
              Packet-Radio Digest V1 #49

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 7 Jun 90 13:25 -0700
From: Doug Collinge VE7GNU <djc@[e-mail]>
Subject: G3RUH Full Duplex
To: [e-mail]

>X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)

The G3RUH can't do full-duplex?  I don't see why that would be.  By my
recollection he uses the TX clock as the reference for the DPLL that
extracts the RX clock and that should work OK as long as the remote TX
clock is reasonably close in frequency to the local TX clock.  If not,
you could always chop it and put in your own clock.

While we're at it, does anyone know why he has what appears to be an
analog loop filter in his DPLL?  I guess it is really a Hybrid PLL.
It seems to me cheaper/easier to do that filter in logic.

73 doug


--
/\/\/\/\/\/
Doug Collinge,  first try: [e-mail]
        then try:  samisen![e-mail]
VE7GNU          VE7GNU@VE7GNU.#VIC.BC.CAN.NA
        Victoria, BC, Canada

------------------------------

Date: Thu, 7 Jun 90 10:02:07 EDT
From: Alex Bodnar (STEAP-IMD 5545) <[e-mail]>
Subject: HD4040 assistance please
To: [e-mail]

i just recieved an answer from Heath Co telling me that there are NO
upgrades to the HD4040 tnc. i am fairly sure that i remember a few
months ago someone on the net upgraded theirs. if anyone has any
information on how to upgrade the HD4040 please send answers directly
to me.   THANK-YOU in advance.
alex bodnar
KA3CIM

------------------------------

Date: Thu, 7 Jun 90 14:49 N
From: Urs Baer <[e-mail]>
Subject: Packet-Radio Digest V1 #49
To: [e-mail]

PLEASE REMOVE [e-mail] MANUALLY BECAUSE THE LISTSERV
DOESN-T WORK.


    MANY THANKS, URS (HB9DIL)

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat,  9 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #51
To: packet-radio


Packet-Radio Digest         Sat,  9 Jun 90       Volume 90 : Issue  51

Today's Topics:
      56 kb/s packet assembler/disassemblers (aka TNCs)
            concerns over TCP/IP (2 msgs)
                  PE1CHL NET

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 8 Jun 90 21:46:23 GMT
From: swrinde!zaphod.mps.ohio-state.edu!usc!srhqla!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: 56 kb/s packet assembler/disassemblers (aka TNCs)
To: [e-mail]

I recently bought a handful of 80C152JC chips from Intel. These are
16 Mhz 80C51 CPUs with an SDLC controller integrated on chip. My intention
is to use these in low parts count 56 kb/s KISS TNCs (1 cpu + 1 EPROM + 1 RAM
+ 1 latch + 1 rs-232 chip). Current drain should be low ( < 100 mA at 5V ).
(I plan to power then with the little wall adapters (9VDC@150 mA type things)).
Right now, I need to build two so they can talk to each other for testing.
At some point I need to hook up with someone who has 56 kb/s modems (like
the recently discussed GRAPES modem) to actually try these things.

  (a) is there anyone around So Cal who is working with 56 kb modems?
  (b) is this pointless given that anyone can put an Eagle in a PC and
      run 56 kb/s (I'm assuming this is true) ?

 * Point (b) is mitigated by the fact that someone may wish to hook up a
non-PC (like a mainframe) to packet.

*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

Date: 8 Jun 90 11:14:49 GMT
From: uhccux![e-mail]  (Antonio Querubin)
Subject: concerns over TCP/IP
To: [e-mail]

I have a problem which some of you may have already run into and
I hope can offer some advice on.  Some friends and I were planning
on running TCP/IP on the local packet network.  When various people
got wind of this, particularly the folks who have turned all the
major local digipeaters into ROSE nodes (it's their equipment), I
started hearing 'concerns' about TCP/IP's effect on the packet
channels.

Most of the concerns seem to center around increased congestion on
the packet channel we chose to run on.  I've monitored that
frequency (145.01) and detect very little activity on it and
therefore don't really see what the big concern is all about.  The
number of people who are considering experimenting with TCP/IP is
less than a dozen.  Yet, some folks have told me that they have
'heard' stories of a few TCP/IP stations tying up packet channels
elsewhere on the mainland.

Another concern is that some folks have invested heavily into
turning their TNCs into ROSE nodes and don't want to see their
investment in time and money go to waste.  This concern has me a
bit confused - as long as a ROSE node can perform traditional AX.25
digipeating I don't see why their efforts are being wasted.  Is
there something about KA9Q digipeating through a ROSE node that I
should know about?

Other concerns seem to result from a lack of understanding just
what TCP/IP is all about and how it fits in with AX.25.  Most hams
around here don't even understand AX.25 or the OSI reference model.
Does there exist a short collection of important Questions &
Answers about TCP/IP, as it applies to ham radio, and where can I
find it?  I may have to do a little bit of educating to alleviate
some imagined fears.

I will be traveling up to the mainland for one semester to do some
research beginning in August so I don't have much time left to
continue playing mid-wife to this as yet unborn network.  I am
seriously tempted to drop the project until I return in half a
year.  But the problems previously mentioned will still be there.
I would appreciate hearing anyone's thoughts on the above
especially if they can help me anticipate some of these 'concerns'.

AH6BW
Internet:  [e-mail]
BITnet:  antonio_querubin-manoa@uhplato

------------------------------

Date: 9 Jun 90 03:52:19 GMT
From: uc!shamash![e-mail]  ( VTC)
Subject: concerns over TCP/IP
To: [e-mail]

I think I know what 'the other' people were worried about.  It is
possible to totally, completely hog a channel with KA9Q net, but
it doesnt have to be that way.  You can change the window sizes
that net uses to be just about anything you want.  If you set it
up to transmit 4000 byte packets, it will take about 10 seconds to
transmit it.  This gives the appearance of hogging the channel, and
it does.  What you have to do is make a good impression, and keep
you tcp window's to a value that is fair to other users on the
channel, like maybe 256 instead of 4000 or 8000, etc.  If you
experiment, you will find that large windows can make a drastic
improvement on thruput, and I expect that some people have taken
advantage of that on a shared channel, thus giving TCP/IP a bad
name.  Phil Karn ( KA9Q ) has just put in alot of info on how to
adjust the window's and such into the NOS documentation.  If you read
it you will be able to set things up on a shared channel.

Saying all that - please be aware that KA9Q TCP/IP is designed to NOT
hog the channel, because it will backoff it's transmissions if it
detects collisions.  Also, it uses KISS mode which has programmable
parameters to keep things flowing right on the channel.

SO........

If you are on a public, shared channel - keep reasonable and sane
windows and they won't even know you are there.

If you have your own private TCP/IP only channel, open things up
to the max, and they will drool with envy when they see your
thruput.

I urge you to experiment/study these things, and then please
have a meeting with these people to set the record straight. There
is no reason that TCP/IP should have a bad name.

Jeff

------------------------------

Date: 6 Jun 90 00:05:45 GMT
From: usc!cs.utexas.edu!mailrus!umich!pmsmam![e-mail]  (Bill Meahan)
Subject: PE1CHL NET
To: [e-mail]

In article <[e-mail]> [e-mail] (Bdale Garbee) writes:
>>Is the newest version of PE1CHL NET Atari ST version available via FTP
>>somewhere. I have found the MS-DOS version from numerous places, and
>>even the revision history for ST(!) but not the ST executables...
>
>I just got mail from Rob, telling me that he'd mailed floppies to me with his
>latest work.  When they arrive, I'll put the bits on col.hp.com and announce
>availability here... would expect the disks within a week or so.
>
>Bdale

Mike Curtis, WD6EHR is the US distributor for the ST version.
Send him 2 DS or 3 SS ST disks and a note telling him what you want
and he'll get back to you ASAP (1 week for me).

Mike's address is:
    7921 Wilkinson Ave.
    North Hollywood, CA 91605-2210
    [phone]

The version I got is 900517

--
Bill Meahan  WA8TZG             uunet!mailrus!umich!pmsmam!wwm
I speak only for myself - even my daughter's cat won't let me speak for her!

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon, 11 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #52
To: packet-radio


Packet-Radio Digest         Mon, 11 Jun 90       Volume 90 : Issue  52

Today's Topics:
             concerns over TCP/IP
            KISS-mode on TNC-1270

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 10 Jun 90 23:48:18 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: concerns over TCP/IP
To: [e-mail]

In article <[e-mail]> [e-mail] (Antonio Querubin) writes:
>[...]  Some friends and I were planning
>on running TCP/IP on the local packet network.  When various people
>got wind of this, particularly the folks who have turned all the
>major local digipeaters into ROSE nodes (it's their equipment), I
>started hearing 'concerns' about TCP/IP's effect on the packet
>channels.  [...]

It seems that this myth will never die. I have worked very hard to make
my TCP/IP/AX.25 code about the most "channel-friendly" software in
amateur packet radio by including the following features. Most are, as
far as I know, unique to my code:

1. Both my TCP and AX.25 code automatically measure the times taken to
receive acknowledgements and use them to set their retransmission timers
(commonly referred to as "FRACK" in AX.25 TNCs). More recent versions do
a more sophisticated set of measurements suggested by Van Jacobsen. The
variance of the round trip time is also measured, yielding a measure of
the "unpredictability" in the path. I.e., the more unpredictable the
round trip time, the longer the timeout even if the average remains the
same. This set of procedures dramatically reduces the unnecessary
retransmissions you see so often from plain AX.25 TNCs with fixed,
"triggerhappy" FRACK settings.

2. Both TCP and AX.25 "back off" on each retransmission. That is, for
each unsuccessful retransmission attempt, the timeout is doubled for the
next attempt. This provides some negative feedback when the channel gets
congested.

3. The KISS TNC, which was originally developed specifically for TCP/IP
operation (but is not limited to it), specifies the use of
"p-persistence" for channel access. When properly configured,
p-persistence greatly reduces the "jump on" phenomenon whereby several
stations waiting for the channel all begin to transmit the instant the
station already on the channel finishes.

I should point out that in packet radio, as in real life, being a nice
guy usually means you finish last. Stations using my code often get much
poorer throughput when they have to contend with more agressive stations
that don't follow the same rules (which means almost other stations).
Many users of my code have long complained about this and some have made
local modifications to increase its "agressiveness", but I have resisted
such measures in the standard version because I want to set an example.

The only valid basis for complaint about TCP/IP is that it is so useful
and convenient a tool for transferring mail and files that its users can
easily keep a channel busy for hours with little effort. That's why I've
worked very hard to make my code as deferential as possible to other
traffic on the channel.

Phil

------------------------------

Date: 11 Jun 90 06:10:40 GMT
From: bellcore-2!ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: KISS-mode on TNC-1270
To: [e-mail]

The KISS TNC interface is documented in the paper "The KISS TNC: A
Simple Host-to-TNC Communications Protocol" by K3MC and myself. It
appears in the proceedings of the 6th ARRL Computer Networking Conference
held in Redondo Beach CA  on August 29, 1987.

I believe you can find the troff source to this paper on flash.bellcore.com;
however that machine is down right now so I can't check.

Phil

------------------------------

End of Packet-Radio Digest
******************************
Date: Tue, 12 Jun 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #53
To: packet-radio


Packet-Radio Digest         Tue, 12 Jun 90       Volume 90 : Issue  53

Today's Topics:
             56 kb TNC revisited
            CD-ROM and 386-unix ?
            concerns over TCP/IP (3 msgs)
              DVR-2 at 9600 Baud
         Gateway from Packet to the Internet
              HD4040 assistance
        KA9Q for Xenix available on Internet?
            KISS-mode on TNC-1270
                  PE1CHL NET
                Tncs (2 msgs)
                TNC Simulation
                What is ROSE?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 11 Jun 90 20:38:04 GMT
From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: 56 kb TNC revisited
To: [e-mail]

 Recently I posted that I'm working a simple, low parts count, low cost
56 kb packet assembler-disassembler (PAD), another term for TNC. I'd
suggested a 19kb serial interface for the host. Most folks who sent me
mail didn't talk about this, except for one guy in San Diego who actually
has on-the-air experience. He said "it's pointless" to run a serial host
link, that I really need a bus attach interface. He's sorta right, too.

  But bus attach is very restrictive. I want to make an item people can
connect to their PCs, of course, but I think the future of high speed
packet is in connecting VME systems, RS/6000 Micro-Channel Systems,
Sun systems, you name it, to packet links. You can't build bus interfaces
for all these machines (try building a bus card for a Sparc Station SLC :-).

  There are two popular parallel interfaces around today. One is IEEE-488
and the other is SCSI. SCSI is increasingly popular among the smaller and large
systems (like Sparc Station SLC). It offers relatively high throughput. The
physical addressing on the bus is limited to seven peripherals (excluding
any attached directly to the SCSI controller) but each physical peripheral
can have up to eight sub-units. A multiport PAD would easily use this
addressing.

  You might have guessed. I plan to use SCSI. The C152 is ideal for a SDLC
to SCSI connected PAD. Driver software is a little funny. I'd suggest
building standard network drivers for standard ports of Unix, etc. For PCs,
one would need an inexpensive SCSI card. The Micro-Channel machines (PS/2
and RS/6000) have a variety of IBM supported cards available. Sun machines
and Macintoshes all have SCSI connectors on the back. At some point NOS drivers
will need to be cranked out.

  This started out as a whim, but I think packet ought to get with the 90s
and draw in more nodes directly attached to greater variety of hardware. One
way to do it is higher channel speeds, another way is high speed attach to
all kinds of machines (I wonder if a 370 channel to SCSI adaptor is available
? ;-)

73 -
Dana
*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

Date: 11 Jun 90 13:39:28 GMT
From: rochester!rit!cci632![e-mail]  ( co-op)
Subject: CD-ROM and 386-unix ?
To: [e-mail]

I am considering purchasing a CD-ROM player for my computer, with the
ham-radio callsign database.  Before I do this, I want to know that
the thing will work under Unix (it's meant for DOS).  Has anybody
any experience with this contraption?  Specifically, does it look
(to the kernal) enough like a floppy or hard drive that I could
"mount" it from Unix as a dos partition, and access the database?

(Also: does anybody out there know how this callsign database gets
updated, and what it costs to get the new discs?)

Chris, N2JGW
cci632![e-mail] (or Pnews, or whatever path works)

------------------------------

Date: 11 Jun 90 13:33:33 GMT
From: rochester!rit!cci632![e-mail]  ( co-op)
Subject: concerns over TCP/IP
To: [e-mail]

The static inertia of society is tremendous, and it is no better in
many parts of the ham-radio community.  Here are a few other pieces
of resistance I have personally encountered:

- Equipment.  "Will my C-64 work?"  "Is there a CP/M version for my
    shoe-box that I bought for $20.00 at a hamfest?"  etc.
    I'm not sure if these people feel "threatened" that their
    "stuff" will be forced into an early grave, but there
    needs to be an effort to educate people that this stuff
    already *IS* outdated.  The concensus _seems_ to be that
    those of us who are CAPABLE of doing development on
    this hardware choose not to do development because we
    are snobbish (stuck up, arrogant, etc.) about our hard-
    ware.  In reality, enough people have found that such
    development is not worthwhile (for one reason or another)
    that there _must_ be some reason for it.

- Unprintable characters.  This is one of my favorites.  I have gotten
    many, many dirty looks from people who have met me with
    comments about how my TCP/IP "garbage" has locked up
    their terminal or computer, or gone through a whole box
    of paper.  I'm not sure why everybody is printing out ALL
    activity on the channel, but there are lots of people
    doing it.  (I have thought on occasion that if I were
    IP coordinator, I would assign addresses made up of
    combinations of formfeeds and bells :-) :-) :-) hehehe)

- "What we've got now works, so don't mess with it."  This one makes
    me madder than h ... (better not say it).  My best
    example is with binary file transfer.  Software updates
    were coming from across the lake, and I suggested that
    binary FTP would be a great way to do it.  A room full
    of people told me that they'd rather BSQ (sorta like
    uuencode) the whole thing and transfer it into a capture
    buffer, then decode it back to binary.  Talk about freq.
    clogging -- in addition, you're not adding ANOTHER 50%
    overhead.

- Commercial interconnection.  Many people hear "TCP/IP" and think,
    gee, next we'll be plugging into Internet and our
    default routing will be landline.  I personally see
    a lot of merit to having a few "wormholes" until we
    have a truly national IP network, but I _don't_ think
    this is the goal.

- "I don't like the way TCP/IP handles e-mail".  I am **TOTALLY**
    without explaination for this one.  When I asked why,
    I only got, "I just don't like it."  The idea that
    TCP/IP is a suite of protocols has not gotten through
    to the non network-y types; perhaps this is part of the
    problem?


Right now, I am running PA0GRI NOS.  It is VERY unstable (if
    someone has made the GRI mailbox work with a more
    recent version of NOS, **PLEASE** let me know!!!)
    Using this software has helped to a degree, because
    of the gateway features, and because of the organization
    of the mailbox.  Another good package is MSYS, a BBS
    which supports TCP/IP.  (MSYS is missing one thing: you
    can only telnet to the sysop, you can't telnet into the
    BBS).

My approach to a lot of these problems hinges on me getting a
    new computer, running U*ix, because I feel I can do a much
    better job of presenting what TCP/IP can do once I get some
    remotely-accessible software running.  DOSGATE is a neat
    idea; a Unix "version" of this idea would really be a
    knockout!!!


Best 73's
    Chris, N2JGW

------------------------------

Date: 12 Jun 90 02:16:21 GMT
From: zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun![e-mail]  (Jon Bloom)
Subject: concerns over TCP/IP
To: [e-mail]

In article <[e-mail]>, [e-mail] ( co-op) writes:
>
> - Equipment.  "Will my C-64 work?"  "Is there a CP/M version for my
>       shoe-box that I bought for $20.00 at a hamfest?"  etc.
>       I'm not sure if these people feel "threatened" that their
>       "stuff" will be forced into an early grave, but there
>       needs to be an effort to educate people that this stuff
>       already *IS* outdated.  The concensus _seems_ to be that
>       those of us who are CAPABLE of doing development on
>       this hardware choose not to do development because we
>       are snobbish (stuck up, arrogant, etc.) about our hard-
>       ware.  In reality, enough people have found that such

Funny you should mention it... I got a letter just today from someone
exhibiting exactly that complaining attitude.  Now I have to tell him
that yes, Virginia, CP/M _is_ obsolete technology.

>       doing it.  (I have thought on occasion that if I were
>       IP coordinator, I would assign addresses made up of
>       combinations of formfeeds and bells :-) :-) :-) hehehe)

Oh, I like that!  Think I'll assign 44.88.7.12 next!

> - "I don't like the way TCP/IP handles e-mail".  I am **TOTALLY**
>       without explaination for this one.  When I asked why,
>       I only got, "I just don't like it."  The idea that
>       TCP/IP is a suite of protocols has not gotten through
>       to the non network-y types; perhaps this is part of the
>       problem?

Actually, the number one problem I've run into is, "You mean I have
to leave the computer on ALL THE TIME??"

Jon

--
Jon Bloom, KE3Z                              | American Radio Relay League
Internet: [e-mail]         |
Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."

------------------------------

Date: 12 Jun 90 08:01:55 GMT
From: bellcore-2!ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: concerns over TCP/IP
To: [e-mail]

In article <[e-mail]> [e-mail] (Christopher Piggott - co-op) writes:
>The static inertia of society is tremendous, and it is no better in
>many parts of the ham-radio community.  Here are a few other pieces
>of resistance I have personally encountered:

[long list of unbelievably brain-damaged excuses deleted for brevity...]

Now you see one of the reasons I'm so strongly in favor of a no-code license
that would attract more technically oriented people to the service.

I certainly welcome the participation of any and all existing hams in TCP/IP
and related developments such as DREAMNET (N6GN et al's megabit microwave
project), but I harbor no illusions about ever garnering more than a small
fraction of the existing amateur population. That's why it's important to go
outside the existing pool for new blood.

Phil

------------------------------

Date: Tue, 12 Jun 90 03:31:27 EDT
From: [e-mail]
Subject: DVR-2 at 9600 Baud
To: [e-mail]

Can anyone tell me what the exact deviation is on a DVR-2 running a G3RUH
modem at 9600 baud?  My calculations come up to somewhere around +/- 8 Khz
for a total bandwidth of around 16 Khz, but I would appreciate hearing from
someone who might actually be using this setup and has measured it "under
load" so to speak.

I am putting this setup on a 1500 foot tower and need to put a crystal
filter in the front end of the DVR-2 and am trying to figure out exactly
what I need to tell the people that are going to make it.  :-)  I figured
that if it spec'ed out at 20 Khz that I would be OK.

Comments?  Help?  Words of Wisdom?

Thanks!

Mark Bitterlich
wa3jpy@wb4uou
[e-mail]

------------------------------

Date: 11 Jun 90 20:11:56 GMT
From: linus!mitre.org![e-mail]  (Tom Reale)
Subject: Gateway from Packet to the Internet
To: [e-mail]

I am searching for an SMTP gateway from my packet station to the Internet
so I can exchange personal email with friends who don't have the good
sense to join the amateur community.  I would appreciate any suggestions.




Tom Reale (WB1GSP)
[e-mail]

------------------------------

Date: Mon, 11 Jun 90 13:01:30 EDT
From: Alex Bodnar (STEAP-IMD 5545) <[e-mail]>
Subject: HD4040 assistance
To: [e-mail]

a big THANK-YOU to all who answered my plea for assistance.

the only kikker is that i am running CPM but i think i can still
get going.

alex bodnar
ka3cim

------------------------------

Date: 11 Jun 90 16:42:16 GMT
From: rochester!rit!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: KA9Q for Xenix available on Internet?
To: [e-mail]

In article <[e-mail]> [e-mail] (WA7LDV) writes:
>In article <[e-mail]> [e-mail] (Maxim Samo) writes:
>>Is there a KA9Q for Xenix available via ftp?
>>

I too would like to run nos on my 286 Box running SCO Xenix, If
anyone has done this port, any info would be greatly appreciated.
AS a matter of fact I would be willing to provide compensation for
anyone offering floppies with a running version.

Lot's of ideas and needs, but not much time?

I am running UUCP to my SUN at work and my mail node at Kodak. I
would like to be able to also run tcpip for other HAMS to use
my unix (like) Box via my DRSI board or my tiny 2. Thanks in advance.


--

email:   cb@cci632  or !rochester!kodak!n2hkd!curtis
Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450

------------------------------

Date: 11 Jun 90 16:13:40 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: KISS-mode on TNC-1270
To: [e-mail]

>KISS-mode seems like a nice mode to use if you want to create your own
>software for a TNC. For example using a PC as a host for a node or BBS.
>However, this requires the knowledge of KISS-mode, something we haven't
>got.
>So if anyone has documentation of what the TNC recognizes as commands
>, what you should feed it with and what kind of format the output comes in.
>(Seems like some characters get the doubled ASCII-value.)
>We at the Club at Lunds Institute of Technology ,Sweden would greatly
>appreciate a e-mail of some kind.

There is an appendix to the KA9Q NET User Manual that describes the KISS
protocol.  The user manual is available with the rest of the package on the
machine col.hp.com by ftp from the subdirectory ka9q/890421.1, or from TAPR
by mail on PC floppies, TAPR being at:

    TAPR
    PO Box 12925
    Tucson, AZ  85732
    [phone]

73 - Bdale, N3EUA

------------------------------

Date: 11 Jun 90 16:10:27 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: PE1CHL NET
To: [e-mail]

>Mike Curtis, WD6EHR is the US distributor for the ST version.
>Send him 2 DS or 3 SS ST disks and a note telling him what you want
>and he'll get back to you ASAP (1 week for me).

>The version I got is 900517

I just received 900522 from Rob, with a request to forward the disks on to
Mike Curtis when done.  If Mike or anyone near him is listening, I'm reading
the disks onto col.hp.com today, and will mail them off to CA tomorrow.

Bdale

------------------------------

Date: 11 Jun 90 18:44:11 GMT
From: MEMPHIS.wif.ctt.bellcore.com![e-mail]  (Mike)
Subject: Tncs
To: [e-mail]

Newsgroups: rec.ham-radio.packet

Gentlemen and Ladies:

Has anyone ever used the HK-21 pocket TNC from Heathkit? If so, do you
have any experiences you wish to share? What company manufactures a
solid TNC for a reasonable price?

Thank you very much.

Mike

[e-mail]
[e-mail]

------------------------------

Date: 11 Jun 90 18:44:16 GMT
From: MEMPHIS.wif.ctt.bellcore.com![e-mail]  (Peter Clitherow)
Subject: Tncs
To: [e-mail]

Newsgroups: rec.ham-radio.packet

Gentlemen and Ladies:

Has anyone ever used the HK-21 pocket TNC from Heathkit? If so, do you
have any experiences you wish to share? What company manufactures a
solid TNC for a reasonable price?

Thank you very much.

Mike

[e-mail]
[e-mail]

------------------------------

Date: 11 Jun 90 14:31:35 GMT
From: cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!rsiatl!nanovx!ke4zv![e-mail]  (Gary Coffman)
Subject: TNC Simulation
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>
>I recommend the plug-in card approach if you will always use your PC to
>run packet, and especially if you want to use or experiment with higher
>level protocols like TCP/IP. The "TNC" was designed for an erstwhile
>era, when everybody used dumb terminals. It makes much more sense to
>build packet stations around computers, not terminals.
>
I would point out that there are situations where the TNC approach is
still necessary. Laptop computers instantly come to mind as do Macintoshs.
Also Unix boxes such as this one. I am excited about the Kantronic Data
Engine as an semi-intelligent front end for my system. If you have a DOS
PC with slots, then the plugin cards are great. I'm running a DRSI on
a PC too, but it won't work with my laptop and I'm not up to writing a
device driver for Unix yet.
Gary KE4ZV

------------------------------

Date: 11 Jun 90 11:27:10 GMT
From: att!cbnewsj![e-mail]  (thomas.kenny)
Subject: What is ROSE?
To: [e-mail]

I'm relativily new to packet and know a little bit about TCP/IP and NetRom
and how to use them but I don't know what ROSE is. For some reason I thought
it was just another BBS but from some previous messages I've read here
it sounds more like NetRom. Is ROSE another NetRom type of widget? Any
info on it would be appreciated. TNX ES 73 DE KB2GLO.

--
Tom Kenny, KB2GLO
US mail: AT&T, 307 Middletown-Lincroft Rd, Lincroft NJ 07738
voice: 201-576-3888
uucp: att!lzatt!tek            internet: [e-mail]

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed, 13 Jun 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #54
To: packet-radio


Packet-Radio Digest         Wed, 13 Jun 90       Volume 90 : Issue  54

Today's Topics:
            10 Gigahertz repeater
             56 kb TNC revisited (3 msgs)
            concerns over TCP/IP (2 msgs)
              DVR-2 at 9600 Baud
          KA9Q - WHERE IS IT FOR THE MAC? (SUMMARY)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 12 Jun 90 15:31:48 GMT
From: mcgill-vision!clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!watserv1!sunee![e-mail]  (Peter Gray)
Subject: 10 Gigahertz repeater
To: [e-mail]

On the surplus market (at least around here) there are for sale these
10 gighertz military radar sets. These include a wealth of neat parts
including a 2-foot dish, all kind of wave guide, and a positioning system.

I have thought of a way of making a 10gig repeater with these dishes. The
repeater would consist of two of these units under control of a computer.
The computer would control the dishes and initially they would search the
area for signals. When a signal is found, the dish is stopped and adjusted
for max signal. Then the second dish is used to repeat the input. If a signal
is heard on the second dish, it is locked also.

The net effect of all this (aside from a neat display of radar dishes wizzing
around) is a 10gig repeater. All the users would mount their antennae to point
at the repeater, not at each other. To QSO with another user of the repeater,
they turn on their "rig" and within a few seconds one dish will lock onto
them (software will disallow both dishes from locking to the same signal).
Then the user can [use the autopatch] call CQ, effectily transmitting in all
directions from the repeater site, likely with more power than he could normally
muster. When a station responds, the second dish will lock onto it's signal
and the two can QSO via the repeater.

The final result would be full duplex and could be any mode. Unlike other
VHF and UHF repeaters, this would re-transmit on the same frequency as the
input. The only disadvantage to this system is that roundtables are not
simple (but they are not impossible either, just takes software). A closed
repeater of this type could lock out users by the direction of the signal.

Just some ideas for a group or an individual who has more money than I.

PG

------------------------------------------------------------------
Peter D. Gray -- Programer and KIA.
aka: VE3PGD, VE3PGD@VE3EUK, [e-mail], pgray@watcsc
via: [phone], 561 Fallingbrook Dr/Waterloo ON

------------------------------

Date: 12 Jun 90 18:18:57 GMT
From: bellcore-2!ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: 56 kb TNC revisited
To: [e-mail]

In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>  There are two popular parallel interfaces around today. One is IEEE-488
>and the other is SCSI.

It depends on your intended application. Neither of these interfaces is at
all common on PCs, although SCSI disk drives are just now starting to appear
in the PC environment (I have one).

There's another parallel interface that is far more widespread on PCs,
namely the Centronix printer interface. Even laptops without card slots
almost always have printer connectors. One company (Xircom) has already
exploited this fact by developing an Ethernet controller/transceiver that
plugs directly into the printer port. You do have to play some games, since
the data lines on a standard printer port are output-only; I suspect (but
don't know for sure) that Xircom uses the control lines for input. I don't
have any personal experience with this product, but those who have say it
works just fine; there's even a packet driver that allows its use with my
code or PC/TCP.

I think you should have no problem at all in handling data rates on the
order of 56kb/s with this interface. It might not sustain multi-megabit
throughputs, but then again most laptops can't handle those speeds either.

Phil

------------------------------

Date: 13 Jun 90 01:24:07 GMT
From: hayes![e-mail]
Subject: 56 kb TNC revisited
To: [e-mail]

In article <[e-mail]>, [e-mail] (Phil Karn) writes...
>In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>>  There are two popular parallel interfaces around today. One is IEEE-488
>>and the other is SCSI.
>
>It depends on your intended application. Neither of these interfaces is at
>all common on PCs, although SCSI disk drives are just now starting to appear
>in the PC environment (I have one).

I like the idea, if you can really come up with a SCSI implementation that
works with most SCSI-supporting products.  Third-party makers seem to have
had some troubles here in the past, though they are doing better now.
There is still some anxiety when plugging in a third-party SCSI product
that isn't well-known to work with your hardware that it will work most
of the time but crash the system at unpredictable times due to some subtle
timing effect.  As far as I know, though, SCSI is available on all modern
computing equipment, even not-so-modern boxes like the Atari ST.
>
>There's another parallel interface that is far more widespread on PCs,
>namely the Centronix printer interface. Even laptops without card slots
>almost always have printer connectors. One company (Xircom) has already
>exploited this fact by developing an Ethernet controller/transceiver that
>plugs directly into the printer port. You do have to play some games, since
>the data lines on a standard printer port are output-only; I suspect (but
>don't know for sure) that Xircom uses the control lines for input. I don't
>have any personal experience with this product, but those who have say it
>works just fine; there's even a packet driver that allows its use with my
>code or PC/TCP.
>
>...
>Phil

There's an article called "Convert PC's parallel port into bidirectional
instrumentation interface" in the June 1990 Personal Engineering &
Instrumentation News.  [They offer back issues for $5, 617-232-3625 if
you are really interested.]  Anyhow, in the introduction, it says:

  Recently, though, I encountered an application where I also needed to
  _input_ digital data _from_ the parallel port.  At first I thought the
  eight data lines should be the means for accomplishing the task, and
  while that method is possible, the data lines' limited current-handling
  capability and the inherent danger of blowing out the driver ICs suggest
  that a better method must exist.  Indeed, I realized that a better method
  does exist when I examined the commercial products that allow bidirectional
  exchanges between a laptop and a desktop computer....  The answer, in fact,
  is quite simple and deals with the use of the status lines to carry input
  information.

He goes into a fairly detailed description of how to do it, but I don't see
any claims about the data rate that can be achieved.  I'm not a PC fan so
I couldn't guess.  It would be nice to have a version of the interface that
did use the 8 data lines so that machines with true bidirectional printer
ports (like the Atari ST) could take advantage of it.  Running 56kbps
would be no sweat at all with a true bidirectional parallel interface.
Good luck...

Don Rice KL7JIQ                           Internet: [e-mail]
Geophysical Institute                     E-mail:   [e-mail]
University of Alaska                      Phone:    [phone]
Fairbanks, AK 99775                       Loran:    64.86N 212.16E

------------------------------

Date: 13 Jun 90 00:40:24 GMT
From: usc!srhqla!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: 56 kb TNC revisited
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil Karn) writes:
>In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>>  There are two popular parallel interfaces around today. One is IEEE-488
>>and the other is SCSI.
>
>It depends on your intended application. Neither of these interfaces is at
>all common on PCs, although SCSI disk drives are just now starting to appear
>in the PC environment (I have one).
>
>There's another parallel interface that is far more widespread on PCs,
>namely the Centronix printer interface. Even laptops without card slots
>almost always have printer connectors. One company (Xircom) has already
>exploited this fact by developing an Ethernet controller/transceiver that
>plugs directly into the printer port. You do have to play some games, since
>the data lines on a standard printer port are output-only; I suspect (but
>don't know for sure) that Xircom uses the control lines for input.

   Interesting you point this out, Phil. The PS/2 parallel port, normally
used for Centronix printer connection, has an explicit input mode also.
This is an extension over the original PC configuration of output only.
Certainly it is useful as a bidirectional I/F. I'll look at both.

  On the other hand, almost every new workstation class machine and every
new supermicro is coming with a SCSI connector on the box. A trend is
appearing, and I think this is chance to ride the horse rather than run
after it :-)

Dana
*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

Date: 12 Jun 90 16:56:50 GMT
From: rochester!rit!cci632![e-mail]  ( co-op)
Subject: concerns over TCP/IP
To: [e-mail]

In article <[e-mail]> [e-mail] (Jon Bloom) writes:
 [ stuff deleted ]
>Actually, the number one problem I've run into is, "You mean I have
>to leave the computer on ALL THE TIME??"

Hmm.  I am WAY out of touch when it comes to what's presently in NOS.
My head is totally spinning when it comes to which software does what,
and what version I should be using, etc.

It seems that my version has a "remote" command, where you could say
"remote kick n2jgw.ampr.org" and force my machine into trying to
smtp out whatever it had, but it doesn't seem to be selective (for
instance, be able to say 'wb2abc just kicked me, I'll just send stuff
to him, if I have any'.  This may already exist without my being aware
of it.

However, even with all of the nntp talk, etc. that's been going on,
I know that I personally don't feel satisfied with regard to what
form the old RLI-style BBS's will take in a TCP/IP world.  MSYS would
be a good place to start, if you could telnet into the BBS.

-- Chris, N2JGW

------------------------------

Date: 13 Jun 90 01:32:35 GMT
From: usc!samsung!rex!rouge![e-mail]  (Mahler Stephen J)
Subject: concerns over TCP/IP
To: [e-mail]

In article <[e-mail]> [e-mail] (Christopher Piggott - co-op) writes:
>In article <[e-mail]> [e-mail] (Jon Bloom) writes:
> [ stuff deleted ]
>>Actually, the number one problem I've run into is, "You mean I have
>>to leave the computer on ALL THE TIME??"
>
>It seems that my version has a "remote" command, where you could say
>"remote kick n2jgw.ampr.org" and force my machine into trying to
>smtp out whatever it had, but it doesn't seem to be selective (for
>instance, be able to say 'wb2abc just kicked me, I'll just send stuff
>to him, if I have any'.  This may already exist without my being aware
>of it.
>

I have a local change to the NOS software that allows you to TURN THE
MACHINE OFF, yet still get your mail.  The changes use the POP protocol,
and the concept is to move your e-mail box from a system that is up 24
hrs/day to your system on demand.  We have called that SLURPING the
mailbox.  During testing a SUNOS system was used as the base mail system.
We also have patched a POP server side together under NOS.  The project has
set idle for about 8 weeks now, if someone would like to take the pieces
and do the polishing, or use the work as a base to start over please
contact me.

I really feel that mail delivery on demand to your NOS system will be
a required feature before NOS is ready for the masses.

.... 73 ... Steve  KF5VH

------------------------------

Date: 13 Jun 90 07:53:12 GMT
From: maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]  (Steve Schallehn)
Subject: DVR-2 at 9600 Baud
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>Can anyone tell me what the exact deviation is on a DVR-2 running a G3RUH
>modem at 9600 baud?  My calculations come up to somewhere around +/- 8 Khz
>for a total bandwidth of around 16 Khz ....

I was very interested in the fact that a DVR2-2 and a G3URH modem could
be used together.  I was at the ARRL National Hamfest in Kansas City
this weekend and ask Karl Medcalf, WK5M about how much deviation that
configuration used.  He responded by saying "about legal limit".

Rather impressive to see 2 Date Engines with G3URH modems transfer a text
file across the room at 9600.  Makes my landline modem seem slow!

-Steve Schalleh, KB0AGD
 Kansas State Universiy ARC (W0QQQ)

--
_____________________________________________________________________________
Steve Schallehn           | Internet : [e-mail]
Kansas State University   | UUCP : ..!rutgers!ksuvax1!ksuvm.bitnet!steve
Manhattan, Kansas 66506   | Bitnet   : STEVE@KSUVM

------------------------------

Date: 12 Jun 90 14:51:01 GMT
From: snorkelwacker!bu.edu!rpi!image.soe.clarkson.edu!sunybcs!dsinc!netnews.upenn.edu!eniac.seas.upenn.edu![e-mail]  (James F. Kennedy)
Subject: KA9Q - WHERE IS IT FOR THE MAC? (SUMMARY)
To: [e-mail]

First of all, thanks to all who sent me responses on where the latest
version of the Mac KA9Q program was.  I downloaded and am now in the process
of playing around with it.

SECOND - By popular demand, those of you who don't know where to find this
version yet can anonymous ftp it from apple.com (or apple.apple.com).  You
will find it in the directory pub/ham-radio along with millions and millions
of other nifty stuff (slight exaggeration on the millions).  Anyways, all
(30+) response pointed me here....

                    James

--
James F. Kennedy                Internet: [e-mail]
University of Pennsylvania      HAMNET: 146.895- (Ohio) 146.685- (Philly)

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu, 14 Jun 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #55
To: packet-radio


Packet-Radio Digest         Thu, 14 Jun 90       Volume 90 : Issue  55

Today's Topics:
             56 kb TNC revisited (4 msgs)
         [[e-mail]: Field Day Question]
             concerns over TCP/IP
       concerns over TCP/IP (a non-expert's confusion)
         List of BBS's that are used by HAM'S
           Packet Connections in the Baltic States
               Thanks for 56kb input...

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 13 Jun 90 13:35:36 GMT
From: crdgw1![e-mail]  (Donald P Perley)
Subject: 56 kb TNC revisited
To: [e-mail]

In article <[e-mail]>, dana@lando (Dana H. Myers) writes:
>In article <[e-mail]> [e-mail] (Phil Karn) writes:
>>In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>>There's another parallel interface that is far more widespread on PCs,
>>namely the Centronix printer interface. Even laptops without card slots
>>almost always have printer connectors.

>  On the other hand, almost every new workstation class machine and every
>new supermicro is coming with a SCSI connector on the box. A trend is
>appearing, and I think this is chance to ride the horse rather than run
>after it :-)

I will just throw out a couple of pro/cons.

Hams being what they are, they would love to take this kind of stuff
mobile and portable.  The ablility to run off a laptop is a win here.
Score 1 for parallel ports.

On the other hand, most people who have a scsi board have at least one
address free for a tnc.  Most people who have a parallel port already
have a printer plugged into it.  Score one for scsi.

I don't suppose you could make this modular enough so someone could
hack the alternate I/O channel (assuming you don't want to do both yourself)?

-don perley ke2tp

[e-mail]

------------------------------

Date: 13 Jun 90 12:18:52 GMT
From: usc!samsung!umich!pmsmam![e-mail]  (Bill Meahan)
Subject: 56 kb TNC revisited
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil Karn) writes:
>In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>
[stuff deleted]

>There's another parallel interface that is far more widespread on PCs,
>namely the Centronix printer interface.
>
[stuff deleted]

>I think you should have no problem at all in handling data rates on the
>order of 56kb/s with this interface. It might not sustain multi-megabit
>throughputs, but then again most laptops can't handle those speeds either.
>
>Phil

Atari ST users of NET (few of us in the US but a lot in Europe) also could
benefit if this interface were used for the same reasons Phil states.  SCSI
interfaces for Atari ST's are more common since the disk controller port
('DMA Port') usually gets an SCSI hosta adaptor plugged on to it and SCSI
drives are then used.
--
Bill Meahan  WA8TZG             uunet!mailrus!umich!pmsmam!wwm
I don't speak for Ford - the PR department does that!

"stupid cat" is unnecessarily redundant

------------------------------

Date: 13 Jun 90 06:35:21 GMT
From: ogicse!emory!rsiatl![e-mail]  (John G. De Armond)
Subject: 56 kb TNC revisited
To: [e-mail]

[e-mail] (Dana H. Myers) writes:

>  On the other hand, almost every new workstation class machine and every
>new supermicro is coming with a SCSI connector on the box. A trend is
>appearing, and I think this is chance to ride the horse rather than run
>after it :-)

So are you going to build a board for the, oh, 7 or 8 workstations in
use by hams or are you going to build a genuinely useful hardware device
that might just catylize the adoption of high speed modems by average
hams?  If you plan to do the latter, then please listen to Phil (and others)
and use the parallel port.

The parallel port exists on practically all computers of interest to
hams.  It has more than adequate bandwidth (my covox speech thing that
connects to the parallel port is claimed to handle up to 14 ksamples/sec).
More importantly, it is EASY to program.  That means that Phil can
trivially incorporate a driver in NOS.  A packet driver will similiarly
be trivial.  As important, the easy driver requirement will mean that
the BBS code writes can add support quite simply.  And a unix driver
should not be too hard to do.

A SCSI port, on the other hand, while technically elegant, will guarantee
the board to become as obscure as the NNC.  Software will likely not
get written, especially software for all the different SCSI controllers
that is compatable with all the funky disk drives, tape drives, DATs, etc.

I could get really excited about what you propose to do if you do it
with a parallel interface.  I want to be able to run high speed
networking from my laptop (a natural, no?) which becomes possible
with your proposed device.

John

--
John De Armond, WD4OQC  | We can no more blame our loss of freedom on congress
Radiation Systems, Inc. | than we can prostitution on pimps.  Both simply
Atlanta, Ga             | provide broker services for their customers.
{emory,uunet}!rsiatl!jgd|  - Dr. W Williams |                **I am the NRA**

------------------------------

Date: 14 Jun 90 04:04:58 GMT
From: ogicse!emory!kd4nc!km4ba![e-mail]  (Alan Barrow)
Subject: 56 kb TNC revisited
To: [e-mail]

RE: scsi, I like the scsi idea.... and an st-02 scsi board is only
$50 or so. (Dumb and slow as it may be for disks) It does fit
my idea of pricing. It  also gets my vote for workstations and PC's,
as my 386 has scsi, and most new HP workstations are scsi.
I would love to trash gateway.km4ba. (dedicated ether<-> 56k gateway
pc)

RE: Centronics.... HP scanjets use some Bidirectional Centronics
I/F. I also saw the Personal ENg. article, and saved it. There was
also a rptr controller on 73 a year or so back, basedon the old
IBM convertable portable. He also used centronics for I/O
and buffered the lines. Most recent workstations have
Centronics also, but I really prefer the multi device capabilities
of scsi for this type of thing.

I can see scsi being handy for our LAN switch's... Multi 56k
scsi->hdlc drivers all on one scsi adapter. Forget about
all the serial interupt nonsense. Several 56k (or even some 1200)
modems on one I/F sounds attractive.

I hate to admit this publicly, (Everyone loves to bash Intel
micro controllers)but I even like the 8051 family of
processors, and think it would make a neat
board if you can get enough bandwidth out of it.
(I consider 8748's as poor man's ASIC's. $2 a chip
at hamfests, pub domain macro assemblers, and easy to
use. The 8031's are also cheap, and more powerfull.)

I have a forth for the 8031 I use on my robot that is real handy
and makes tight code, If you are interested. (I am sure all the
C types are groaning as they read this.) But they would be amazed to
know how many 874X, and 875X's are embedded in things they use every
day!

Well, build this thing, and I will use it anyway!
73, and happy coding. (and watch your page boundries on the '51)

Alan Barrow km4ba
..!gatech!kd4nc!km4ba!alan
[e-mail]

------------------------------

Date: Wed, 13 Jun 90 11:21:07 -0700
From: Doug Faunt N6TQS 415-688-8269 <[e-mail]>
Subject: [[e-mail]: Field Day Question]
To: [e-mail]

The straight information, from the ARRL, by email.


>From [e-mail]  Wed Jun 13 11:14:30 1990
Date: Wed, 13 Jun 90 13:12 EST
From: American Radio Relay League <[e-mail]>
To: Doug Faunt N6TQS <[e-mail]>
Subject: Field Day Question

To:  Doug Faunt, N6TQS
From:  Warren C. Stankiewicz, NF1J
Assistant Contest Manager, ARRL

Our definition of a packet QSO for Field Day
is a station to station contact.  Digipeated
QSOs are acceptable.

73, Warren

------------------------------

Date: 13 Jun 90 06:14:57 GMT
From: psuvm!ricevm1.bitnet![e-mail]  (Jordan Kossack)
Subject: concerns over TCP/IP
To: [e-mail]

Recently, [e-mail] ( co-op) said:
- The static inertia of society is tremendous, and it is no better in
- many parts of the ham-radio community.  Here are a few other pieces
- of resistance I have personally encountered:

- Equipment.  "Will my C-64 work?"  "Is there a CP/M version for my
-     shoe-box that I bought for $20.00 at a hamfest?"  etc.
-     I'm not sure if these people feel "threatened" that their
-     "stuff" will be forced into an early grave, but there
-     needs to be an effort to educate people that this stuff
-     already *IS* outdated.


==>  I don't know a whole lot about packet so I've been reading
this newsgroup to try and get a feel for it. This attitude really
burns me - sure, a C-64 may not be ideal for packet radio but not
all hams are rich. I'm sorry, but I can't afford to go out and buy
a MicroVAX on a student's budget. Also, why should someone have to
spend a boatloads of money on equip. for packet if they're not real
sure whether it's a mode that they'll enjoy? I don't hear folk on HF
complaining that all hams should buy a digitally synthesized tuner
so it won't annoy them when your old Drake is 14 Hz off of their
rice box's frequency. Gee, Wally.

Then, in a follow-up, [e-mail] (Phil Karn) says:
- >many parts of the ham-radio community.  Here are a few other pieces
- >of resistance I have personally encountered:

- [long list of unbelievably brain-damaged excuses deleted for brevity...]

- Now you see one of the reasons I'm so strongly in favor of a no-code license
- that would attract more technically oriented people to the service.
  . . .
- project), but I harbor no illusions about ever garnering more than a small
- fraction of the existing amateur population. That's why it's important to go
- outside the existing pool for new blood.


==>  I don't believe this!  Mr. Karn calls the newcomers `brain dead'
because either 1) they want to homebrew because they can't afford new
equipment [ or 'cause they enjoy it ]  OR  2) they're new to packet
radio and don't know all the ropes.  THEN, he goes on to complain of
the lack of interest from the ham community. ACK!  If y'all treat the
new Communicator Class licensees like this, the influx of `new blood'
is not going to help. They'll just get HTs and mobile VHF/UHF rigs &
talk with their buddies on the local repeater. Now, I'm not going to
claim that the folk working packet MUST help the new guys, but without
good elmers it is difficult to attract any but the most dedicated
potential packeteer ... or attract new hams in general.

     Now don't get me wrong - I think innovation is intrinsically a
good thing, but don't leave the rest of us in the dust. Mark the path
so we can follow you, step by step, as our finances and our free time
allow. That is, if you really want more folk who are packet literate.

                            - Jordan
                            n5qvi  (ex- ka2pfa)
-------
Jordan Kossack  |  N5QVI   |               Student Staff
----------------+----------+  Office of Networking and Computing Systems
[e-mail]  |        Rice University  Houston Texas

------------------------------

Date: 13 Jun 90 13:41:20 GMT
From: philmtl!philabs!briar![e-mail]  (Robert Casey)
Subject: concerns over TCP/IP (a non-expert's confusion)
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil Karn) writes:
>In article <[e-mail]> [e-mail] (Christopher Piggott - co-op) writes:
>>The static inertia of society is tremendous, and it is no better in
>>many parts of the ham-radio community.
>
>Now you see one of the reasons I'm so strongly in favor of a no-code license
>that would attract more technically oriented people to the service.
>
>I certainly welcome the participation of any and all existing hams in TCP/IP

Could someone point out some references on TCP/IP suitable for the
non-computer-expert packet user?  I've been using packet radio for about 2
years now.  I mostly get on my local BBS, sometimes crossposting articles from
packet to UUCP, and vs versa.  Is TCP/IP meaningful to me?  How does it differ
from what I'm used to (ROSE and regular TNCs)?  (any of this making sense? :-)
I think it has something to do with the way e-mail and postings are sent
around the packet BBS network.  (I'm using an old Atari 800 8bit computer with
a KPC2 tnc and a crystal controlled 2m radio, if it matters.  Do you need
"KISS" for TCP/IP?)   signed: Confused.

Maybe some expert should write an "Idiot's guide to TCP/IP"?
=======================================================================
73 de WA2ISE

------------------------------

Date: 12 Jun 90 19:52:27 GMT
From: bu.edu!orc!inews!iwarp.intel.com!psueea!parsely!twiki![e-mail]  (Dale A. Weber)
Subject: List of BBS's that are used by HAM'S
To: [e-mail]

[e-mail] (michael) writes:

> I'm looking for a list of computer BBS's where I can get in touch with HAM
> radio operators. I'm interested in geting involved with HAMing and would like
> to find a users group that would help me get started. Thanks in advance!

  We have Ham Radio Micro Bits here in Portland, OR. It is dedicated
totally to all phases of Amateur Radio. The number is [phone] and is
online 24 hours. I'm also very interested in Ham Radio, especially packet,
and carry the rec.ham-radio.* news groups here. See below for the info on
my system. ;-) ;-)

---
INTERNET: [e-mail] OR [e-mail] (Dale A. Weber)
UUCP: ..!uunet!twiki!dalew OR ..!{sun!nosun, tektronix}!tessi!twiki!dalew
 BBS: [phone], 24 Hours, 1200/2400 Bps MNP 1-5, PCPable via ORPOR

------------------------------

Date: Wed, 13 Jun 90 13:10:32 EDT
From: Mike <[e-mail]>
Subject: Packet Connections in the Baltic States
To: Packet-Radio List <[e-mail]>

We are searching for packet radio operators in the Baltic states.
If anyone knows of any packet radios out there, please let me know.
If anyone knows of anyone closer to the Baltic states, who might know,
please let me know!

Thank you.

73

MM438

[e-mail]

------------------------------

Date: 14 Jun 90 06:49:59 GMT
From: usc!srhqla!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Thanks for 56kb input...
To: [e-mail]

  I've received several useful pieces of input from the group; thanks.

 To summarize, as most have already seen, the response is generally
favorable. There are some questions about the SCSi interface actually
working; these are very good questions. I've been using the Adaptec Nodem
as an example of a SCSI communications device that works, and I will
investigate it in greater detail a little later.

   I'm going to be away from my keyboard until the 26th. If you have
more ideas/input for me, please send it to '[e-mail]', so I
don't miss it on the group (our site only keeps things for a few days).

  One thing looks pretty likely - I may end up using a purpose built
SCSI interface chip for that part of the design, though a low cost
parallel port (like the bidirectional Centronix discussed) version
may pop out on the way to a SCSI device. Those of you with PS/2s would
be the easiest for this.

  Anyway - thanks again. See ya in 12 days.

Dana


*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri, 15 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #56
To: packet-radio


Packet-Radio Digest         Fri, 15 Jun 90       Volume 90 : Issue  56

Today's Topics:
          9th Computer Networking Conference (ARRL)
            concerns over TCP/IP (3 msgs)
       concerns over TCP/IP (a non-expert's confusion)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 14 Jun 90 20:17:30 GMT
From: swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun![e-mail]  (Jon Bloom)
Subject: 9th Computer Networking Conference (ARRL)
To: [e-mail]

           9th Computer Networking Conference

         The American Radio Relay League
         The Canadian Radio Relay League

Plan to participate in the 9th Computer Networking Conference,
jointly sponsored by ARRL and CRRL, to be held this September in
Canada--the country that first brought you packet radio!  Here
are the details:

TIME AND DATE: 9 AM to 5 PM, Saturday, 1990 September 22

LOCATION:      London Regional Art Gallery and Museum, 421 Ridout
           Street North, London, Ontario

REGISTRATION:  $US 20 or $CDN 25.  Registration fee includes a
           copy of the conference proceedings and a catered
           hot lunch.

A WORD ABOUT THE LOCATION:  London, Ontario, population 270,000
is located in Southern Ontario midway between Detroit, Michigan,
and Buffalo, New York (or Toronto, Ontario).  London is
accessible by car via Highway 401, rail or air.  While no major
airlines have direct service to London, excellent commuter
service to Toronto and Detroit is provided by Air Ontario (Air
Canada) and Canadian Partner (Canadian Airlines International).
ComAir (Delta) provides connector service from Cincinnati and
Cleveland, Ohio.  For those in the US that might want to take in
a bit of countryside, flying to Detroit or Buffalo, or to Niagara
Falls, New York, and renting a car for the 2-3 hour trip to
London can be a cost-effective alternative to flying directly.
Check with your travel agent for details.  The London Regional
Art Gallery and Museum is located in downtown London, overlooking
Harris Park at the forks of the Thames River.  There is adequate
free parking nearby.

A WORD ABOUT ACCOMMODATIONS:  Conference organizers have
negotiated a special flat rate of $CDN 85 a night (no limit to
the number of people allowed to stay in one room) at the 322-room
Radisson Hotel, London Centre, located about four blocks from the
conference site.  it is highly recommended that conference
participants stay at this hotel to facilitate organizing Friday-
night dinners and informal get-togethers.  (A list of alternate
accommodations can be furnished on request.)  Conference
participants must make their own reservations at the Radisson.
Use the toll-free number [phone] and mention the
conference.

A WORD ABOUT THE CONFERENCE:  Past computer networking
conferences have attracted 120-150 participants from all over the
US and Canada--and occasionally from beyond.  Conference speakers
share the results of recent work at the leading edge of packet
radio.  All participants hear all speakers--there are no
concurrent presentations.  Is this a place to find out how to get
into packet radio?  We would say no.  But if you're a beginner
and you do attend, you're certain to develop an enthusiasm for
this wonderful mode.  Is there anything to look at or buy?  Not
really--it's a conference, not a hamfest.  Of course, that
doesn't preclude a few interesting displays or demonstrations--or
the deal of a lifetime made in the parking lot!  What about
Saturday activities after the conference?  Conference organizers
will make arrangements so that everyone who wishes can have
dinner together and a night out at a popular restaurant--a good
way to end the conference.

HOW TO REGISTER:  Send $US 20 or $CDN 25 to:
     9th Computer Networking Conference
     c/o Harry MacLean, VE3GRO
     500 Riverside Drive
     London, ON  N6H 2R7
Include your name, address and call (if any).  You will receive a
confirmation in the mail, along with maps and additional
information related to the conference.

--
Jon Bloom, KE3Z                              | American Radio Relay League
Internet: [e-mail]         |
Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."

------------------------------

Date: 14 Jun 90 06:23:30 GMT
From: bellcore-2!ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: concerns over TCP/IP
To: [e-mail]

In article <1704KOSSACKB@RICEVM1> [e-mail] (Jordan Kossack) writes:
>==>  I don't know a whole lot about packet so I've been reading
>this newsgroup to try and get a feel for it. This attitude really
>burns me - sure, a C-64 may not be ideal for packet radio but not
>all hams are rich. I'm sorry, but I can't afford to go out and buy
>a MicroVAX on a student's budget.

Don't bother with Microvaxes, they're obsolete too.  All you need to run
TCP/IP is a cheap, lowly PC.  You don't even need a hard disk. I've seen
brand new PC/XT clone boards going at the computer shows for $60 or less.

The point is that the price/performance ratio of personal computer hardware
has improved dramatically over the past two decades, and this trend shows no
sign whatsoever of slowing down. This has made it possible for the average
amateur to have capabilities that were mere fantasies a decade ago, but the
unavoidable flip side is that personal computer hardware becomes obsolete
very quickly. It's a fact of modern computer life.

I had to accept this years ago. When I was in college in the mid 1970s I
hand-built an S-100 system. Its cost as a function of my available funds
then was far higher than the fraction of my current income that I now spend
on PC hardware.  Years ago I tearfully tore that old S-100 machine apart --
it had become competely obsolete and worthless, and I had another use for
the rack cabinet.  Yet it was still one of the best investments I've ever
made, because of the early practical experience it gave me with small
computer systems. I give that experience at least partial credit in landing
my first job with Bell Labs.

>Then, in a follow-up, [e-mail] (Phil Karn) says:
>==>  I don't believe this!  Mr. Karn calls the newcomers `brain dead'
>because either 1) they want to homebrew because they can't afford new
>equipment [ or 'cause they enjoy it ]  OR  2) they're new to packet
>radio and don't know all the ropes.  THEN, he goes on to complain of
>the lack of interest from the ham community.

If you look at the list of "brain damaged complaints" I was referring to,
they fell roughly into three categories. The first (and least defensible)
were packet users objecting to the use of TCP/IP by others. How can you
possibly defend the guys who complain about "funny characters" on their
printers when the packets aren't even addressed to them! The second group
complained that I hadn't supported (for free, of course) their particular
type of hardware. Since when did I commit to doing this? (At least I make my
full source code available so they can try the job themselves; I don't know
of ANY other amateur software project of similar scale that has done this.)
And the third group is, of course, simply opposed to any change at all.

> ACK!  If y'all treat the
>new Communicator Class licensees like this, the influx of `new blood'
>is not going to help. They'll just get HTs and mobile VHF/UHF rigs &
>talk with their buddies on the local repeater. Now, I'm not going to
>claim that the folk working packet MUST help the new guys, but without
>good elmers it is difficult to attract any but the most dedicated
>potential packeteer ... or attract new hams in general.

There will certainly be many Communicators who do nothing but chat on FM,
but I hope the new license will also attract many people who are already in
the computer field, or at least have a greater interest in doing new things
with computer communications than I've seen expressed by the existing
amateur community at large. I have no objection to non-computer-oriented
hams doing their thing as long as they let me do mine.

>     Now don't get me wrong - I think innovation is intrinsically a
>good thing, but don't leave the rest of us in the dust. Mark the path
>so we can follow you, step by step, as our finances and our free time
>allow. That is, if you really want more folk who are packet literate.

No problem. You can lead, follow, or get out of the way; it's your choice.
Just don't try to block my path!

Phil

------------------------------

Date: 14 Jun 90 15:00:25 GMT
From: wang!tegra![e-mail]  (Johnathan Vail)
Subject: concerns over TCP/IP
To: [e-mail]

In article <[e-mail]> [e-mail] (Antonio Querubin) writes:

   I have a problem which some of you may have already run into and
   I hope can offer some advice on.  Some friends and I were planning
   on running TCP/IP on the local packet network.  When various people
   got wind of this, particularly the folks who have turned all the
   major local digipeaters into ROSE nodes (it's their equipment), I
   started hearing 'concerns' about TCP/IP's effect on the packet
   channels.

   Most of the concerns seem to center around increased congestion on
   the packet channel we chose to run on.  I've monitored that
   frequency (145.01) and detect very little activity on it and

    .
    .
    .

The concerns can be valid and work in both directions.  Your average
typewriter-CB packet user doesn't necessarily require great
performance from the network nor put a great strain on it.  When you
get a TCP/IP station transfering a couple hundred K file on the same
channel then throughput of the other users of the channel can be
affected.

At the same time I am told that there are performance problems on
mixed netwroks for the TCP users.  When collisions do occur the TNC
will retransmit whenever it thinks it can get in while the TCP station
will back off, politely stepping aside.  This means the X-25 TNC gets
to use the channel more often than the TCP station.

Another problem is the mode of operation.  PAUs typically will switch
the 2m rig off the local repeater and over to the TNC when they want
to use it, running a hundred or so watts into the omni antenna.  To
get proper benefit a TCP station is usually dedicated to the purpose
and running proper power into a beam into the repeater or switch site.

I think the proper way to run things is to establish full duplex
repeaters, probably on 440 or above, greater than 1200 baud and use
beams to "work" the repeater.  Using a repeater eliminates hidden
transmitter problems and since you are working point-to-point the use
of beams and reduce the QRM to same channel repeaters allowing more
re-use of the frequency pair.

Some things, like long distance backbones can be shared between
the protocols.  In New England some long distance links use NETROM
nodes to connect them.

In summary, the things that you use TCP for, like transfering files,
can increase traffic per user over a typical PAU.  The algorithms used
to send a packet can cause TCP stations to lose on shared channels.  I
reccomend finding a separate channel for local TCP use and sharing
long distance nodes.

These are just my opinions and thoughts.  Hope they help.

73s, jv

"Imagine what it would be like if TV actually were good. It would be the end
 of everything we know."  -- Marvin Minsky
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

------------------------------

Date: 14 Jun 90 10:35:55 GMT
From: cs.utexas.edu!texbell!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: concerns over TCP/IP
To: [e-mail]

In article <1704KOSSACKB@RICEVM1> [e-mail] (Jordan Kossack)
writes, in response to Phil Karn's comment about how he wants a no-code
license to get technically oriented people into ham radio, since we
obviously don't have them now:
>[...] If y'all treat the
>new Communicator Class licensees like this, the influx of `new blood'
>is not going to help. They'll just get HTs and mobile VHF/UHF rigs &
>talk with their buddies on the local repeater. Now, I'm not going to
>claim that the folk working packet MUST help the new guys, but without
>good elmers it is difficult to attract any but the most dedicated
>potential packeteer ... or attract new hams in general.

Now, Jordan...don't you know that the new Communicator Class licensees
will uniformly be the most dedicated, technically competent wizards in
existence? Just ask Phil Karn! They don't NEED Elmers. They have
SPARCstations, and MicroVaxes, and other advanced computing systems, and
are interested in heavy-duty technical innovation, not just wasting time
on FM voice - why, I bet they'll never even buy a microphone to go with
the radios they'll use while they're developing T-1 links to run on
microwave bands. Of course, they won't even want to talk to us lowly
non-techies who had to earn our licenses.

(The above was heavy sarcasm, for those who couldn't figure it out.)

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
[e-mail]       (eieio)| adequately be explained by stupidity.
"I don't usually do vicious;        +----------------------------------------
 I try to stick to depressing." -- Janis Ian, in concert, 6/6/90

------------------------------

Date: 14 Jun 90 13:13:14 GMT
From: casux4![e-mail]  (jonathan nagy)
Subject: concerns over TCP/IP (a non-expert's confusion)
To: [e-mail]

In article <[e-mail]> [e-mail] (Robert Casey) writes:
>
>Maybe some expert should write an "Idiot's guide to TCP/IP"?
>=======================================================================
>73 de WA2ISE

Someone did!
It's called "Beginner's Guide to TCP/IP on the Amatuer Packet
Radio Network Using the KA9Q  Internet Software"
written by Gary Ford, N6GF.

I belive I got my copy by ftp from flash.bellcore.com. Look in
/pub/ka9q.  Otherwise, you can contact the author:

AX.25 PBBS:  N6GF@WA6NWE.#NOCAL.CA
Internet:    [e-mail]
U.S. Mail:   226 Diablo Ave, Davis, CA 95616

73, Jon NK2D


Jonathan Nagy
[e-mail]
[phone]

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat, 16 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #57
To: packet-radio


Packet-Radio Digest         Sat, 16 Jun 90       Volume 90 : Issue  57

Today's Topics:
            concerns over TCP/IP (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 14 Jun 90 14:35:36 GMT
From: usc!elroy.jpl.nasa.gov!peregrine!ccicpg!cci632![e-mail]  ( co-op)
Subject: concerns over TCP/IP
To: [e-mail]

>     Now don't get me wrong - I think innovation is intrinsically a
>good thing, but don't leave the rest of us in the dust. Mark the path
>so we can follow you, step by step, as our finances and our free time
>allow. That is, if you really want more folk who are packet literate.

Hmm.  The FCC said recently that developement of HDVT should continue,
but any standards that are developed must still include owners of the
old style TV's.  This is much the same as when color came out, and it
was assumed that color broadcasts could still be received on B&W sets
of ten years before.

The HDTV thing made me mad as ... er, heck.

I don't see this sort of thing as being much different, in that
I don't like being told what to do, and I don't like it when
people try to make me feel guilty because they can't use my
software on their C64's.

>Jordan Kossack  |  N5QVI   |               Student Staff

By the way...I'm on a student's budget, too.  And a student's
schedule.  (Fun, isn't it?)  :-)

-Chris

------------------------------

Date: 15 Jun 90 19:35:37 GMT
From: sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!sayshell.umd.edu![e-mail]  (Louis A. Mamakos)
Subject: concerns over TCP/IP
To: [e-mail]

I fail to see the reason why the C64 folks are complaining about how
they can't run NET/NOS or a generic TCP/IP on their machines.  Phil
Karn writes this software, and GIVES IT TO WHOEVER WANTS IT FOR FREE.
What's to complain about?

I don't have an IBM Pee-Cee thing, and won't allow any brain-dead
Intel architecture CPU under my roof. [CPU religion wars to be fought
elsewhere].  I've got a Commodore-Amiga 68000 based system.  I didn't
bitch because Phil's code didn't run on my machine, I did my own port
of his code.  Phil even took some of my changes back to the "generic"
part of the code.  What more do you want?  Him to drop by your shack
and do the port FOR you?  For free?

If you feel strongly about using your C64 or whatever, do something
about it, don't complain.  Just because Phil chooses not to write code
for a C64 and I choose not to write code for an 80x86, doesn't mean
that you can't.

Louie WA3YMH

------------------------------

End of Packet-Radio Digest
******************************
Date: Sun, 17 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #58
To: packet-radio


Packet-Radio Digest         Sun, 17 Jun 90       Volume 90 : Issue  58

Today's Topics:
          KA9Q - WHERE IS IT FOR THE MAC? (SUMMARY)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 16 Jun 90 01:51:00 GMT
From: hpda!hpcupt1![e-mail]  (Ray Terry)
Subject: KA9Q - WHERE IS IT FOR THE MAC? (SUMMARY)
To: [e-mail]

>SECOND - By popular demand, those of you who don't know where to find this
>version yet can anonymous ftp it from apple.com (or apple.apple.com).  You
>will find it in the directory pub/ham-radio along with millions and millions
>of other nifty stuff (slight exaggeration on the millions).  Anyways, all
>(30+) response pointed me here....

For those w/o access to an open subnet machine (to do the ftp), the Mac
KA9Q (version 2.0), latest BM mailer (900415), and docs are also available
via landline on MacScience BBS (408-866-4933).

Ray

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ray Terry      GEnie = R.Terry      CIS = 71150,735      HPDesk = /HP4700
Domain = [e-mail]    SysOp = MacScience BBS 408-866-4933
Packet = N6PHJ @ N6IIU.#NOCAL.CA.USA  UUCP = sun!hpda!hpcupt1!rterry
UFGate = vsi1!camphq!36![e-mail]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon, 18 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #59
To: packet-radio


Packet-Radio Digest         Mon, 18 Jun 90       Volume 90 : Issue  59

Today's Topics:
          KA9Q NOS 900612 problems (& G1EMM)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 17 Jun 90 02:12:22 GMT
From: cs.utexas.edu!asuvax!mcdphx!phx.mcd.mot.com![e-mail]  (Dave Fritsche )
Subject: KA9Q NOS 900612 problems (& G1EMM)
To: [e-mail]

I'm having problems with the KA9Q version of NOS.  The version I am now
trying to use is 900612 and is not a modified copy.  I have run other versions
of NOS in the past, and have been running G1EMM's version (900522v1.1) up
until now with no problem.  Here's what I've tried doing & what's happened:

  - start up NOS
  - at the prompt, type "con tnc phx" ("phx" is the local netrom node)
  * connect is successful
  - then type "n *" (get a complete nodes list, multiple packets long)
  * received the nodelist just fine
  - then type "users"
  * NOS never tries to transmit after this.  The "STA" led never comes on.
  - turn trace on:  "tra tnc 1111"
  * NOS reports that it's sending the TNC packets, still no LED
  - do an "asy stat":
     tnc: [trig char 0xc0]
      RX: int 1157 chr 1157 ovrn 0 hiwat 1
      TX: int 97 chr 97 sndq 14 CTS int 0

My system configuration:
    8Mhz XT, 640k
    COM2 serial port
    MFJ-1270 tnc
    Note: the RS232 cable is 3-wire with jumpers: 4 to 5, and 6 to 8 to 20
      at each end.
      (I'm curious about the "CTS" in the asy stat!?!  What is that?)

Here is some key info from my autoexec.net file:
    attach asy 0x2f8 3 ax25 tnc 2048 128 1200
    param tnc 1 40
    param tnc 2 25
    param tnc 3 20
    tcp mss 88
    tcp window 88
    ax25 maxframe 1
    ax25 paclen 128
    ax25 window 128
    mode tnc datagram
    netrom qlimit 1024
    netrom window 1
    mode netrom datagram
    ifconfig netrom mtu 108

All "irtt's" are set to 32000.  Can anyone shed some light?  I reported a
similar problem a few weeks ago, and Phil mentioned that he had removed
the "UART transmitter tickle", and that may have been the problem.  I am
assuming the "tickle" was put back in on this version, but maybe it slipped
thru the cracks.

The whole reason I was going back and trying the KA9Q "original", was because
with G1EMM, nobody can seem to connect to the MBOX via netrom or AX.25.
They get connected ok, but the MBOX prompt never comes thru.  With trace
turned on, I can see that my system is sending the MBOX stuff out, but it
isn't making it thru the netrom node back to the user.  Have I screwed up
some parameters?  Has anyone else seen this behavior?  I can repeat the
problem by connecting to the local netrom node, then connecting back to
myself.  Since I haven't seen anything about it in the "tcp-group" maillist,
or here, I figure I have something configured wrong.

Any help would be greatly appreciated.

Dave Fritsche (wb8zxu)
[e-mail]

------------------------------

End of Packet-Radio Digest
******************************
Date: Tue, 19 Jun 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #60
To: packet-radio


Packet-Radio Digest         Tue, 19 Jun 90       Volume 90 : Issue  60

Today's Topics:
             56 kb TNC revisited (2 msgs)
             900612 & async stall

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 18 Jun 90 15:59:53 GMT
From: cellar![e-mail]  (Martin Harriss (ACP - contractor))
Subject: 56 kb TNC revisited
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil Karn) writes:
>There's another parallel interface that is far more widespread on PCs,
>namely the Centronix printer interface. Even laptops without card slots
>almost always have printer connectors. One company (Xircom) has already
>exploited this fact by developing an Ethernet controller/transceiver that
>plugs directly into the printer port. You do have to play some games, since
>the data lines on a standard printer port are output-only; I suspect (but
>don't know for sure) that Xircom uses the control lines for input.

Actually, most if not all parallel ports these days allow 8-bit parallel
input as well.  My laptop (a Toshiba T1000) does, and I seem to remember
hearing that bi-directional ports are now the norm.

I've succesfully used the parallel port for various interface functions,
although it can be a bit slow at times.

Martin kb2jyz
[e-mail]

------------------------------

Date: 18 Jun 90 21:12:22 GMT
From: van-bc!ubc-cs!alberta!atha![e-mail]  (Ross Alexander)
Subject: 56 kb TNC revisited
To: [e-mail]

I was quoted $35.00 Canadian for a SCSI disk controller board for a
PC.  Surely most of us can afford that sort of small change price?
I think that would be good enough for the purpose.

And furthermore { :-) } bidirectional parallel I/O is pretty cheap;
what's the price of an 8255, $2.00 ??  Plus a prototyping card, of
course.  Another 10 bucks.  Yawn.



--
--
Ross Alexander    [e-mail]    [phone]    ve6pdq

------------------------------

Date: Mon, 18 Jun 90 13:21:12 GMT
From: [e-mail]
Subject: 900612 & async stall
To: [e-mail]

Phil Karn did indeed take out the transmitter tickle in 900612. I promptly
put it back in again! You should find that the g1emm version of 900612
works correctly with the async driver.
As for the mbox funnies over netrom & ax25... I think this may be to do with
a mis-match of ax25 frame sizes and the like. We had a similar problem in
the UK recently and it was found to be due to a mis-configured paclen and
attach command. Please give it a whirl using larger paclen and mtu sizes.
If all else fails, try and determine the point of failure. One difference
in my version and Phils is that I have slightly different mbox prompt sizes
and this may explain the problem. I also don't put a c/r + l/f on the end
of the subject prompt during mail sends. This should not cause a problem
but I think MSYS tries to use the prompt for automated forwarding, instead
of using the MBL type of BBS->BBS forwarding sequence....(Yuck!)
  Hope this helps a bit....
     All the best,
           Kelvin.

+----------------------------------------+------------------------------------+
| |  /    |               |  |    |  |   |Kelvin J.Hill - BULL HN Ltd Hounslow|
| |_/  __ |      O        |__| O  |  |   |Internet - 128.35.110.6             |
| | \ |__|| \  / |  |\ |  |  | |  |  |   |Amprnet - g1emm.ampr.org 44.131.7.6 |
| |  \|__.|_.\/  |_.| \|  |  | |_.|_.|_. |Compulink - [e-mail]         |
+----------------------------------------+------------------------------------+

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed, 20 Jun 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #61
To: packet-radio


Packet-Radio Digest         Wed, 20 Jun 90       Volume 90 : Issue  61

Today's Topics:
             56 kb TNC revisited
             KA9Q for the Amiga (2 msgs)
        Nation(World) Wide TCP/IP 56k/2mbit Community
            Network Models (long) (2 msgs)
                  NOS & SLIP
     Re: concerns over TCP/IP (a non-expert's confusion)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 19 Jun 90 15:03:58 GMT
From: wang!tegra![e-mail]  (Johnathan Vail)
Subject: 56 kb TNC revisited
To: [e-mail]

In article <[e-mail]> [e-mail] (John G. De Armond) writes:

   >  On the other hand, almost every new workstation class machine and every
   >new supermicro is coming with a SCSI connector on the box. A trend is
   >appearing, and I think this is chance to ride the horse rather than run
   >after it :-)

   So are you going to build a board for the, oh, 7 or 8 workstations in
   use by hams or are you going to build a genuinely useful hardware device
   that might just catylize the adoption of high speed modems by average
   hams?  If you plan to do the latter, then please listen to Phil (and others)
   and use the parallel port.

I like the SCSI idea.  Sign me up for several!  I can use it on my Sun
3/60 and since we are using SCSI here I may have a line on surplus
equipment to use.  The paralell port may have some value as far as PCs
are concerened but really loses in high speed applications because of
the lack of DMA.  If you have to babysit an 8 bit port you may as well
just run an 8530 or some serial port directly.

   The parallel port exists on practically all computers of interest to
   hams.  It has more than adequate bandwidth (my covox speech thing that
   connects to the parallel port is claimed to handle up to 14 ksamples/sec).
   More importantly, it is EASY to program.  That means that Phil can
   trivially incorporate a driver in NOS.  A packet driver will similiarly
   be trivial.  As important, the easy driver requirement will mean that

The driver is the easy part. I think its more a matter of performance.
With the paralell port the CPU has to stuff the bytes and twiddle the
handshakes the entire time.  With a DMA and SCSI you just set and
forget it.  Set up the DMA, the SCSI, and away the data packet goes.

...jv

The inability of snakes to count is actually a refusal, on their part,
    to appreciate the Cardinal Number system. -- "Actual Facts"
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

------------------------------

Date: 18 Jun 90 22:12:07 GMT
From: snorkelwacker!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!jhunix![e-mail]  (Thomas G Edwards)
Subject: KA9Q for the Amiga
To: [e-mail]

Where is KA9Q available for the Amiga? (via ftp prefered)

-Tom

------------------------------

Date: 20 Jun 90 02:23:42 GMT
From: haven!sayshell.umd.edu![e-mail]  (Louis A. Mamakos)
Subject: KA9Q for the Amiga
To: [e-mail]

A version of the KA9Q NOS code for the Amiga can be had via anonymous FTP
from Sayshell.UMD.EDU in the /pub directory.  I haven't had time to do a
port of the latest NOS code, but hope to get around to it some time.

louie WA3YMH

------------------------------

Date: 19 Jun 90 23:32:06 GMT
From: usc!ucselx!crash![e-mail]  (Jim Burnes)
Subject: Nation(World) Wide TCP/IP 56k/2mbit Community
To: [e-mail]

HI!

I was wondering if anyone was interested in a semi-formal international
digital network of people who use 56kb local packet at 220mhz and above
and use 10ghz surplus microwave systems to hop between cities.  The local
clubs could buy the 10ghz stuff and put it at someones house to act as
intercity gateways.  This could all happen with tcp/ip, the grapes modem
and surplus 10ghz stuff.  Maybe this has happened already.  When is the
new digital class going to be ok'd?  What will you have to do?  Just the
test, but no code?

  Considering I'm not a ham yet (cause of the damn code requirement),
this probably sounds a bit premature.  I just would like to get this set
up.  An worldwide communications network sounds so slick I wonder why its
not illegal.  (And you dont have to pay AT&T or telenet...shhh...dont tell
anybody!...as long as its non profit). I have some names for the network..
here are some humble suggestions...

    village:  for global village
    mag/net:  for electromagnetic network (think of all the puns)

I really think something like this would attract a lot of new technically
oriented blood. (me for sure!)  We could have free fidonet done right and
maybe some good hearted person will makea a gateway to usenet/internet
(and then watch the whole community move to packet 'en-masse')

I'm really pumped...somebody tell me why this wouldnt work!

By the way....i really like the idea of a cheap SCSI interface..this would
probably be fast enuf for almost all concevable packet speeds.

Jim Burnes
(if you like my idea and want to chat with me about it call [phone])

------------------------------

Date: 19 Jun 90 19:20:26 GMT
From: umich!pmsmam![e-mail]  (Bill Meahan)
Subject: Network Models (long)
To: [e-mail]

Let's see,
    Asbestos jockey shorts?         Check.
    Nomex flame suit?               Check.
    Ready?                          Check.
OK, let's go:

Much of the discussion in the thread 'Concerns over TCP/IP' concerns the
willingness of various hams who are not a part of the rabid development
group to 'get with the program' and be a part of a 24-hour/7-day 'network'
(patterned after the Internet) that is the working model for the TCP/IP
developers.

Other would-be users who are not willing to do this are disparaged (albeit
politely) and relegated to some sub-human class known as 'BBS-users.'

Why must this be so?

Let's face it, the Internet is a GOOD model of a network.  The fact that
various sites are connected on a 24-hour/7-day basis fuels the fires of
development by making sure that messages/files/whatever are available in
'transmission time' to other folks elsewhere.

But the Internet is NOT the ONLY model of a good network.  At least as far
as 'leaf' sites are concerned.  In many organizations, the model of choice
is the 'Client/Server' model with 'workstations' as clients and some
'host' as the server.  Ideally, the server is up at all times, well-connected
to other sites of interest to the organization, and able to support the
clients **WHENEVER** they are powered up and attach themselves to the server.

Often (usually?) the workstations are diskless and rely completely on the
server for all files and even for downloads of the OS.  Users at the
workstations boot them up at the beginning of a session (or of the work day),
do their thing, and often power down their workstation when done.  The server
is 'smart' enough to queue mail (without complaint) until a given user logs
in.

Hmm.  This sounds suspiciously like the much-maligned BBS!

Perhaps the amateur community could be UNITED, rather than split, around
TCP/IP if some work were done to develop appropriate server software that
runs on top of the TCP/IP package so that workstations/leaf-sites could
come and go as appropriate to the USERS' needs without mucking up mail
and file transfers.  No, I'm not suggesting bootp downloads of DOS over
packet, but I AM suggesting that something be done so that the amateur packet
community can be united around a superior standard rather than fragmented
into this-and-that groups where the BBS users won't talk to the ROSE switchers
and the IP'ers won't talk to the keyboarders. etc. etc. sadly etc.

Believe it or not, there are actually hams who regard amateur radio as a
HOBBY and not as a second career.  These people should not be locked out
of the future simply because they're not workaholics or lack the technical
expertise to develop an IP-compliant cilent that runs on a VIC-20.

Come on, guys, lighten up.  Computers must serve people, not the other way
around!
--
Bill Meahan  WA8TZG             uunet!mailrus!umich!pmsmam!wwm
I don't speak for Ford - the PR department does that!

"stupid cat" is unnecessarily redundant

------------------------------

Date: 20 Jun 90 02:21:05 GMT
From: mailrus!uflorida!haven!sayshell.umd.edu![e-mail]  (Louis A. Mamakos)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Meahan) writes:

>Perhaps the amateur community could be UNITED, rather than split, around
>TCP/IP if some work were done to develop appropriate server software that
>runs on top of the TCP/IP package so that workstations/leaf-sites could
>come and go as appropriate to the USERS' needs without mucking up mail
>and file transfers.


Feel free to write such software.  Personally, I prefer the standard
TCP/IP functions pretty much as they exist.  Phil Karn provides you
all the source code, so you've got a good head start.  At least as far
as this USER is concerned, I'm happy. (Well, as happy as anyone can be
at 1200 bps...)  All us TCP/IP weenies are already united.


>No, I'm not suggesting bootp downloads of DOS over
>packet, but I AM suggesting that something be done so that the amateur packet
>community can be united around a superior standard rather than fragmented
>into this-and-that groups where the BBS users won't talk to the ROSE switchers
>and the IP'ers won't talk to the keyboarders. etc. etc. sadly etc.


Ah, SOMETHING should be done.  Presumably SOMEONE should do SOMETHING
about this terrible problem.  I wonder who?


>Believe it or not, there are actually hams who regard amateur radio as a
>HOBBY and not as a second career.  These people should not be locked out
>of the future simply because they're not workaholics or lack the technical
>expertise to develop an IP-compliant cilent that runs on a VIC-20.

That's a good point.  I hack on TCP/IP packet radio because its fun
for me.  Hacking BBS gateway stuff into the code is "fun" for me any
longer.  Who's going to (IMHO) waste their time to develop an IP based
implementation for a VIC-20?  If you want something, go ahead and do
it.  But don't demand that someone else provide this extra function
FOR you.  It is a hobby, and each of us has our own goals an
interests.  The problem is, my goals and interests don't match your
expectations.  Sorry about that.

What's in it for me?  We don't get paid to write this software, we do
it 'cause it fun?  It's only a hobby, right?

louie
WA3YMH

------------------------------

Date: 19 Jun 90 11:26:47 GMT
From: uhccux![e-mail]  (Antonio Querubin)
Subject: NOS & SLIP
To: [e-mail]

Which lines on a serial port does NOS require for proper handshaking/flow
control for SLIP?  And the same for a MacNET SLIP line?

------------------------------

Date: 19 Jun 90 01:20:15 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Re: concerns over TCP/IP (a non-expert's confusion)
To: [e-mail]

>==>  I don't know a whole lot about packet so I've been reading
>this newsgroup to try and get a feel for it. This attitude really
>burns me - sure, a C-64 may not be ideal for packet radio but not
>all hams are rich.

It all comes back to what you're trying to do.  If you're satisfied by defining
"packet radio" as having a terminal connect session with a local packet
bulletin board system, then great... your C64 will work fine.  If you want a
more exotic definition of "packet radio", then you may need more horsepower...

It's the same reason you won't find X11 running on a C64.

>Also, why should someone have to
>spend a boatloads of money on equip. for packet if they're not real
>sure whether it's a mode that they'll enjoy?

This reminds me of when, in high-school, I worked for an Apple dealer.  The
Apple 2 Plus was the rage then, but selling them was a pain.  If you sold a
guy a system with no floppy disk drive, just the cassette interface, he would
find it difficult to use, frustrating, etc., and eventually he'd either want
his money back, or he'd want to buy a disk drive.  If you tried hard to sell
him a disk drive, he'd moan and groan about the amount of money he was
spending on "something I'm not sure I'll like".  But almost without exception,
the guy who bought the floppy drive would be happy with his system, and the
only time he'd be back was to buy software, or more blank floppies, etc.

You can buy a C64 and TNC and define "packet radio" akin to loading BASIC at
cassette speeds... and it'll probably do just fine.

>I don't hear folk on HF
>complaining that all hams should buy a digitally synthesized tuner
>so it won't annoy them when your old Drake is 14 Hz off of their
>rice box's frequency. Gee, Wally.

Not exactly the same thing.  The modern, digitally synthesized tuner varies
in frequency accuracy from the Drake in a merely quantitative way.  But some
of the things some of us want to include in our definition of "packet radio"
are qualitatively different than what is possible with a C64.  Apples and
Oranges.

>==>  I don't believe this!  Mr. Karn calls the newcomers `brain dead'
>because either 1) they want to homebrew because they can't afford new
>equipment [ or 'cause they enjoy it ]  OR  2) they're new to packet
>radio and don't know all the ropes.

I don't think this is at all what Phil meant.  I personally believe he thinks
newcomers are "brain dead" when they expect to accelerate from 0 to 60mph in
6 seconds in an 1100cc VW Beatle, or the equivalent, when they expect to engage
in very sophisticated computer to computer networking activities with a C64...

Homebrewing is great... and newcomers are extremely welcome... as long as they
have or can learn to have a realistic view of what is achievable with given
resources.

>If y'all treat the new Communicator Class licensees like this, the influx of
>`new blood' is not going to help. They'll just get HTs and mobile VHF/UHF
>rigs & talk with their buddies on the local repeater.

This is going to happen, to a certain extent, anyway.  The hope with a
Communicator Class license is that we will attract more people in to the
hobby.  You are likely to attract other C64 users.  The repeater guys in the
area are likely to attract more HT-toting repeater users.  Phil and I are
likely to attract protocol hackers and digital networking hardware
professionals who *do* have Microvaxen, Suns, HP 9000's, etc at home that they
are excited about using to help build a "packet radio network" that matches
our definition.  There's nothing wrong with any of that... it's the way the
world works.

>Now, I'm not going to
>claim that the folk working packet MUST help the new guys, but without
>good elmers it is difficult to attract any but the most dedicated
>potential packeteer ... or attract new hams in general.

I have, and will continue to, be an "elmer" to folks in my area interested in
the area of amateur radio that I am interested in... high-speed digital
communications.  Got a WA4DSY 56kb modem that's not working and live nearby?
Sure, I'll help you out!  But the 1200-baud variant of "packet radio" has
about as much interest to me as working pileups on 20m... assymptotically
approaching zero.  I'd be a miserable elmer for someone who wants to contest
on HF, and I'd be a miserable elmer for someone who wants to use his C64 to
contact the local PBBS...

>     Now don't get me wrong - I think innovation is intrinsically a
>good thing, but don't leave the rest of us in the dust. Mark the path
>so we can follow you, step by step, as our finances and our free time
>allow. That is, if you really want more folk who are packet literate.

I think we do.  And I think we're marking the trail pretty well.  Phil and
friends left a couple of marks in the messages you replied to... one is
that to play with sophisticated computer networking on radio links, you need
more computer than a C64...

73 - Bdale, N3EUA

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu, 21 Jun 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #62
To: packet-radio


Packet-Radio Digest         Thu, 21 Jun 90       Volume 90 : Issue  62

Today's Topics:
              Message of thanks
            Multi-TNC controller. (2 msgs)
            Network Models (long) (5 msgs)
            Parallel port vs SCSI

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Wed, 20 JUN 90 15:58:06 GMT
From: [e-mail]
Subject: Message of thanks
To: packet-radio <@NSFnet-Relay.AC.UK:[e-mail]>

    I would like to thank all the people I haven't managed to thank
personally in helping me for my project (Design and building of an
experimental TNC). Thanks to the list. The whole thing went smoothly,
demonstration, documentation, etc. Long life to packet radio.

Olivier Crepin-Leblond, Computer Systems & Electronics III,
Electrical & Electronic Eng., King's College London, UK.

------------------------------

Date: Wed, 20 Jun 90 13:32 N
From: <[e-mail]>
Subject: Multi-TNC controller.
To: [e-mail]

Distribution-File:
    [e-mail]

               DESIGN OF A MULTI-TNC CONTROLLER
                      by:
      Andre Bakkers PA0APA,  Erwin Hoogzaad PE1CFJ, and  Marcel Schwirtz
   ETGD Club Station, University of Twente, PO box 217, NL-7500 AE Enschede
              indebted to DG9FU, DB8AS and PA0HWB
              email: [e-mail]

The june 1990 issue of QEX will contain our article describing a multiport-TNC
controller. The following text contains some background information.

On October 5 1988, DG9FU and DB8AS launched the idea to use RTS/CTS control
in a system using TNC's equipped with NetRom software, to prevent packet
collision on the RS-232 channel. These collisions occur when one TNC is
transmitting while another TNC wants to start transmitting packets.

PA0HWB has performed measurements on the RS-232 channel that indicate, at
least in his system, that this channel exhibits an efficiency of 20%. With
a baud rate of 9600 on the RS-232 channel this results in an effective baud
rate through the node of 9600x0.20 = 1920 Baud. Division by the number of
channels, in his case four, results in 480 Baud per TNC!

As soon as one TNC activates his RTS line (pin 5, active = low), usually
two other TNC's start to transmit (Murphy's law). Possibly this may be
improved in the NetRom software as well.

The idea of DG9FU and DB8AS consists of a proposal to enable the CTS (pin
4) inputs of the TNC's one by one with the use of a counter. The counter
will be stopped as long as the TNC replies with an active low RTS signal
(pin 5), within approximately 3 mSec.. As a result this enabled TNC is the
only one that may start transmitting on the RS-232 channel. As soon as the
packet has been transmitted, this TNC will deactivate its RTS line which in
turn allows the counter to resume counting.

The DG9FU and DB8AS design, consisting of a 4017 counter and a NE555 clock
oscillator, excels in simplicity, but suffers from the well known problems
of the diode matrix. Besides any TNC can halt the counter at any time by
setting its RTS low. The TNC that is enabled by the counter will
consequently be allowed to start transmitting. However, this need not be
the same TNC that made its RTS low. As a result the system deadlocks.

In the Multi-TNC Controller, which operates completely at TTL level, the
counter will continue to count in such a case until the correct TNC is
enabled. Then the counter will stop and this TNC will be allowed to
transmit its packet. Moreover the RxD signals are enabled with the CTS
signals.

A maximum of 8 TNC's may be connected to the controller, not connected
ports will not hamper the operation of the controller. TNC's may be
connected or removed while the controller is in operation.

At the club station PI8THT of the University of Twente this idea has been
converted into logic formulas and has resulted in an EPLD and a printed
circuit board design. The logic expressions are available as EPLD design file
on request. The EPLD type is EP900-PC2 or EP900-DC for the non-erasable or
erasable type respectively. The printed circuit board layout is available as a
plotter file or as a film at a nominal charge.

The Multi-TNC controller has a theoretical throughput equal to maximum of all
channels, almost 1200xn where n is the number of channels. If the RS-232 baud
rate is increased from the usual 9600 to 19200 Baud, the resulting delay of
the network node becomes hardly noticeable. Furthermore all channels will be
serviced evenly and one will not even be bothered by the delay of Mailbox
traffic as long as the Mailboxes use the maximum value of PACLEN = 236 and a
value of MAXFRAME = 1 as the setting for their TNC's. The TNC's will scanned
by the adjustable clock which may be adjusted between 200 and 400 Hz.

The Multi-TNC controller has been in operation at three nodes in Holland for
about 6 month, showing an improved network thoughput.
--------------------------------------------------------------------------------
My e-mail address is:
[e-mail] (Andre Bakkers)
or:
[e-mail] (Andre Bakkers)

Mailing address: Ir. A.W.P. Bakkers
         Twente University, EL-BSC Dept.,
         P.O. Box 217,
         7500 AE Enschede, Netherlands.

Tel:[phone] or [phone] (secretary)
Fax:[phone]
Telex: 44200 thtes

------------------------------

Date: 20 Jun 90 12:56:49 GMT
From: bacchus.pa.dec.com!shlump.nac.dec.com!ryn.esg.dec.com!pstjtt.enet.dec.com![e-mail]  (>>>==>PStJTT)
Subject: Multi-TNC controller.
To: [e-mail]

In article <[e-mail]>, [e-mail] writes...
>Distribution-File:
>The june 1990 issue of QEX will contain our article describing a multiport-TNC
>controller. The following text contains some background information.

Oh boy!  I read your QEX article and liked it, but I'm confused about
something.  The idea seems to be servicing multiple TNC's by
multiplexing a single RS232 line.  Why not just use separate lines?
Multiple UART chips are cheap enough and it doesn't seem any more
complex or expensive to make a multi-port RS232 board than to build a
board that implements daisy-chaining on an RS232 line.

It's obvious from the amount and quality of work that went into the
article that I'm missing something that makes this solution better.
Could you do an "idiot's summary" of why this method was chosen?

        >>>==>PStJTT
            Patrick St. Joseph Teahan Taber

Mail address:  Nahhhhh, you don't want to send me mail....

------------------------------

Date: 20 Jun 90 14:22:23 GMT
From: swrinde!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Meahan) writes:
>Believe it or not, there are actually hams who regard amateur radio as a
>HOBBY and not as a second career.  These people should not be locked out
>of the future simply because they're not workaholics or lack the technical
>expertise to develop an IP-compliant cilent that runs on a VIC-20.

So what are you saying? Should code developers abandon a minimally adequate
platform like the PC and retreat to a VIC-20 for their coding? You do
understand that a clone PC is CHEAPER than a new C64 and disk drive don't
you? You do understand that developing code for networking IS the hobby
of the code developers don't you? Are you saying they should practice THEIR
hobby only on machines that they KNOW are inadequate to the task?

There are certain minimum requirements to playing network packet radio.
You need a license.
You need a radio or a GRAPES RF modem.
You need a TNC or digital interface card.
You need the software supplied FREE by the code developers.
YOU NEED A PC.

The minimum requirements are less than and MUCH cheaper than those required
for DXing, working satellites, or ATV. If you want to play, you gotta
pay (at least a little).

I'm sorry, but I have little patience with people who aren't willing to
meet the minimum requirements and who complain that the network won't work
with their Halicrafters Sky Buddy and ENIAC.

Gary KE4ZV

------------------------------

Date: 20 Jun 90 19:04:41 GMT
From: usc!samsung!umich!pmsmam![e-mail]  (Bill Meahan)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>In article <[e-mail]> [e-mail] (Bill Meahan) writes:
>>Believe it or not, there are actually hams who regard amateur radio as a
>>HOBBY and not as a second career.  These people should not be locked out
>>of the future simply because they're not workaholics or lack the technical
>>expertise to develop an IP-compliant cilent that runs on a VIC-20.
>
>So what are you saying? Should code developers abandon a minimally adequate

[flame deleted]

You miss the point entirely:

The TCP/IP crowd as represented in this newsgroup seems to be rapidly becoming
a group whose credo could be: "Subscribe to exactly MY model of what amateur
radio should be, or go to hell."  This attitude isn't new or restricted to
any one group - it's been a major part of ham radio for the entire 25 years I've
held my license and has been expressed by the homebrewers, the traffic fanatics,
the public service enthusiasts etc. etc. etc.

What I am advocating is NOT that the 'leading edge' developers ABANDON anything.
What I think needs to happen, however, is to recognize that not EVERY ham NEEDS
to have a 'well-connected' host that is up 24-hours/7-days.  By EXPANDING the
vision and developing such things as a restricted telnet client that CAN run
on, say, a C-64 so that the interested ham can log in to a well-connected
server and read the news, send some mail, read some other mail, establish
a telnet link to someone else, etc.

What has the hobby got to lose be becoming more INCLUSIVE instead of more
EXCLUSIVE?  Why is the only 'acceptable' newcomer a network engineer?
Couldn't the 'BBS' (or server in my parlance) become more like one of the
public access UNIX systems where conferencing, USENET, e-mail and the like
are available to anyone with a terminal and a modem and do it based on
IP rather than 'vanilla' AX.25?  That way, the interested but restricted
(by funds/expertise/time) amateur could take part in the IP-based future
rather than be forced to remain in the X.25 past.

Why should amateur radio, which historically has been an innovator, be
stuck FOLLOWING technology instead of LEADING it?   Client/server architectures
are becoming extremely common throughout industry.  In fact, it is trivial
to put together a system (on an Ethernet) consisting of a primary server
that HAS NO TERMINAL/SCREEN AT ALL and 'terminal servers' (NOS-in-a-box) that
either happily connect dumb terminals to the server via telnet, or gateway
SLIP connections if the attached devices has any brains at all.  Why can't
amatuer packet be as accomodating?
--
Bill Meahan  WA8TZG             uunet!mailrus!umich!pmsmam!wwm
I don't speak for Ford - the PR department does that!

"stupid cat" is unnecessarily redundant

------------------------------

Date: 21 Jun 90 02:09:04 GMT
From: mentor.cc.purdue.edu!noose.ecn.purdue.edu!en.ecn.purdue.edu![e-mail]  (Milton D Miller)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Meahan) writes:
> ... 24-hour/7-day 'network' (patterned after the Internet)
>
>But the Internet is NOT the ONLY model of a good network.  At least as far
>as 'leaf' sites are concerned.  ...
> Ideally, the server is up at all times, well-connected
>to other sites of interest to the organization, and able to support the
>clients **WHENEVER** they are powered up and attach themselves to the server.
> ...  The server
>is 'smart' enough to queue mail (without complaint) until a given user logs
>in.

Have you looked at using POP and NNTP?  I rember seeing a reference about
someone doing somethig with pop (probably in May or sooner while I was
still at school).

>
>Hmm.  This sounds suspiciously like the much-maligned BBS!
>
>Perhaps the amateur community could be UNITED, rather than split, around
>TCP/IP if some work were done to develop appropriate server software that
>runs on top of the TCP/IP package so that workstations/leaf-sites could
>come and go as appropriate to the USERS' needs without mucking up mail
>and file transfers.

Using POP and a mail server would take care of the mail and news transfer
items... The model for using pop that I would propose is have a client
login and download the mailbox to the local system, which then adds it
to the local user's mailbox for later processing.

Two points on this model:
1)  The hardware required for such a server is not the same as that suited
to hill-top environments, much like the reason for bbs's are not on the
hills.  I propose two systems: the hilltop IP switch and a server 'close'
to it, but readily accessable to the sysop.

2)  I am reasonably certian that not all of the software is written (yet).

After theese, the next (and mabye hardest administratively) would be
maintaining the routing tables, especially in the network switches...


> ... not workaholics or lack the technical
>expertise to develop an IP-compliant cilent that runs on a VIC-20.

Except for the network look, the function would be not much more than
that available via ax25 connects to the station.  I think the point that
several are trying to make is that fitting TCP/IP into a C64 or VIC-20
or (fill in your favorite hardware here) is not a trivial task.  However,
if you want to take Phil's code, and chop out all but the IP and telnet
portions then port that, go ahead (mabye also leave the DNS client?
for routing, one default with redirects should  be ok with a IP hub,
but I digress).

Once you (or whoever) writes the 'generic' low-thruput telnet-only
code (or extracts it from Phil's), it might be a better base for porting
to other 'dumb' systems.  Phil is fighting bloating, but he is also trying to
provide a broad, useful generic base that will also be useable with
many varients of PC (and other for the generic stuff) hardware.

My intrests,  once I get my license (I am learning the secret code
right now :-), include (in order of feasable attack, not necessarly intrest):

    POP and NNTP clients/servers, allowing users to 'go away' and still
    participate in TCP/IP networks

    New partitions of the network layers, to support intellegent hardware
    and reduce host load for higher speed networks and/or background operation

    New routing protocols and multicast protocols (eg VMTP) that better
    fit the amateur packet Real-World(TM) model

    General applications that will use and require the higher speed networks
    (and getting these into operation)

milton

PS: How did I get interested, you ask?   well, as far as TCP/IP goes, it
comes from reading RFC's and kernels and...
For Amateur radio, it is from my roomate at school.

PPS: I am doing this at 300 baud, so please bear with any typo's I missed.

--
Milton D. Miller II
[e-mail]   ...!pur-ee!milton
ECN consultant and co-op student on work term

------------------------------

Date: 21 Jun 90 03:53:46 GMT
From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun![e-mail]  (Jon Bloom)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bill Meahan) writes:
> In article <[e-mail]> [e-mail] (Gary Coffman) writes:
> >In article <[e-mail]> [e-mail] (Bill Meahan) writes:
> >>Believe it or not, there are actually hams who regard amateur radio as a
> >>HOBBY and not as a second career.  These people should not be locked out
> >>of the future simply because they're not workaholics or lack the technical
> >>expertise to develop an IP-compliant cilent that runs on a VIC-20.
> >
> >So what are you saying? Should code developers abandon a minimally adequate
>
> [flame deleted]
>
> You miss the point entirely:
>
> The TCP/IP crowd as represented in this newsgroup seems to be rapidly becoming
> a group whose credo could be: "Subscribe to exactly MY model of what amateur
> radio should be, or go to hell."  This attitude isn't new or restricted to

If that's the impression given by the postings here, it is a false one.
I can say with some certainty that the major players in the TCP/IP
development effort have _no_ intention of fostering an elitist ham radio.
Is there technological chauvinism within that group of people?  Probably
a little.  But I think the record shows that the TCP/IP software is
getting closer to the kind of thing you espouse.  The current NOS system
includes "vanilla" AX.25 and NET/ROM access to the system, allowing any
user of an off-the-shelf TNC to access the NOS station, at which point
he/she can "bridge" to TELNET, thus accessing services of the TCP/IP
network.  Given that, is a VIC-20 TELNET implementation critically needed?

> are becoming extremely common throughout industry.  In fact, it is trivial
> to put together a system (on an Ethernet) consisting of a primary server
> that HAS NO TERMINAL/SCREEN AT ALL and 'terminal servers' (NOS-in-a-box) that
> either happily connect dumb terminals to the server via telnet, or gateway
> SLIP connections if the attached devices has any brains at all.  Why can't
> amatuer packet be as accomodating?

It's getting there.  Have a little patience and you will see it happen.
In the meantime, let's let the developers work on the part of the problem
that most interests them.  Understand that NOS is a work in progress, as
is the development of an amateur digital network.  I agree that the
average user (whoever that is :-) needs to be brought on board, but it's
too early for that just yet.

The only complaint I have with you, Bill, is that you seem to be saying
that because some talented people have developed something worthwhile
on their PCs/Macs/Amigas they are somehow _obligated_ to make it
available for the VIC-20/C-64/Timex 1000.  I don't see it, myself.
The fact that these people are not personally interested in spending
their time developing C-64 code is not a black mark against them.
Frankly, I'd rather they spend their time advancing the state of the
art than dragging each ham up by his/her bootstraps to the present state
of the art.

Jon

--
Jon Bloom, KE3Z                              | American Radio Relay League
Internet: [e-mail]         |
Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."

------------------------------

Date: 21 Jun 90 03:43:10 GMT
From: zaphod.mps.ohio-state.edu!swrinde!emory!rsiatl![e-mail]  (John G. DeArmond)
Subject: Network Models (long)
To: [e-mail]

[e-mail] (Bill Meahan) writes:

>The TCP/IP crowd as represented in this newsgroup seems to be rapidly becoming
>a group whose credo could be: "Subscribe to exactly MY model of what amateur
>radio should be, or go to hell."

Bill,

I've made almost the same arguments before but I think you've missed the point.
Yes, there are a bunch of very opinioniated people writing network code and
yes, some of their opinions are plain BS.  HOWEVER, they ARE the ones
writing the code and that means that they get to do it however they like.
My major gripes have been that a) the implementors have been building to
an idealized model of amateur networking that does not work out in the
field and b) they don't communicate very well with the rest of us.  (That
criticism is now muted somewhat with Phil's release of a draft manual)
Other complaints include many developers going their own way and doing little
to assist in keeping all the code synchronized.  But the fact remains, there
IS networking code available in source form for anyone else to work with.


>What I think needs to happen, however, is to recognize that not EVERY ham NEEDS
>to have a 'well-connected' host that is up 24-hours/7-days.  By EXPANDING the
>vision and developing such things as a restricted telnet client that CAN run
>on, say, a C-64 so that the interested ham can log in to a well-connected
>server and read the news, send some mail, read some other mail, establish
>a telnet link to someone else, etc.

First off, no one who is knowledgable enough to work with IP code is going
to babysit C-64 users.  Not to mention the misery a porting effort would
involve.  Like Gary said, if you wanna play, at least you gotta buy a ball.
Considering that I can buy several well equipped XT-class machines for the
cost of a modern HF rig, I can't shed too many crocodile tears for those
who cry poorhouse.  Once they get the basic equipment, then we can help them.

I start having problems with the current situation when it is claimed that
people must invest in the latest and greatest expensive and unreliable
gadget of the day in order to be REAL packet hams.  Someone who has a
PC, a radio, a TNC and an antenna should be able to participate at
some level.  Maybe not much but at least a bit.  And I predict the time
will come when not too many even casual users will want to work with less
than 9600 baud.

The key here is services.  Quite frankly, currently I cannot see much to keep an
average ham's interest in packet once the new wears off.  Services now are
limited to BBS operation.  What is needed is for some of the people who
complain about the plight of the average ham (and who are quite capable of
doing the deed) to start writing code instead of more whining.  How about
a network chat system, a call sign database server, a contest/DX server,
voice mail, store and forward mail, news and the like?  The platform is
available in the form of TCP/IP that pretty much works now and has a
fairly well defined API.  When I speak of servers, I also include the clients
to run on the pc, not just something to be telneted into.

To summarize, I don't give a damn about your typical old whiny ham who
wants to do no more than keyboard chat while refusing to support the
work of others with neither time nor money.  If they don't show any more
interest than that, quite frankly, let them go back to 75 meters.

On the other hand, I do believe that modern networking technology should
be available to the ham of average technical ability with a minimum of pain.
No, it will never become a turnkey situation where someone can pride themselves
in their ignorance and still use the technology effectivly.  We can
however, put together a system whereby a ham can plug a few components in,
configure a few things, and be on the air.  I'd like to think that this
task would involve plugging in an interface board that connects to a
turnkey WA4DSY/GRAPES RF modem at 56k :-)

So perhaps the next time someone complains about the elitists on packet,
perhaps you could shove a disk containing NOS sources under their noses
and suggest maybe they take the several man-years of work involved and
build something useful on top of it.

John

--
John De Armond, WD4OQC  | We can no more blame our loss of freedom on congress
Radiation Systems, Inc. | than we can prostitution on pimps.  Both simply
Atlanta, Ga             | provide broker services for their customers.
{emory,uunet}!rsiatl!jgd|  - Dr. W Williams |                **I am the NRA**

------------------------------

Date: 20 Jun 90 02:49:19 GMT
From: cs.utexas.edu!samsung!emory!rsiatl![e-mail]  (John G. DeArmond)
Subject: Parallel port vs SCSI
To: [e-mail]

[e-mail] (Johnathan Vail) writes:

>I like the SCSI idea.  Sign me up for several!  I can use it on my Sun
>3/60 and since we are using SCSI here I may have a line on surplus
>equipment to use.  The paralell port may have some value as far as PCs
>are concerened but really loses in high speed applications because of
>the lack of DMA.  If you have to babysit an 8 bit port you may as well
>just run an 8530 or some serial port directly.

As someone who as suffered through a couple of years' worth of SCSI
non-standard hardware and software, I must ack the question of whether
you've ever really dealt with SCSI at other than a user level.  I'm
not trying to be combative but SCSI as it exists today is quite simply
a mess.  If this fellow did build a board that talked SCSI, hung it
on an SCSI bus with other devices and tried to run it, I'd bet even
money that either his card or some other device on the bus would
malfuction.  Especially if he writes the driver according to published
specifications instead of reverse engineering the bus with a logic
analyzer.

If you suggest that one simply install another SCSI interface card,
then the question begs, why bother.  Why not keep it simple and plug
a parallel port card in?  Unless you get a SCSI host adaptor card
capable of bus mastering in a PC, DMA is pretty much a waste.  Remember
that to stuff 56kb/second in/out the port only requires 7kbytes/second - a
fairly trivial task.  If we're talking anything much faster than 56k,
we really should be looking at intelligent cards with dual-ported RAM
in order to off-load the processor.

Once we begin to talk more than about a hundred bux or so, we really need
to look at ethernet adaptors.   Remember what the original objective of the
discussion was - to provide something cheap capable of being use by Joe
EveryHam at moderate speeds.

Perhaps the thing to do is to build a protocol converter that has
a thinnet port on one side and a sync port on the other.

John

--
John De Armond, WD4OQC  | We can no more blame our loss of freedom on congress
Radiation Systems, Inc. | than we can prostitution on pimps.  Both simply
Atlanta, Ga             | provide broker services for their customers.
{emory,uunet}!rsiatl!jgd|  - Dr. W Williams |                **I am the NRA**

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri, 22 Jun 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #63
To: packet-radio


Packet-Radio Digest         Fri, 22 Jun 90       Volume 90 : Issue  63

Today's Topics:
                 info needed
            Network Models (long) (5 msgs)
                  NOS & SLIP
            Seeking technical info: TNC-2
               TCP/IP inhibitor
               TNC information request.

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 21 Jun 90 18:17:26 GMT
From: shlump.nac.dec.com!engage.enet.dec.com!col01![e-mail]
Subject: info needed
To: [e-mail]

    Some days (weeks?) ago, i saw a list of people responsible for
    the assignment of network-numbers in their countries.
    I lost this list, so would someone be so kind to e-mail
    this list to me?
    I need the name (and network address) for the guy in W.Germany.

    regards
    /jr
################################################################################
    Josef Reisinger
    Digital Equipment Corporation
    5000 Koeln
    Eupener Strasse

[e-mail]            ! VAX/VMS via USA
..unido!decum!col01.dnet!reisinger      ! VAX/VMS in EUROPE

[e-mail]            ! VAX/Ultrix via USA
..unido!decum!colix.dnet!reisinger      ! VAX/Ultrix in EUROPE
################################################################################

------------------------------

Date: 20 Jun 90 20:38:32 GMT
From: rochester!rit!cci632![e-mail]  ( co-op)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>So what are you saying? Should code developers abandon a minimally adequate
>platform like the PC and retreat to a VIC-20 for their coding?

I don't think that anybody is saying this ... at least, we can easily
dismiss the people who ARE saying it as (ahem) idiots, and drop the
conversation.  The bigger problem is that you have the "status quo,
it works why change it" group vs. the techies.

We could certainly coexist, except that I as a techie feel seriously
out-numbered.  I also realize that price is closely related to the
size of the user base (supply and demand, etc) and so it is to my
benifit to show others the wonders of it all.

The point of me starting this heated discussion is not to argue about
who should be using what box. It's that the C-64 users are telling many
newcomers, "Yes, a C-64 or VIC-20 or other notsopocketcalculator will
work just as well as a PC".  NO.  It will NOT work just as well.  The
newcomers are NOT being given the whole story; they are being told
that a $80 solution is just as good as a PC.  Who would rather pay
$600 for something that somebody just told you an be done for $80?

Well...OK, that's not the whole story...but it's part of it which I
would like to see picked up on here.

>YOU NEED A PC.

Welllllllllllllll...I was hoping that by this time (Summer 1990) that
wouldn't be true.  The Data Engine turned out to not be what I had
expected, though, and I see it as a neat toy but not particularly
useful to most people.  From the marketing/promotional standpoint
(and for the good of ham radio), I would have prefered to see the
next generation of TNC2 come out; something on the order of an 8086-
based TNC-2 with more memory.  This wouldn't have driven the price up
very much (8086's and 8088's are cheap; even better, NEC V-20!!!)
and memory is not THAT unreasonable.  This would have several
BIG advantages:

    - be able to develop software in a native environment,
        rather than using cross-development tools.

    - make it perfectly reasonable to implement higher-level
        protocols with very little work, e.g. how about a
        partial nos-in-a-box that Joe User can use with
        a dumb terminal ?

    - Give us some long-haul networking capabilities with a
        good, cheap box that you can bolt on to a tower in
        the middle of nowhere and FORGET ABOUT IT.


Comments?
                                            Chris

--
(These opinions are my own, not CCI's or STC's)
Christopher E. Piggott, WZ2B                                (ex-N2JGW)
Computer Consoles, Inc. (an STC company)                 Rochester, NY
cs.rochester.edu!cci632!ccird7!cep  or  uunet!ccicpg!cci632!ccird7!cep
Work: (716)-482-5000 x2307                        home: (716)-292-0243

------------------------------

Date: 21 Jun 90 11:47:36 GMT
From: usc!samsung!umich!pmsmam![e-mail]  (Bill Meahan)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Jon Bloom) writes:
>
>It's getting there.  Have a little patience and you will see it happen.
>In the meantime, let's let the developers work on the part of the problem
>that most interests them.  Understand that NOS is a work in progress, as
>is the development of an amateur digital network.  I agree that the
>average user (whoever that is :-) needs to be brought on board, but it's
>too early for that just yet.
>
>The only complaint I have with you, Bill, is that you seem to be saying
>that because some talented people have developed something worthwhile
>on their PCs/Macs/Amigas they are somehow _obligated_ to make it
>available for the VIC-20/C-64/Timex 1000.  I don't see it, myself.
>The fact that these people are not personally interested in spending
>their time developing C-64 code is not a black mark against them.
>Frankly, I'd rather they spend their time advancing the state of the
>art than dragging each ham up by his/her bootstraps to the present state
>of the art.
>
>Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."

I DON'T WANT NOS IN A C-64! (I don't even own one!)

It seems that a lack of a smiley after the VIC-20 comment means that nobody
caught that it was a wry/sarcastic remark!

What I DO think is necessary, as other posters have implied, is that there
be some sort of GATEWAY such that those who are STUCK with the (fill in
your favorite bitty box) can make USE of the more sophisticated features
provided by NOS/NET while the sophisticated stuff is running on some
far more powerful server.

Think of KISS turned upside down - a client node runs a SIMPLE protocol
that allows it to connect with the server and maintain multiple connections
(Please not AX.25!).  The server takes the commands/data from the client node
and processes them, wrapping the appropriate IP headers around them if
necessary and forwarding them on via the well-connected IP network.  Returned
stuff gets unwrapped and returned to the client node using the SIMPLE protocol.

A bit of malice aforethought could result in a fairly efficient point-to-
point service that WOULD fit in a bitty box - after all, it doesn't NEED
to worry about more than ONE route/connection!

Is my point a little clearer?  Do you catch my contention that it is NOT
necessary for ALL hams to run a FULL implementation of NET/NOS in order
to USE them?

After all, I'm writing this on a PC attached to a (large) UNIX box.  By
comparison, the PC is a bitty box.  But who cares?  By terminal connect
I am able to make full use of the capabilities of my UNIX system without
having to run full UNIX on my PC.

Let me rephrase my proposal like this:  Let's develop software for
USER INTERFACES that will run happily on bitty boxes and can connect
cleanly and efficiently with ONE server (at a time).  Let the server
be whatever the server provider (individual or club) can afford and let
it run the most sophisticated NOS Phil and the rest can possibly develop.
By doing such, by allowing USERS to get by with simple equipment, we can
reach out to include a far greater number of hams in the digital network
of the future.

If this doesn't clarify it, then let's drop it now.  No sense wasting
net bandwidth with flame wars.
--
Bill Meahan  WA8TZG             uunet!mailrus!umich!pmsmam!wwm
I don't speak for Ford - the PR department does that!

"stupid cat" is unnecessarily redundant

------------------------------

Date: 21 Jun 90 13:54:09 GMT
From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Meahan) writes:
>You miss the point entirely:
>
>The TCP/IP crowd as represented in this newsgroup seems to be rapidly becoming
>a group whose credo could be: "Subscribe to exactly MY model of what amateur
>radio should be, or go to hell."  This attitude isn't new or restricted to
>any one group - it's been a major part of ham radio for the entire 25 years I've
>held my license and has been expressed by the homebrewers, the traffic fanatics,
>the public service enthusiasts etc. etc. etc.
>
>What I am advocating is NOT that the 'leading edge' developers ABANDON anything
>What I think needs to happen, however, is to recognize that not EVERY ham NEEDS
>to have a 'well-connected' host that is up 24-hours/7-days.  By EXPANDING the
>vision and developing such things as a restricted telnet client that CAN run
>on, say, a C-64 so that the interested ham can log in to a well-connected
>server and read the news, send some mail, read some other mail, establish
>a telnet link to someone else, etc.
>
>What has the hobby got to lose be becoming more INCLUSIVE instead of more
>EXCLUSIVE?  Why is the only 'acceptable' newcomer a network engineer?
>Couldn't the 'BBS' (or server in my parlance) become more like one of the
>public access UNIX systems where conferencing, USENET, e-mail and the like
>are available to anyone with a terminal and a modem and do it based on
>IP rather than 'vanilla' AX.25?  That way, the interested but restricted
>(by funds/expertise/time) amateur could take part in the IP-based future
>rather than be forced to remain in the X.25 past.
>
>Why should amateur radio, which historically has been an innovator, be
>stuck FOLLOWING technology instead of LEADING it?   Client/server architectures
>are becoming extremely common throughout industry.  In fact, it is trivial
>to put together a system (on an Ethernet) consisting of a primary server
>that HAS NO TERMINAL/SCREEN AT ALL and 'terminal servers' (NOS-in-a-box) that
>either happily connect dumb terminals to the server via telnet, or gateway
>SLIP connections if the attached devices has any brains at all.  Why can't
>amatuer packet be as accomodating?
>--

I think you missed MY point entirely. I was not saying that everyone
should have to be a network engineer or that a BBS type service should
go away. What I was saying was that the VIC-20/C64/terminal is not IMHO
an adequate platform for ANY type of IP based service. And further, the
code developers have the tools to develop code for the PC, the PC is
extremely price competitive with a C64+disk, and none of the current
HOBBY developers have ANY interest in attempting a client on an eight
bit machine anymore. This does not mean that YOU are not welcome to
develop such a client. All the C source is freely available.

Many of us recognize that not every ham is willing to have a 24hr a
day IP host at his station. This is why work is proceeding on POP,
the post office protocol. Also, some of us allow telnet login on
our Unix(tm) boxes. Bdale's Nos-in-a-box is mainly aimed at switch
service (no disk) but could be used to allow a plain terminal/TNC
user to connect and do a telnet session.

The major problems that we have with link level only AX25 users are
the inadequate channel management in the TNC firmware, and the
attitude that ALL I NEED IS A TNC AND A TERMINAL TO DO PACKET and
why don't YOU write software to let me do all the neat things you
keep talking about. If I were in the BUSINESS of selling networking
products, this MIGHT be a legitimate attitude, BUT THIS IS A HOBBY.

Gary KE4ZV

------------------------------

Date: 21 Jun 90 18:25:14 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Network Models (long)
To: [e-mail]

>The TCP/IP crowd as represented in this newsgroup seems to be rapidly becoming
>a group whose credo could be: "Subscribe to exactly MY model of what amateur
>radio should be, or go to hell."

Ok, fair enough.  That is, in my opinion, a serious misrepresentation of what
most of the "TCP/IP crowd" is really like, but I'm more than willing to admit
that we may have come to appear that way in this forum... ouch.

>By EXPANDING the
>vision and developing such things as a restricted telnet client that CAN run
>on, say, a C-64 so that the interested ham can log in to a well-connected
>server and read the news, send some mail, read some other mail, establish
>a telnet link to someone else, etc.

The effect that you are asking for is actually happening, with the NOSINABOX
code that N4PCR and I are working on for the Grace PackeTen card, the
Kantronics DE, and the AEA PS-186.  We use a slightly different model, to
avoid having to find pneumatic shoehorns and the time to apply them to each of
the many "small home computers" like the C64.  We put code in the local
packet switch for a community that allows AX.25 users to connect to the switch
(many at a time, even), and get access to a set of services from there.  In
effect, you're plugging your C64 with AX.25 "terminal" into a "terminal
server" that speaks IP, etc...  Not absolutely sure, but I think this solves
the problem you're identifying, *without* requiring us to write any code for
things like C64's...

>What has the hobby got to lose be becoming more INCLUSIVE instead of more
>EXCLUSIVE?

I wish I knew...

>Why is the only 'acceptable' newcomer a network engineer?

This is not my perception at all.  The problem that started this current
round of discussion might be paraphrased "why can't I put a big-block V8 in
my Honda Civic?".  Noone that I've seen has tried to suggest that Honda's
should be banned from the roads, but many folks have suggested more or less
successfully that you need something bigger than a Honda to wedge in a big
engine...

Pardon my frequent slip into analogy, but from the mail I've gotten in the
last couple of days, it seems to be helping some folks understand the
difference between "C64 bashing" and "realizing that some tasks require more
horsepower than a C64 provides".

>Couldn't the 'BBS' (or server in my parlance) become more like one of the
>public access UNIX systems where conferencing, USENET, e-mail and the like
>are available to anyone with a terminal and a modem and do it based on
>IP rather than 'vanilla' AX.25?  That way, the interested but restricted
>(by funds/expertise/time) amateur could take part in the IP-based future
>rather than be forced to remain in the X.25 past.

I certainly hope so!  Around here, it's almost working now... we're providing
a whole set of services on a Unix machine running IP, and anyone with NET or
NOS can get access to those services with Telnet, FTP, NNTP, etc... the next
step is to bring a switch or two online with the terminal server code, then
this same set of services will be available to anyone with AX.25 capability...
albeit slowly.

>Why should amateur radio, which historically has been an innovator, be
>stuck FOLLOWING technology instead of LEADING it?

Probably the same reason our country now follows technology more than leading
it in any of a number of areas... a poor education system, negative financial
motivation to excell, etc... but let's leave that one for a hot night and a
cold beer...

>Why can't amatuer packet be as accomodating?

I think it can.  It just requires more folks actually working on making it
happen, and less people "following", asking the doers why it hasn't happened
yet...

73 - Bdale, N3EUA

------------------------------

Date: 21 Jun 90 15:43:05 GMT
From: uc!shamash![e-mail]  ( VTC)
Subject: Network Models (long)
To: [e-mail]

I fail to see what the big stink over C64's running TCP is.  I think it could
be done.  I bought one when the suckers cost $550.00.  I put it in the closet
about 3 years ago.  Now I program Cybers, Sperry 1100's Suns, Apollos, you
name it.  It would be tough to have multilple session telnets, ftp's and a bbs,
but it is time someone wrote at least a client for it.  ( Not me - I am too
busy writing PC code for NOS).  The point is,  I bet alot of people would like
to do it, but would feel stupid about it.  Frankly, if someone comes up with
a telnet or ftp client, Ill pull mine out of the closet.  Be sure to make it
compatible with Digicomm.

By the way -  a real telnet server, one that puts you at the C64 command prompt
would be a hell of a lot easier to do than putting that on a pc.  It might make
us PC programmers blush.......

Jeff

------------------------------

Date: 22 Jun 90 08:19:49 GMT
From: bellcore-2!ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: NOS & SLIP
To: [e-mail]

In article <[e-mail]> [e-mail] (Antonio Querubin) writes:
>Which lines on a serial port does NOS require for proper handshaking/flow
>control for SLIP?  And the same for a MacNET SLIP line?

Standard SLIP requires no handshaking lines at all; just three wires will do
(gnd, tx data, rx data). The recent version of NOS includes a contribution
that supports optional RTS/CTS handshaking; that's what the mention of "CTS
ints" in the asy stat command refers to.  Check the docs and the source for
the details of how this operates; I haven't actually used this feature
myself.

Phil

------------------------------

Date: 21 Jun 90 13:40:34 GMT
From: rochester!rit!cci632![e-mail]  ( co-op)
Subject: Seeking technical info: TNC-2
To: [e-mail]

I have not been able to find much useful information on TNC-2's.
At least, not information which is on the level I seek.

I would like to confirm some of the following information, as well as
ask some questions:

1.      It appears that the I/O mapping in a TNC-2 is as follows:

        PORT 0 - HDLC data register
        PORT 1 - HDLC control register

        PORT 2 - UART data register
        PORT 3 - UART control register

    If this is the case, I should be able to use the usual IN and
OUT instructions on the above numbers to get to them.  Can anybody confirm
this?

2.      Is TRANSMIT (both HDLC and SIO) polled, or interrupt driven?

------------------------------

Date: Thu, 21 Jun 90 18:10:24 PDT
From: "Roy Engehausen" <[e-mail]>
Subject: TCP/IP inhibitor
To: [e-mail]

Every week or so, I get asked when will my BBS program support TCPIP.
My answer is always the same: When someone packages TCPIP in a
Terminate and Stay Resident (TSR) program.

I don't want to write my own protocol handler and I don't think I want
to convert my 40K lines of Turbo Pascal into something I can use with
NOS.

If G8BPQ can do it for NETROM, I challenge the TCPIP promoters to
provide a similar program for TCPIP.  If one is available, I would
love to get a copy to try.

Roy, AA4RE

------------------------------

Date: 21 Jun 90 18:05:19 GMT
From: mcsun!goya!goya.dit.upm.es![e-mail]
Subject: TNC information request.
To: [e-mail]

I'm trying to send data over a terrestrial telephone mobile radio
network based on 460 Mhz carriers. I want to use the installed
radio equipment.

My first idea was to use CCITT (or BELL) analog voiceband modems.
I think the four wire standards may work well.

I think TNC's are a better solution, but I'm not familiar with
ham radio packets.

So I'm looking for pointers to information on how TNC works
and who sells them.

Thank you in advance,

Antonio
...................................................................
    ! o !        Antonio Martinez Mas
  --! !-!-       Departamento de Ingenieria de Sistemas Telematicos
 !  ! ! !        ETSI Telecomunicacion
 \_ ! ! !_       Ciudad Universitaria s/n 28040 MADRID; SPAIN
     U P M       tel.(..34-1)5495700 ext 367; fax.(..34-1)2432077
         email [e-mail]
...................................................................

------------------------------

Date: (null)
From: (null)
This is for starters; as I learn, more will probably follow.  I should
mention that I'm working strictly in assembly, to save space (I view
32K of assembly object as a challenge :-) )


Chris
--
Christopher E. Piggott, WZ2B                                (ex-N2JGW)
Computer Consoles, Inc. (an STC company)                 Rochester, NY
cs.rochester.edu!cci632!ccird7!cep  or  uunet!ccicpg!cci632!ccird7!cep

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat, 23 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #64
To: packet-radio


Packet-Radio Digest         Sat, 23 Jun 90       Volume 90 : Issue  64

Today's Topics:
         KA9Q NOS 900612 problems (& G1EMM) (2 msgs)
            Kiss Protocol Standard
             Looking for TNC-1's
            Network Models (long) (4 msgs)
            nos porting kit availibility?
            Parallel port vs SCSI (2 msgs)
            Seeking technical info: TNC-2
                 unsubscribe

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 22 Jun 90 17:07:17 GMT
From: bellcore-2!ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: KA9Q NOS 900612 problems (& G1EMM)
To: [e-mail]

For some reason, the version of asy_output() in 8250.c in NOS 900612
has the kick start code commented out. I probably did it in order to
test something, and then forgot to re-enable it before sending out
the distribution. If you're having transmitter constipation troubles,
all you have to do is to uncomment the two lines at the end of
that function and remake net.exe.  Sorry for the trouble.

Phil

------------------------------

Date: 23 Jun 90 00:21:56 GMT
From: bacchus.pa.dec.com!leftlane.ucs.dec.com![e-mail]  (Mark Curtis)
Subject: KA9Q NOS 900612 problems (& G1EMM)
To: [e-mail]

Has anyone else tried to compile the NOS code with the new Turbo C++?
If you have and somehow got a useable exe file let me know, because
I haven't been able to yet.

C++ has much more type checking and it will not compile at least 60%
of the code.  I have the 4/xx/90 version and after about 5 hours of
rearranging include statements so that it would compile without
fatal errors the exe that was built wouldn't work.  There were always
a great number of warnings with TC2.0, but no fatal errors and the
exe ran.  With C++ the number of warnings goes way up and about
6 out of 10 files contains a fatal error.  Most are due to include files
in the wrong order.  I don't know how it passed TC2.

Mark

------------------------------

Date: 23 Jun 90 04:53:10 GMT
From: maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]  (Steve Schallehn)
Subject: Kiss Protocol Standard
To: [e-mail]

After talking to Karl, WK5M, from Kantronics, I was told the KISS Protocol
standard could be found in:

6th Computer Networking Conference
KISS Protocol Standard
Redondo Beach, CA
PP. 38-43

As I understand it, ARRL should still have a copy of this.  However, does
anyone on the net happen to have an electronic version or a paper copy
that could be easily scanned?


-Steve Schallehn, KB0AGD
 Kansas State University ARC, W0QQQ

--
_____________________________________________________________________________
Steve Schallehn           | Internet : [e-mail]
Kansas State University   | UUCP : ..!rutgers!ksuvax1!ksuvm.bitnet!steve
Manhattan, Kansas 66506   | Bitnet   : STEVE@KSUVM

------------------------------

Date: 22 Jun 90 13:25:49 GMT
From: usc!cs.utexas.edu!helios![e-mail]  (William Gunshannon)
Subject: Looking for TNC-1's
To: [e-mail]

The Title pretty well sums it up.  Now that everyone is looking for the DE and
other faster systems, does anyone have any TNC-1's they want to get rid of
(hopefully cheap)??  I have something I would like to try but it requires a
TNC-1 (6800) and because it is all experimental anyway, I would just as soon
not have to mortgage the farm to try it out.
So anybody out there who has a couple of these beasties collecting dust that
wants to unload them, I'm interested.

Thanks in advance for any help.

bill gunshannon
[e-mail]
[e-mail]

------------------------------

Date: 22 Jun 90 16:38:59 GMT
From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Meahan) writes:
>I DON'T WANT NOS IN A C-64! (I don't even own one!)
>
>It seems that a lack of a smiley after the VIC-20 comment means that nobody
>caught that it was a wry/sarcastic remark!
>
>What I DO think is necessary, as other posters have implied, is that there
>be some sort of GATEWAY such that those who are STUCK with the (fill in
>your favorite bitty box) can make USE of the more sophisticated features
>provided by NOS/NET while the sophisticated stuff is running on some
>far more powerful server.
>
>Think of KISS turned upside down - a client node runs a SIMPLE protocol
>that allows it to connect with the server and maintain multiple connections
>(Please not AX.25!).  The server takes the commands/data from the client node
>and processes them, wrapping the appropriate IP headers around them if
>necessary and forwarding them on via the well-connected IP network.  Returned
>stuff gets unwrapped and returned to the client node using the SIMPLE protocol.
>
>A bit of malice aforethought could result in a fairly efficient point-to-
>point service that WOULD fit in a bitty box - after all, it doesn't NEED
>to worry about more than ONE route/connection!
>
>Is my point a little clearer?  Do you catch my contention that it is NOT
>necessary for ALL hams to run a FULL implementation of NET/NOS in order
>to USE them?
>
>After all, I'm writing this on a PC attached to a (large) UNIX box.  By
>comparison, the PC is a bitty box.  But who cares?  By terminal connect
>I am able to make full use of the capabilities of my UNIX system without
>having to run full UNIX on my PC.
>
>Let me rephrase my proposal like this:  Let's develop software for
>USER INTERFACES that will run happily on bitty boxes and can connect
>cleanly and efficiently with ONE server (at a time).  Let the server
>be whatever the server provider (individual or club) can afford and let
>it run the most sophisticated NOS Phil and the rest can possibly develop.
>By doing such, by allowing USERS to get by with simple equipment, we can
>reach out to include a far greater number of hams in the digital network
>of the future.
>
Our users already have login access to three Unix boxes here in Atlanta.
But it isn't very practical to be a remote user of a Unix system when
your net thruput is ~150 baud. With one of our 56k links it is pleasant
to login and use your Unix account, but to run 56k right now you need
a PC equivalent and NOS to keep up with the digital bits. So even with
the big powerful server you need a PC level bitty box AND a fast RF modem.

You don't know what pain and frustration are until you try to use a
simplex 1200 baud packet channel in a busy metropolitan area for
interactive work. With 150 active users, mostly hidden terminals, and
two BBS systems, you are lucky to get 80 characters a MINUTE net thruput.

The reality is that on a contention channel with modest TNC level baudrates,
you don't want to do much interactive work with a big server. What you
need to do is start a client process such as ftp or smtp on your local
box and let it patiently deal with the slow channel and alert you when
it's done. THIS IS WHAT NOS DOES! AND you aren't limited to interacting
with a few big servers. You have file transfer access and mail delivery
service directly to ALL those other bitty boxes out there.

NOS is not rocket science, we have retired PR types who don't know a bit
from a byte who happily run NOS as USERS. Sure, at the present state of
development of the package, it takes a little coaching from an experienced
user to get them started, but it isn't HARD to use.

To sum up, I think your mental MODEL of packet radio is wrong. With slow
channels likely to be with us for the forseeable future, at least for casual
users, the idea of INTERACTIVE packet is unworkable. NOS gives us the
option of requesting a service from a remote machine by making a request
on our local machine, then going away and doing something else until our
requested service is completed. Sure, there is plenty of work left to be
done on the package, but it is usable right now.

Gary KE4ZV

>"stupid cat" is unnecessarily redundant
***MINI-FLAME***
Cats are smarter than people. They get us to feed them and clean their
litter boxes don't they? You've never seen a cat work eight hours a
day to feed his person have you? :-)

------------------------------

Date: 22 Jun 90 16:56:36 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Network Models (long)
To: [e-mail]

>It would be tough to have multilple session telnets, ftp's and a bbs,
>but it is time someone wrote at least a client for it.  ( Not me - I am too
>busy writing PC code for NOS).  The point is,  I bet alot of people would like
>to do it, but would feel stupid about it.  Frankly, if someone comes up with
>a telnet or ftp client, Ill pull mine out of the closet.  Be sure to make it
>compatible with Digicomm.

I believe that the real problem is that most folks who would be willing and
able to do this are in fact off writing code for something else now... but I
too would love to see someone take and do this... it would certainly squelch
an amazing amount of noise on the subject...

Bdale

------------------------------

Date: 22 Jun 90 16:55:02 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Network Models (long)
To: [e-mail]

>What I DO think is necessary, as other posters have implied, is that there
>be some sort of GATEWAY such that those who are STUCK with the (fill in
>your favorite bitty box) can make USE of the more sophisticated features
>provided by NOS/NET while the sophisticated stuff is running on some
>far more powerful server.

It exists today.  Run a copy of NOS on a PC somewhere in your area, and turn
on the "AX.25 Mailbox" functionality.  Other folks can AX.25 connect to the
machine and have access to a fairly rich subset of the available functionality.

We're going to make it even easier with NOSINABOX.

>Let me rephrase my proposal like this:  Let's develop software for
>USER INTERFACES that will run happily on bitty boxes and can connect
>cleanly and efficiently with ONE server (at a time).

There's nothing to develop.  Unless you have an especially rabid opinion of
AX.25 (most of us don't), you might as well use it as the user connection
mechanism because it exists, and you don't have to write any code to use it,
and all the TNC toting hams of the world will still be unhappy if you don't
use it.  Right?

>"stupid cat" is unnecessarily redundant

I ought to resent that... but I'll leave it alone... I *like* my cats, and
they are far from stupid!  :-)

Bdale

------------------------------

Date: 22 Jun 90 16:50:17 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Network Models (long)
To: [e-mail]

>The Data Engine turned out to not be what I had
>expected, though, and I see it as a neat toy but not particularly
>useful to most people.  From the marketing/promotional standpoint
>(and for the good of ham radio), I would have prefered to see the
>next generation of TNC2 come out; something on the order of an 8086-
>based TNC-2 with more memory.  This wouldn't have driven the price up
>very much (8086's and 8088's are cheap; even better, NEC V-20!!!)
>and memory is not THAT unreasonable.  This would have several
>BIG advantages:

That's what a DE *is*, at least to me... a faster TNC with a V40 engine, which
is just a V20 with onboard stuff like DMA and serial ports and interrupt
controllers, which you'd want anyway.  What were you expecting, and have you
looked at a DE up close and personal?

>       - be able to develop software in a native environment,
>               rather than using cross-development tools.

For the DE, I'm using Turbo C 2.0 on an AT clone, and a toolset from Paradigm
that allows easy .EXE and .MAP -> ROM image.  Others have been downloading
code over the serial port using a debug monitor thingy on the DE and PS-186.
It's really pretty easy.

>       - make it perfectly reasonable to implement higher-level
>               protocols with very little work, e.g. how about a
>               partial nos-in-a-box that Joe User can use with
>               a dumb terminal ?

That's one of the things you'll get when my code is done.  I'm not sure why
anyone would buy one for that, when for the price of a DE they can have most
of a 640k XT clone with floppy, which is a better base for the future, but...

>Comments?

I always have some...  :-)

Bdale

------------------------------

Date: 21 Jun 90 19:15:00 GMT
From: sun-barr!newstop!texsun!texbell!merch!cpe!techsup![e-mail]
Subject: nos porting kit availibility?
To: [e-mail]

...
i remember seeing mention of a kit to help port nos to xenix/unix
systems.  is this kit available for uucp or download from
anywhere?  i don't have ftp ability.

thanks in advance,

ken brookner, n5lpi
[e-mail]
...!texbell!techsup!kenb

------------------------------

Date: 22 Jun 90 19:41:26 GMT
From: eagle![e-mail]  (Jim McKim)
Subject: Parallel port vs SCSI
To: [e-mail]

In article <[e-mail]> [e-mail] (John G. DeArmond) writes:
>[e-mail] (Johnathan Vail) writes:
>
>>I like the SCSI idea.  Sign me up for several!  I can use it on my Sun
>>3/60 and since we are using SCSI here I may have a line on surplus
>>equipment to use.  The paralell port may have some value as far as PCs
>>are concerened but really loses in high speed applications because of
>>the lack of DMA.  If you have to babysit an 8 bit port you may as well
>>just run an 8530 or some serial port directly.
>
>As someone who as suffered through a couple of years' worth of SCSI
>non-standard hardware and software, I must ask the question of whether
>you've ever really dealt with SCSI at other than a user level.  I'm
>not trying to be combative but SCSI as it exists today is quite simply
>a mess.

I disagree.  We have been using SCSI-1 for several years here as
an inter-processor communications medium for embedded multiple
processor systems.  Most of the few problems I have encountered
originate from poor documentation from third parties whose devices
we use.  We have had few problems with SCSI itself; the medium works
well (once we got the bugs out of our own drivers).  The quality of
SCSI [target] firmware has improved as SCSI peripherals have become
more commonplace.

>         If this fellow did build a board that talked SCSI, hung it
>on an SCSI bus with other devices and tried to run it, I'd bet even
>money that either his card or some other device on the bus would
>malfuction.  Especially if he writes the driver according to published
>specifications instead of reverse engineering the bus with a logic
>analyzer.

Yes - an analyzer is helpful if you are working with some of the
older controllers.  However, since the bus is static - you can single
step your way through a transaction and do your debugging with something
as simple as a DVM.

>If you suggest that one simply install another SCSI interface card,
>then the question begs, why bother.  Why not keep it simple and plug
>a parallel port card in?

Expandability - if my system is limited to 'x' parallel channels,
I don't want be limited to 'x' peripherals (especially if x==0 - there
are some computers that don't have parallel ports).  I would rather
not see a proliferation of add-on devices that use a parallel
port hack for their I/O.

>                          Unless you get a SCSI host adaptor card
>capable of bus mastering in a PC, DMA is pretty much a waste.  Remember
>that to stuff 56kb/second in/out the port only requires 7kbytes/second - a
>fairly trivial task.

This does not resolve the bottleneck - without DMA, the fastest rate
the computer can process information is limited to the rate of that
_single_ channel.  Also - multiple thread programs really lose
because they can't do anything else while coddling that channel.
I've done unix parallel port drivers - substantial amounts of parallel
port I/O degrades performance.

>                      If we're talking anything much faster than 56k,
>we really should be looking at intelligent cards with dual-ported RAM
>in order to off-load the processor.

Intelligent cards are expensive.  You don't need dual port ram unless
you are talking megabytes per second - anyways it is of limited use on
PCs because of the slow (PC) bus speed.

>Once we begin to talk more than about a hundred bux or so, we really need
>to look at ethernet adaptors.   Remember what the original objective of the
>discussion was - to provide something cheap capable of being use by Joe
>EveryHam at moderate speeds.
>
>Perhaps the thing to do is to build a protocol converter that has
>a thinnet port on one side and a sync port on the other.

I guess we are talking about making a tradeoff decision here.  On the
one hand, parallel ports are easier to program, cheaper, often available
on the most popular computers used today.  They also have the non-DMA
I/O bottleneck and limited expandability.

On the other hand, SCSI is more expensive, it needs more complicated
software drivers, but it offers greater flexability in terms of how it
impacts system performance and in how it can be expanded.
--
----------------
Jim McKim  /  Internet: [e-mail]             "" -
Phone: [phone]  /  Packet: [e-mail]       Needermeyer
----------------

------------------------------

Date: 22 Jun 90 17:02:45 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Parallel port vs SCSI
To: [e-mail]

>If you suggest that one simply install another SCSI interface card,
>then the question begs, why bother.  Why not keep it simple and plug
>a parallel port card in?  Unless you get a SCSI host adaptor card
>capable of bus mastering in a PC, DMA is pretty much a waste.  Remember
>that to stuff 56kb/second in/out the port only requires 7kbytes/second - a
>fairly trivial task.  If we're talking anything much faster than 56k,
>we really should be looking at intelligent cards with dual-ported RAM
>in order to off-load the processor.

I contend that if you're talking about a PC/XT/AT at all, you ought to be
talking about an intelligent plug-in card... or at least a dumb plug-in card.

To me, at least, the niche that exists unfilled is for a standalone product
that is targetted to work with all the non-PC machines out there.  The Macs,
Amigas, Atari ST's, workstations, etc.  For all that stuff, the right answer
is SCSI, and even if you have to pull out a logic analyzer and reverse
engineer the cable, it still isn't that hard.

>Once we begin to talk more than about a hundred bux or so, we really need
>to look at ethernet adaptors.   Remember what the original objective of the
>discussion was - to provide something cheap capable of being use by Joe
>EveryHam at moderate speeds.

Then for a PC it ought to be a plug-in card.  There's no cheaper way to do it.
You get to steal power and cabinetry from the PC.  You don't have the interface
problem, etc...

>Perhaps the thing to do is to build a protocol converter that has
>a thinnet port on one side and a sync port on the other.

This would work great for some of us, but I think would miss the point for a
lot of other folks...  they don't have thinnet either...

Bdale

------------------------------

Date: 22 Jun 90 17:04:37 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Seeking technical info: TNC-2
To: [e-mail]

>I have not been able to find much useful information on TNC-2's.
>At least, not information which is on the level I seek.

Dig up a copy of the KA9Q distribution, and unpack the TNC_TNC2.ARC archive.
It contains, among other things, the full source to a rev of K3MC's KISS for
the TNC2.  It's written in assembler, and has all the info you need embedded
in the comments and defines.

If you can't find it, email me and I'll send you the source.

Bdale

------------------------------

Date: Fri, 22 Jun 90 08:53 CDT
From: <[e-mail]>
Subject: unsubscribe
To: [e-mail]

unsubscribe

------------------------------

End of Packet-Radio Digest
******************************
Date: Sun, 24 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #65
To: packet-radio


Packet-Radio Digest         Sun, 24 Jun 90       Volume 90 : Issue  65

Today's Topics:
                Amiga TCP SLIP

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 24 Jun 90 05:27:54 GMT
From: usc!samsung!umich!umeecs!dip.eecs.umich.edu![e-mail]  (Ralph Seguin)
Subject: Amiga TCP SLIP
To: [e-mail]

Hi.  Does anybody know where I can obtain the latest version of Amiga
TCP for SLIP?  I have an old version that has no documentation whatsoever.
I have no idea how to go about using it with my modem.  Any help
would be appreciated.  Where can I obtain docs?  Where can I obtain
info on TCP/IP?  How do you dial through the modem using TCP?
Many more questions that I cannot remember.

            Thanks, Ralph


[e-mail]       [e-mail]
[e-mail]     [e-mail]
[e-mail]    [e-mail]

Ralph Seguin               |  In order to get infinitely many monkeys to type
565 South Zeeb Rd.         | something that actually makes sense, you need to
Ann Arbor, MI 48103        | have infinitely many monkey editors as well.
[phone]

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon, 25 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #66
To: packet-radio


Packet-Radio Digest         Mon, 25 Jun 90       Volume 90 : Issue  66

Today's Topics:
              Azden m3000>PK232
             concerns over TCP/IP
            Network Models (long)
                  NOS & SLIP

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 24 Jun 90 23:17:27 GMT
From: bacchus.pa.dec.com!shlump.nac.dec.com!e2big!anarky.enet.dec.com![e-mail]  (John Brewer)
Subject: Azden m3000>PK232
To: [e-mail]

    I have a friend that is looking for information on connecting
an Azden m3000 to a PK232 for packet. While I'm sure that with
enough muddling, we could get it to sing, there are two reasons
for asking the net before warming up the iron...(pencil?)
    1) The radio is not mine...
    2) He had heard that some Azden radios were particularly
    sensitive to misapplication of PTT/MIC signals (not much
    buffering between PTT in, and uP goes the story).

    Can someone help us out, or point me to the correct CQ
mag issue if you happen to have performed this operation?
    73/john wb5oau



+----------------------------------------------------------------+
|John Brewer    WB5OAU           |      [e-mail]  |
|Digital Equipment Corporation   |      [e-mail]    |
|Albuquerque NM                  |      WB5OAU@KN5D              |
+----------------------------------------------------------------+

------------------------------

Date: 23 Jun 90 02:15:33 GMT
From: swrinde!zaphod.mps.ohio-state.edu!mips!twg.com![e-mail]  (David S. Herron)
Subject: concerns over TCP/IP
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil Karn) writes:
>In article <[e-mail]> [e-mail] (Christopher Piggott - co-op) writes:
>>The static inertia of society is tremendous, and it is no better in
>>many parts of the ham-radio community.  Here are a few other pieces
>>of resistance I have personally encountered:
>
>[long list of unbelievably brain-damaged excuses deleted for brevity...]
>
>Now you see one of the reasons I'm so strongly in favor of a no-code license
>that would attract more technically oriented people to the service.

Here is one technically oriented person who would love to be doing
packet radio but who doesn't have time/interest in learning code.

I don't see why code is *necessary* anymore.  I can see an argument
that in an emergency situation that if you were having to cobble
a radio out of spare parts it might be easier to build one for code
than one for voice.  But, as I'm remembering the circuitry, adding
voice to a radio is simply

    microphone -> amplifier
and
    amplifier -> speaker

Both of which are available in plentiful supply.  How many people
have old cassette tape recorders sitting around?  I know I do..


The argument that it's a hurdle to keep out the dweebs is interesting.
But since it keeps me out too.. I don't like it. :-)
--
<- David Herron, an MMDF weenie, <[e-mail]>
<- Formerly: David Herron -- NonResident E-Mail Hack <[e-mail]>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!

------------------------------

Date: 24 Jun 90 21:52:00 GMT
From: [e-mail]  (Patty Winter)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Bdale Garbee) writes:
>>What I DO think is necessary, as other posters have implied, is that there
>>be some sort of GATEWAY such that those who are STUCK with the (fill in
>>your favorite bitty box) can make USE of the more sophisticated features
>>provided by NOS/NET while the sophisticated stuff is running on some
>>far more powerful server.
>
>It exists today.  Run a copy of NOS on a PC somewhere in your area, and turn
>on the "AX.25 Mailbox" functionality.  Other folks can AX.25 connect to the
>machine and have access to a fairly rich subset of the available functionality.

Sigh. This is probably a Good Thing for introducing AX.25 users to the
extended features available through TCP/IP, but it doesn't exactly help
the channel-access situation for those of us trying to use TCP on the
channel at the same time.

Yesterday I hooked up my packet station for the first time in months to
hand out some Field Day contacts. I wandered over to the TCP channel,
saw a couple of new users, and decided to look them up in the N6OYU
callsign server. So I initiated a finger command to Doug's machine, and
very quickly realized that I was getting blown out of the water by someone
on channel who had an AX.25 connection going to an AX.25/TCP mailbox. TCP
being as gracious as it is, and AX.25 being so aggressive, the interval
between successive packets coming to me kept getting longer and longer
and...until I finally reset the socket and went back to FD stuff.

I don't know what the moral of this story is. Maybe that (as is true with
Mike Chepponis' system) the AX.25 half of the mailbox should be on another
frequency. I like the idea of giving AX.25 users a peek at TCP/IP. I don't
care for the idea of our assigned channel getting filled up with AX.25
packets.


Patty

--
*****************************************************************************
Patty Winter N6BIS                        INTERNET: [e-mail]
AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
*****************************************************************************

------------------------------

Date: 24 Jun 90 23:23:08 GMT
From: sun-barr!newstop!texsun!texbell!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: NOS & SLIP
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil Karn) writes:
>Standard SLIP requires no handshaking lines at all; just three wires will do
>(gnd, tx data, rx data). The recent version of NOS includes a contribution
>that supports optional RTS/CTS handshaking; that's what the mention of "CTS
>ints" in the asy stat command refers to.  Check the docs and the source for
>the details of how this operates; I haven't actually used this feature
>myself.

...and three wires are all I use on my Data General/One. In fact, I had to
rip out all the CTS code the last time I retrofitted my DG/1 serial driver
into Phil's code, since only one of the DG/1's two serial ports has CTS
even wired up, and the internal modem doesn't implement it either. I haven't
noticed the loss.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
[e-mail]       (eieio)| adequately be explained by stupidity.
"I don't usually do vicious;        +----------------------------------------
 I try to stick to depressing." -- Janis Ian, in concert, 6/6/90

------------------------------

End of Packet-Radio Digest
******************************
Date: Tue, 26 Jun 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #67
To: packet-radio


Packet-Radio Digest         Tue, 26 Jun 90       Volume 90 : Issue  67

Today's Topics:
        KA9Q package for Atari ST availability
            Network Models (long)
            Parallel port vs SCSI (3 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 22 Jun 90 15:11:56 GMT
From: crash!simpact!hamavnet![e-mail]
Subject: KA9Q package for Atari ST availability
To: [e-mail]

Hello there,

I am looking for a land line BBS that I can download the KA9Q package for the
Atari ST.

I already tried Delphi and Compuserve, but it is not there.

Thanks,

Javier Henderson     | [e-mail]           | These opinions
Engineering Services | Ham Packet: N6VBG @ KD7XG-1      | are all mine.
Hamilton Avnet       | WWIVNet: 1@2397                  |

------------------------------

Date: 25 Jun 90 06:17:16 GMT
From: sdd.hp.com!elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]  (Mike Curtis, ax.25 wd6ehr@k6iyk [phone])
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Meahan) writes:
>In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>>In article <[e-mail]> [e-mail] (Bill
>>Meahan) writes:
>>>Believe it or not, there are actually hams who regard amateur radio as a
>>>HOBBY and not as a second career.  These people should not be locked out
>>>of the future simply because they're not workaholics or lack the technical
>>>expertise to develop an IP-compliant cilent that runs on a VIC-20.
>>
>>So what are you saying? Should code developers abandon a minimally adequate
>
>[flame deleted]
>
>You miss the point entirely:
>
>The TCP/IP crowd as represented in this newsgroup seems to be rapidly becoming
>a group whose credo could be: "Subscribe to exactly MY model of what amateur
>radio should be, or go to hell."  This attitude isn't new or restricted to
>any one group - it's been a major part of ham radio for the entire 25 years I've
>held my license and has been expressed by the homebrewers, the traffic fanatics,
>the public service enthusiasts etc. etc. etc.>

We're a very homogenous aggregation of quite singular interest groups.

Why do some carp about perceived deficiencies, but aren't willing
to WRITE the ferschluginner software for their obsolete machines?

If you like running AM on a 6V6 pierce oscillator on 75 meters,
that's very well and good.  But don't expect me to design and build
that antique for you.

I have an Olivetti M-10 (TRS100 clone), with 32K RAM and NO drive; this
is an obsolete machine.  I wanted to run a small forwarding w0rli-compat
PBBS on it, so I learned microsoft basic, took a copy of Dick N1AED's
miniPBBS for the TRS100, picked many brains for w0rli forwarding information,
and modified the progam.  Yes, it took a lot of time, but I wanted it bad
enough to shut up and do something about it!

Please realize that the insistence on state of the art on obsolete machines
is holding back the development of amateur radio.  We're about 15 years
retarded.

CASE IN POINT: DIGICOM

Have you ever seen DIGICOM?  It's a truly marvelous package for the C-64,
which software emulates a TNC, terminal, conference bridge, file server,
etc.  All you need is DIGICOM software, a C-64, and a modem board for a
truly state of the art ax.25 packet machine.

And _that's_ exactly my point!!!  State of the art packet runs on a
machine that's been dead meat on ice for 10 years!!!

How will we ever get 9600 baud networks, 56 kB, T-1, etc., when packet
state of the art runs on a machine that limps at 1200 baud?  C'mon, guys.
Grow up!  Put your little playtoys in the attic where they belong!  Or at
least don't come crying because your TRS80 model 1 with 4K and level 1
basic won't run /ip.

>                   .........By EXPANDING the
>vision and developing such things as a restricted telnet client that CAN run
>on, say, a C-64 so that the interested ham can log in to a well-connected
>server and read the news, send some mail, read some other mail, establish
>a telnet link to someone else, etc.

Delete "telnet", tie in some PBBS's to USENET feeds, and you have ax.25 packet.

What if we insisted that Model T's be accommodated in the Indy 500?

>What has the hobby got to lose be becoming more INCLUSIVE instead of more
>EXCLUSIVE?  Why is the only 'acceptable' newcomer a network engineer?

Owning a $300 XT-compat makes one a network engineer?  Eureka!

If you want to play hardball baseball, you need a glove and bat.
With only 64K RAM and a wimpy operating system, the kiddie computers
would of necessity be much more complicated to use for something as
demanding of speed and memory as /ip.
>
>Why should amateur radio, which historically has been an innovator, be
>stuck FOLLOWING technology instead of LEADING it?

Because everyone wants to use technology of 15 years ago.  How can we
lead when state of the art in ham radio is Z-80 and C-64?

>...either happily connect dumb terminals to the server via telnet, or gateway
>SLIP connections if the attached devices has any brains at all.  Why can't
>amatuer packet be as accomodating?

But it IS - all you need is a dumb terminal and TNC, and plug in your
radio, then beg for help, because ax.25 1200 baud AFSK packet is a very
poor, difficult way to do things!  That's what you get when you settle
for inferior equipment because it interfaces with the cheap, existing,
and convenient junk laying aroud the shack.

Whatever happened to our tradition  of building, fixing, and modifying?
I suppose it's gone the way of the dodo, and the work ethic........
Everyone wants something for nothing, right now.

73, Mike wd6ehr@k6iyk

------------------------------

Date: 25 Jun 90 14:45:28 GMT
From: wang!tegra![e-mail]  (Johnathan Vail)
Subject: Parallel port vs SCSI
To: [e-mail]

In article <[e-mail]> [e-mail] (John G. DeArmond) writes:

   As someone who as suffered through a couple of years' worth of SCSI
   non-standard hardware and software, I must ack the question of whether
   you've ever really dealt with SCSI at other than a user level.  I'm

No, not yet.  I am doing that now, writing the drivers for our real
time unix as we switch to SCSI.  That is one reason why the idea
appeals to me.  I have access to different equipment that can talk
scsi.

   Once we begin to talk more than about a hundred bux or so, we really need
   to look at ethernet adaptors.   Remember what the original objective of the
   discussion was - to provide something cheap capable of being use by Joe
   EveryHam at moderate speeds.

Yes, I was thinking in terms of myself, rather than a cheap plug-and-
play for Joe Ham.  He is going to need something cheaper and easier
than SCSI.  I liked SCSI because the same interface can exist on
several non-blue-pc platforms as a standard interface (as far as that
goes...).

As for using a paralell printer interface, that is a great way to go
for a cheap and easy interface for PC and clones.  One possible
drawback is, I believe, that the paralell port on PCs is an exception
in that it is bi-directional.  Do other computers using paralell
printer ports have the ability to go both ways?

73s, one and all

Law of Stolen Flight: Only flame, and things with wings.
              All the rest suffer stings.
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

------------------------------

Date: 25 Jun 90 17:43:13 GMT
From: usc!cs.utexas.edu!mailrus!b-tech![e-mail]  (Jon Zeeff)
Subject: Parallel port vs SCSI
To: [e-mail]

>play for Joe Ham.  He is going to need something cheaper and easier
>than SCSI.  I liked SCSI because the same interface can exist on

You can get the Seagate scsi adapter for a PC for < $50.  I say go with
scsi - using a parallel port is so non standard and so CPU intensive.


--
Jon Zeeff (NIC handle JZ)        [e-mail]

------------------------------

Date: 25 Jun 90 19:02:09 GMT
From: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!pmsmam![e-mail]  (Bill Meahan)
Subject: Parallel port vs SCSI
To: [e-mail]

In article <[e-mail]> [e-mail] (Johnathan Vail) writes:
>In article <[e-mail]> [e-mail] (John G. DeArmond) writes:
>
[stuff deleted]
>
>As for using a paralell printer interface, that is a great way to go
>for a cheap and easy interface for PC and clones.  One possible
>drawback is, I believe, that the paralell port on PCs is an exception
>in that it is bi-directional.  Do other computers using paralell
>printer ports have the ability to go both ways?
>
>73s, one and all
>
>Law of Stolen Flight: Only flame, and things with wings.
>                      All the rest suffer stings.
> _____
>|     | Johnathan Vail | [e-mail]
>|Tegra| [phone] | N1DXG@448.625-(WorldNet)
> -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

The Atari ST port is also bi-directional.
--
Bill Meahan  WA8TZG             uunet!mailrus!umich!pmsmam!wwm
I don't speak for Ford - the PR department does that!

"stupid cat" is unnecessarily redundant

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed, 27 Jun 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #68
To: packet-radio


Packet-Radio Digest         Wed, 27 Jun 90       Volume 90 : Issue  68

Today's Topics:
            Kiss Protocol Standard
             Looking for TNC-1's
            Network Models (long) (2 msgs)
            SCSI Support For NET (2 msgs)
              SCSI TNC Comments (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 25 Jun 90 22:40:24 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Kiss Protocol Standard
To: [e-mail]

>As I understand it, ARRL should still have a copy of this.  However, does
>anyone on the net happen to have an electronic version or a paper copy
>that could be easily scanned?

This gets asked over and over again... the USERMAN document for the 890421.1
release of the KA9Q package has the full KISS spec as an appendix.  This
document is available for FTP from a variety of places, including my machine
col.hp.com, in ka9q/890421.1/userman.arc.

Bdale

------------------------------

Date: 25 Jun 90 22:38:54 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Looking for TNC-1's
To: [e-mail]

>I have something I would like to try but it requires a
>TNC-1 (6800) and because it is all experimental anyway, I would just as soon
>not have to mortgage the farm to try it out.

The TNC-1 is actually a 6809...

I have a Heath 4040 in use that I might be convinced to let go of.  I'm off to
Europe tomorrow for 3 weeks, if you don't find one by 17 July send me email...

Bdale

------------------------------

Date: 25 Jun 90 22:37:21 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Network Models (long)
To: [e-mail]

>>It exists today.  Run a copy of NOS on a PC somewhere in your area, and turn
>>on the "AX.25 Mailbox" functionality.  Other folks can AX.25 connect to the
>>machine and have access to a fairly rich subset of the available functionality
>
>Sigh. This is probably a Good Thing for introducing AX.25 users to the
>extended features available through TCP/IP, but it doesn't exactly help
>the channel-access situation for those of us trying to use TCP on the
>channel at the same time.

Ooops... sorry Patty, I would *never* suggest operating IP and raw AX.25 on
the same channel when you have a choice in the matter.  I have discovered,
however, that with judicious selection of slottime (longer than dwait used by
the AX.25 guys), and P (on the order of 1/8 or less), that you can coexist
fairly well with AX.25 (ab)users.

>I don't know what the moral of this story is. Maybe that (as is true with
>Mike Chepponis' system) the AX.25 half of the mailbox should be on another
>frequency. I like the idea of giving AX.25 users a peek at TCP/IP. I don't
>care for the idea of our assigned channel getting filled up with AX.25
>packets.

I understand.  It's got to be a local issue.  The point I really wanted to make
was that you could put a PC at a multi-port switch site *today* and get the
desired functionality, regardless of what services you assign to what channels.
NOSINABOX will be at first nothing more than an EPROM'ed rendition of this for
some hardware a little more directly suited to the environment in question...

Bdale

------------------------------

Date: 26 Jun 90 17:14:05 GMT
From: van-bc!ubc-cs!alberta!atha![e-mail]  (Richard Loken)
Subject: Network Models (long)
To: [e-mail]

[e-mail] (Mike Curtis, ax.25 wd6ehr@k6iyk [phone]) writes:

>In article <[e-mail]> [e-mail] (Bill Meahan) writes:
>>In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>>>In article <[e-mail]> [e-mail] (Bill
>>>Meahan) writes:

>Whatever happened to our tradition  of building, fixing, and modifying?
>I suppose it's gone the way of the dodo, and the work ethic........
>Everyone wants something for nothing, right now.

>73, Mike wd6ehr@k6iyk

What does buying a Taiwanese XT clone and downloading Phil's gift wrapped
software have to do with building, fixing, and modifying?  That is just as
much appliance operating as an Icom, a microphone, and a triband beam.

The holy wars have moved to packet so soon?  The only place with any peace is
CW, abuse in morse is such hard work.


--
  Richard Loken VE6BSV                             :  see I took it out!
  Athabasca University                             :  I can't afford Campy
  Athabasca, Alberta Canada                        :  anyhow.
  [e-mail] {alberta|decwrl}!atha!tech :

------------------------------

Date: Tue, 26 Jun 90 11:10:56 EST
From: [e-mail]
Subject: SCSI Support For NET
To: [e-mail]

  As long as the debate is going I may as well throw in my 2 cents worth
on the suitability of SCSI as an interface for NET.
I'm running NET on a Mac+ and other then the serial port which runs at a
maximum of 57.6k baud, the ONLY other interface port I have is a SCSI port.
It sure would be nice to use it for a network connection..
Furthermore, Don Lemley of Grace communications (Packet Ten fame) is
*rumored* to be considering a SCSI interface for his Really Awesome I/O
board.
I understand that IBM now officially endorses SCSI as an interface standard
for IBM pc's. Undoubtedly due to the popularity of SCSI for interfacing
CD-ROM players to thier equipment.
Phil's philosophy has been "to use standards where standards exist" lets
not get TOO excited about about using a MOSTLY bi-directional printer port
for networking when a ubiquitous standard already exists!
--dy
Doug Yuill, [e-mail] or [e-mail]

------------------------------

Date: 26 Jun 90 22:03:24 GMT
From: portal!cup.portal.com![e-mail]
Subject: SCSI Support For NET
To: [e-mail]

I'm planning to build a SCSI card for my computer, and since everyone is
talking SCSI, perhaps someone would enlight me on selecting the right
SCSI chip to use.  I have Fujitsu MB87030, National Semi 5380 and
8490 spec sheets but I wonder which to use.  I know that the 8490 and MB87030
can handle to up 4Mbytes/sec transfer, but which chip is easier to program
and which is easier to interface to differential SCSI bus.

John

------------------------------

Date: 26 Jun 90 17:52:39 GMT
From: usc!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!cygnus.la.locus.com![e-mail]  (Dana H. Myers)
Subject: SCSI TNC Comments
To: [e-mail]

Hi guys, it is nice to be back. It was hot and humid in Mississippi (as I
expected), and it is nice to be back to the dry heat of LA :-)

  Also, I see that I started a little flurry of mail about SCSI vs.
parallel ports as high-speed TNC ports. I'd like to respond to a few
general points.

1. Several submitters nattered on about "my XT clone this" and "my
   XT clone that". Get a grip. My original submissions clearly pointed
   out that I am not worried about the lowest cost XT/AT solution. Go
   by a plug-in card like the Eagle or DRSI or Paccom.

2. Other submitters said "Why worry about those workstations, anyway?
   No one uses them.". Well, shucks, tell that to Sun and Atari and
   Commodore. Once again, GET A GRIP.

3. The use of the XT parallel port as a bi-dir port is a non-issue as
   far as I'm concerned, see #1 above (you can buy a plug-in card).

4. This is not an either-or situation. In fact, I plan to test the
   SDLC/CPU part using the bi-dir PS/2 port before I ever use SCSI.
   So, stop the "I want this vs. I want that" crap. What a bunch of
   complainers. A PS/2 only version would address the 3 million MCA
   (Micro-Channel Arch) machines out there without requiring the
   construction of a new MCA board (a project in itself with the POS,
   etc.), and the parallel i/f would be quite simple.

  Summary of above points: Lighten up, GET A GRIP, cool your jets, man.
    If the SCSI idea doesn't apply to you, then don't natter on.

5. A couple of submitters questioned the feasibility of actually using
   a SCSI i/f. These guys are informed and experienced, from what I can
   tell. The concerns are valid. I've been considering the Adaptec Nodem
   as a model of a SCSI communications device. These things are Ethernet to]
   SCSI adaptors, and they appear to work. I'm running with the assumption
   the idea is feasible.

6. I plan to use a purpose built SCSI i/f chip, which integrates the
   drivers, etc. required. This may change... I'm always open to good
   input (but I hate nattering and complaining without solutions).

7. My personal SCSI experience is limited to the IBM adaptors (MCA
   bus masters) and the AIX-PS/2 driver. The driver was written and
   supplied from inside IBM, but I spent much time in contact with the
   author of the driver.  I regard his expert input quite highly and
   he has been quite helpful on details of a SCSI attached communications
   device (he has interfaced the Adaptec Nodem, for instance).

8. This is clearly a case of where I've decided a needs exists and plan
   to fill it by learning what I must to build the SCSI i/f.

  So! I want to start building the prototypes this weekend. I do,
however need to get the Adaptec and Emulex data books for the SCSI
chips. If anyone has actual experience designing with these parts,
I'd like to hear about them (no nattering about "my Maxtor drive has the
Emulex part and it only seeks at 28 mS").

  Thanks to the folks offering constructive input. I hope the moaners,
complainers and pickers will GET A DAMN GRIP and wait until they have
something useful to offer before shooting off flaming know-it-all
messages. Afterall, I'm spending my own time and my own money on this.


73s
Dana
*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

Date: 27 Jun 90 03:06:51 GMT
From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mephisto!emory!rsiatl![e-mail]  (John G. DeArmond)
Subject: SCSI TNC Comments
To: [e-mail]

[e-mail] (Dana H. Myers) writes:

Gee, Dana, I thought when you posted your original query, you were
interested in gaining the benefit of those of us with some experience
in the subject matter.  I did not realize you had alread made your mind
up or I would not have wasted my time "complaining".  I'd invite you
to "get a grip."  Let's look at a couple of items.


>1. Several submitters nattered on about "my XT clone this" and "my
>   XT clone that". Get a grip. My original submissions clearly pointed
>   out that I am not worried about the lowest cost XT/AT solution. Go
>   by a plug-in card like the Eagle or DRSI or Paccom.

>2. Other submitters said "Why worry about those workstations, anyway?
>   No one uses them.". Well, shucks, tell that to Sun and Atari and
>   Commodore. Once again, GET A GRIP.

First, let's establish that 56k technology is at best, medium speed
networking.  It is certainly not "high speed" except in the context
of 1200 bps Bell 202 operation.

The reason you got the responses relative to PC architecture machinery
is that PCs are the overwhelming choice for amateur packet.  Yes, there
are 5 or 6 workstations out there (Atari?  Really? :-) but for medium
speed networking, the PC is the obvious choice.

If we're talking about those machismo, testesterone-loaded, manly workstations
some of us get to play with at work or school, then my question is, why
bother?  (I'll be posting some benchmark data to comp.unix.i386 in a few
days that may help redefine "workstations" :-)  Every unix box I've had
the opportunity to work with either comes with or can be configured for
a bisync port.  These ports, usually implemented as intelligent peripherals,
are more than capable of 56kb.  A driver and pump code to assemble ax.25
packets should be trivial to construct - at least trivial in the same
context as writing an SCSI driver and making it co-exist with other
SCSI devices.  So why not just write the driver and provide cabling
information to connect the modem directly to the bisync port?  I'll bet
GRAPES would even distribute this information with the kits.


>3. The use of the XT parallel port as a bi-dir port is a non-issue as
>   far as I'm concerned, see #1 above (you can buy a plug-in card).

Of course, the eager ham who has just completed his modem kit and wants
to get on the air can bop down to the friendly local Klone dealer,
burn a $20 and be ready to plug'n'play.  Not quite so friendly
with the other cards.


>7. My personal SCSI experience is limited to the IBM adaptors (MCA
>   bus masters) and the AIX-PS/2 driver. The driver was written and
>   supplied from inside IBM, but I spent much time in contact with the
>   author of the driver.  I regard his expert input quite highly and
>   he has been quite helpful on details of a SCSI attached communications
>   device (he has interfaced the Adaptec Nodem, for instance).

As I rear up out of the smelly slime generated by the PS/2-AIX sewer in order
to gain a breath of fresh air, my only comment is that whatever experience
you gain with SCSI on a MicroFunnel bus should be considered an anomoly.
Sorry to be so graphic but my wounds are still very fresh and are being
gouged anew even as we speak.

>8. This is clearly a case of where I've decided a needs exists and plan
>   to fill it by learning what I must to build the SCSI i/f.

Why did you not say so in the first place?  If you desire to learn
something about SCSI interfacing and want to use Packet as the
vehicle, then by all means, go for it!  You have my 100% support.
But you asked if such a device would be generally useful.  Not in
a particular instance but as a general solution.  Several of us
answered "no" and explained why in explicit detail.  If you want to
ignore that advice, fine.  In the end, it was worth no more than you
paid for it.  But I think that the "grip getting" needs to be done
in your direction.

I'm now going to make another suggestion.  Why don't you add the tiny
bit of additional logic necessary to permit the input interface to
be pluggable.  You (or someone else, for that matter) could then
build BOTH interfaces plus maybe some others you have not yet
considered.

John

--
John De Armond, WD4OQC  | We can no more blame our loss of freedom on congress
Radiation Systems, Inc. | than we can prostitution on pimps.  Both simply
Atlanta, Ga             | provide broker services for their customers.
{emory,uunet}!rsiatl!jgd|  - Dr. W Williams |                **I am the NRA**

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu, 28 Jun 90 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #69
To: packet-radio


Packet-Radio Digest         Thu, 28 Jun 90       Volume 90 : Issue  69

Today's Topics:
           Kiss Protocol Standard (2 msgs)
            Network Models (long)
            Parallel port vs SCSI
             SCSI Support For NET
              SCSI TNC Comments

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 27 Jun 90 20:40:58 GMT
From: dsl.pitt.edu!pitt!speedy.cs.pitt.edu![e-mail]  (Bob Hoffman)
Subject: Kiss Protocol Standard
To: [e-mail]

A number of the papers from the Sixth ARRL Computer Networking Conference
are available with anonymous FTP to louie.udel.edu in the directory
pub/arrl_papers.  The KISS document is in the file kisstnc.ms.Z which
is a compressed Unix troff format file.

    ---Bob.

--
Bob Hoffman, N3CVL       {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science    [e-mail]    FAX: [phone]

------------------------------

Date: 28 Jun 90 02:27:52 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: Kiss Protocol Standard
To: [e-mail]

.\" kisstnc.ms -- submitted to the sixth ARRL computer networking
.\"              conference, August 1987.
.\" to format, use "eqn kisstnc.ms | tbl | troff -ms"
.EQ
delim $$
.EN
.\" Remove Page Trailer -- gets rid of page numbers
.rm PT
.ll 6.375i
.nr LL 6.375i   \" set Line Length
.po 1.0625i
.nr PO 1.0625i  \" set Page Offset (left margin)
.TL
The KISS TNC:
A simple Host-to-TNC communications protocol
.AU
Mike Chepponis, K3MC
.AU
Phil Karn, KA9Q
.AB
The KISS\**
.FS
"Keep It Simple, Stupid"
.FE
TNC provides direct computer to
TNC communication using a simple protocol described here.  Many TNCs now
implement it, including the TAPR TNC-1 and
TNC-2 (and their clones), the venerable VADCG TNC, the AEA PK-232/PK-87
and all
TNCs in the Kantronics line.  KISS has quickly become the protocol of choice
for TCP/IP operation and multi-connect BBS software.
.AE
.NH
Introduction
.PP
Standard TNC software was written with human users in mind; unfortunately,
commands and responses well suited for human use are ill-adapted for host
computer use, and vice versa. This is especially true for multi-user
servers such as bulletin boards which must multiplex data from several network
connections across a single host/TNC link.  In addition, experimentation
with new link level protocols is greatly hampered because there may very
well be no way at all to generate or receive frames in the desired format
without reprogramming the TNC.
.PP
The KISS TNC solves these problems by eliminating as much as possible from
the TNC software, giving the attached host complete control over and access
to the contents of the HDLC frames transmitted and received over the air.
This is central to the KISS philosophy: the host software should have control
over all TNC functions at the lowest possible level.
.PP
The AX.25 protocol is removed entirely from the TNC, as are all command
interpreters and the like.  The TNC simply converts between synchronous
HDLC, spoken on the full- or half-duplex radio channel, and a special
asynchronous, full duplex frame format spoken on the host/TNC link.
Every frame received
on the HDLC link is passed intact to the host once it has been translated to
the asynchronous format; likewise, asynchronous frames from the host are
transmitted on the radio channel once they have been converted to HDLC
format.
.PP
Of course, this means that the bulk of AX.25 (or another protocol) must now be
implemented on the host system. This is acceptable, however, considering the
greatly increased flexibility and reduced overall complexity that comes from
allowing the protocol to reside on the same machine with the applications to
which it is closely coupled.
.PP
It should be stressed that the KISS TNC was intended only as a stopgap.
Ideally, host computers would have HDLC interfaces of their own, making
separate TNCs unnecessary. [15] Unfortunately, HDLC interfaces are rare,
although they are starting to appear for the IBM PC.  The KISS TNC therefore
becomes the "next best thing" to a real HDLC interface, since the host
computer only needs an ordinary asynchronous interface.
.NH
Asynchronous Frame Format
.PP
The "asynchronous packet protocol" spoken between the host and TNC is very
simple, since its only function is to delimit frames. Each frame is both
preceded and followed by a special FEND (Frame End) character, analogous to
an HDLC flag.  No CRC or checksum is provided.  In addition, no RS-232C
handshaking signals are employed.
.PP
The special characters are:
.PP
.TS
center box tab(/);
l l l .
Abbreviation/Description/Hex value
=
FEND/Frame End/C0
FESC/Frame Escape/DB
TFEND/Transposed Frame End/DC
TFESC/Transposed Frame Escape/DD
.TE
.PP
The reason for both preceding and ending frames with FENDs is to improve
performance when there is noise on the asynch line.  The FEND at the
beginning of a frame serves to "flush out" any accumulated garbage into a
separate frame (which will be discarded by the upper layer protocol) instead
of sticking it on the front of an otherwise good frame.
As with back-to-back flags in
HDLC, two FEND characters in a row should not be interpreted as delimiting
an empty frame.
.NH
Transparency
.PP
Frames are sent in 8-bit binary; the asynchronous link is set to
8 data bits, 1 stop bit, and no parity.
If a FEND ever appears in the data, it is
translated into the two byte sequence FESC TFEND (Frame Escape, Transposed
Frame End).  Likewise, if the FESC character ever appears in the user data,
it is replaced with the two character sequence FESC TFESC (Frame Escape,
Transposed Frame Escape).
.PP
As characters arrive at the receiver, they are appended to a buffer
containing the current frame.  Receiving a FEND marks the end of the current
frame.  Receipt of a FESC puts the receiver into "escaped mode",
causing the receiver to translate a following TFESC or TFEND back to FESC or
FEND, respectively, before adding it to the receive buffer and leaving
escaped mode.  Receipt of any character other than TFESC or TFEND while in
escaped mode is an error; no action is taken and frame assembly continues.
A TFEND or TESC received while not in escaped mode is treated as an ordinary
data character.
.PP
This procedure may seem somewhat complicated, but it is easy to implement
and recovers quickly from errors. In particular, the FEND character is never
sent over the channel except as an actual end-of-frame indication. This
ensures that any intact frame (properly delimited by FEND characters) will
always be received properly regardless of the starting state of the receiver
or corruption of the preceding frame.
.PP
This asynchronous framing protocol is identical to "SLIP" (Serial Line IP),
a popular method for sending ARPA IP datagrams across asynchronous links. It
could also form the basis of an asynchronous amateur packet radio
link protocol that avoids the complexity of HDLC on slow speed channels.
.NH
Control of the KISS TNC
.PP
Each asynchronous data frame sent to the TNC is converted back into "pure"
form and queued for transmission as a separate HDLC frame.  Although
removing the human interface and the AX.25 protocol from the TNC makes most
existing TNC commands unnecessary (i.e., they become host functions), the
TNC is still responsible for keying the transmitter's PTT line and deferring
to other activity on the radio channel. It is therefore necessary to allow
the host to control a few TNC parameters, namely the transmitter keyup delay,
the transmitter persistence variables and any special hardware that a
particular TNC may have.
.PP
To distinguish between command and data frames on the host/TNC link,
the first byte of each
asynchronous frame between host and TNC is a "type" indicator.  This type
indicator byte is broken into two 4-bit nibbles so that the low-order
nibble indicates the command number (given in the table below) and the
high-order nibble indicates the port number for that particular command.
In systems with only one HDLC port, it is by definition Port 0.  In multi-port
TNCs, the upper 4 bits of the type indicator byte can specify one of up to
sixteen ports.  The following commands are defined in frames to the TNC  (the
"Command" field is in hexadecimal):
.PP
.TS
box expand tab(/);
l l l .
Command/Function/Comments
=
0/Data frame/T{
The rest of the frame is data to be sent on the HDLC channel.
T}
_
1/TXDELAY/T{
The next byte is the transmitter keyup
delay in 10 ms units.
The default start-up value is 50 (i.e., 500 ms).
T}
_
2/P/T{
The next byte is the persistence parameter, p, scaled to the
range 0 - 255 with the following formula:
.sp
$ P = p * 256 - 1 $
.sp
The default value is P = 63 (i.e., p = 0.25).
T}
_
3/SlotTime/T{
The next byte is the slot interval in 10 ms units.
The default is 10 (i.e., 100ms).
T}
_
4/TXtail/T{
The next byte is the time to hold up the TX after the FCS
has been sent, in 10 ms units.  This command is obsolete,
and is included here only for compatibility with some existing
implementations.
T}
_
5/FullDuplex/T{
The next byte is 0 for half duplex, nonzero for full
duplex. The default is 0 (i.e., half duplex).
T}
_
6/SetHardware/T{
Specific for each TNC.  In the TNC-1, this command
sets the modem speed.  Other implementations may use this
function for other hardware-specific functions.
T}
_
FF/Return/T{
Exit KISS and return control to a
higher-level program.  This is useful only when
KISS is incorporated into the TNC along with other
applications.
T}
.TE
.PP
The following types are defined in frames to the host:
.TS
box expand tab(/);
l l l .
Type/Function/Comments
=
0/Data frame/T{
Rest of frame is data from the HDLC channel
T}
.TE
.PP
No other types are defined; in particular, there is no provision for
acknowledging data or command frames sent to the TNC.
KISS implementations must ignore any unsupported command types.
All KISS implementations must implement commands 0,1,2,3 and 5; the others
are optional.
.NH
Buffer and Packet Size Limits
.PP
One of the things that makes the KISS TNC simple is the deliberate lack of
TNC/host flow control. The host computers run a higher level protocol
(typically TCP, but AX.25 in the connected mode also qualifies)
that handles flow control on an end-to-end basis.  Ideally,
the TNC would always have more buffer memory than the sum of all the flow
control windows of all of the logical connections using it at
that moment. This would allow for the worst case (i.e., all users sending
simultaneously).  In practice, however, many (if not most) user connections
are idle for long periods of time, so buffer memory may be safely
"overbooked".  When the occasional "bump" occurs, the TNC must drop the
packet gracefully, i.e., ignore it without crashing or losing packets
already queued.  The higher level protocol is expected to recover by
"backing off" and retransmitting the packet at a later time, just as it does
whenever a packet is lost in the network for any other reason.  As long as
this occurs infrequently, the performance degradation is slight; therefore
the TNC should provide as much packet buffering as possible, limited only by
available RAM.
.PP
Individual packets at least 1024 bytes long should be allowed.  As with
buffer queues, it is recommended that no artificial limits be placed on
packet size.  For example, the K3MC code running on a TNC-2 with 32K of RAM
can send and receive 30K byte packets, although this is admittedly rather
extreme.  Large packets reduce protocol overhead on good channels. They are
essential for good performance when operating on high speed modems such as
the new WA4DSY 56 kbps design.
.PP
.NH
Persistence
.PP
The P and SlotTime parameters are used to implement true p-persistent CSMA.
This works as follows:
.PP
Whenever the host queues data for transmission, the TNC begins monitoring
the carrier detect signal from the modem. It waits indefinitely for this
signal to go inactive. When the channel clears, the TNC generates a random
number between 0 and 1.\**
.FS
To conform to the literature, here $p$ takes on values between
0 to 1. However, fractions are difficult to use in a fixed point
microprocessor so the KISS TNC actually works with $P$ values that are
rescaled to the range 0 to 255.
To avoid confusion, we will use lower-case $p$ to mean the former (0-1)
and upper-case $P$ whenever we mean the latter (0-255).
.FE
If this number is less than or equal to the
parameter $p$, the TNC keys the transmitter, waits .01 * TXDELAY seconds,
and
transmits all queued frames. The TNC then unkeys the transmitter and goes
back to the idle state.  If the random number is greater than $p$, the TNC
delays .01 * SlotTime seconds and repeats the procedure beginning with the
sampling of the carrier detect signal. (If the carrier detect signal has
gone active in the meantime, the TNC again waits for it to clear before
continuing).  Note that $p = 1$ means "transmit as soon as the channel
clears"; in this case the p-persistence algorithm degenerates into the
1-persistent CSMA generally used by conventional AX.25 TNCs.
.PP
p-persistence causes the TNC to wait for an exponentially-distributed random
interval after sensing that the channel has gone clear before attempting to
transmit. With proper tuning of the parameters $p$ and SlotTime, several
stations with traffic to send are much less likely to collide with each
other when they all see the channel go clear.  One transmits first and the
others see it in time to prevent a collision, and the channel remains stable
under heavy load.  See references [1] through [13] for details.
.PP
We believe that optimum $p$ and SlotTime values could be computed
automatically.  This could be done by noting the channel occupancy and the
length of the frames on the channel.  We are proceeding with a simulation of
the p-persistence algorithm described here that we hope will allow us to
construct an automatic algorithm for $p$ and SlotTime selection.
.PP
We added p-persistence to the KISS TNC because it was a convenient opportunity
to do so.
However, it is not inherently associated with KISS nor with new protocols such
as TCP/IP.
Rather, persistence is a \fIchannel access\fR protocol that can yield dramatic
performance improvements regardless of the higher level protocol in use;
we urge it be added to \fIevery\fR TNC, whether or not it supports KISS.
.NH
Implementation History
.PP
The original idea for a simplified host/TNC protocol is due to Brian Lloyd,
WB6RQN.  Phil Karn, KA9Q, organized the specification and submitted an
initial version on 6 August 1986.  As of this writing, the following
KISS TNC implementations exist:
.PP
.TS
box expand tab (/);
l l l .
TNC type/Author/Comments
=
TAPR TNC-2 & clones/Mike Chepponis, K3MC/T{
First implementation, most widely
used. Exists in both downloadable
and dedicated ROM versions.
T}
_
TAPR TNC-1 & clones/Marc Kaufman, WB6ECE/T{
Both download and dedicated ROM
versions.
T}
_
VADCG TNC & Ashby TNC/Mike Bruski, AJ9X/Dedicated ROM.
_
AEA PK-232 & PK-87/Steve Stuart, N6IA/T{
Integrated into standard AEA
firmware as of 21 January 1987.
The special commands "KISS ON"
and "KISS OFF" (!) control entry
into KISS mode.
T}
_
Kantronics/Mike Huslig/T{
Integrated into standard Kantronics
firmware as of July 1987.
T}
.TE
.PP
The AEA and Kantronics implementations are noteworthy in that the KISS
functions were written by those vendors and integrated into their standard
TNC firmware. Their TNCs can operate in either KISS or regular AX.25 mode
without ROM changes.  Since the TNC-1 and TNC-2 KISS versions were written
by different authors than the original AX.25 firmware, and because the
original source code for those TNCs was not made available, running KISS on
these TNCs requires the installation of nonstandard ROMs. Two ROMs are
available for the TNC-2. One contains "dedicated" KISS TNC code; the TNC
operates only in the KISS mode. The "download" version contains standard
N2WX firmware with a bootstrap loader overlay. When the TNC is turned on
or reset, it executes the loader. The loader will accept a memory image in
Intel Hex format, or it can be told to execute the standard N2WX firmware
through the "H"\** command.  The download version is handy for
.FS
For "Howie", of course.
.FE
occasional KISS operation, while the dedicated version is much more
convenient for full-time or demo KISS operation.
.PP
The code for the TNC-1 is also available in both download and dedicated
versions. However, at present the download ROM contains only a bootstrap;
the original ROMs must be put back in to run the original TNC software.
.NH
Credits
.PP
The combined "Howie + downloader" ROM for the TNC-2 was contributed by
WA7MXZ.
This document was carefully typeset by Bob Hoffman, N3CVL.
.PP
.NH
Bibliography
.PP
.IP 1.
Tanenbaum, Andrew S., "Computer Networks"   pp. 288-292.
Prentice-Hall  1981.
.IP 2.
Tobagi, F. A.: "Random Access Techniques for Data Transmission over
Packet Switched Radio Networks," Ph.D. thesis, Computer Science
Department, UCLA, 1974.
.IP 3.
Kleinrock, L., and Tobagi, F.: "Random Access Techniques for Data
Transmission over Packet-Switched Radio Channels," Proc. NCC,
pp. 187-201, 1975.
.IP 4.
Tobagi, F. A., Gerla, M., Peebles, R.W., and Manning, E.G.: "Modeling
and Measurement Techniques in Packet Communications Networks," Proc.
IEEE, vol. 66, pp. 1423-1447, Nov. 1978.
.IP 5.
Lam, S. S.: "Packet Switching in a Multiaccess Broadcast Channel",
Ph.D. thesis, Computer Science Department, UCLA, 1974.
.IP 6.
Lam, S. S., and Kleinrock, L.: "Packet Switching in a Multiaccess
Broadcast Channel:  Dynamic Control Procedures," IEEE Trans. Commun.,
vol COM-23, pp. 891-904, Sept. 1975.
.IP 7.
Lam, S. S.: "A Carrier Sense Multiple Access Protocol for Local
Networks,"  Comput. Networks, vol 4, pp. 21-32, Feb. 1980
.IP 8.
Tobagi, F. A.: "Multiaccess Protocols in Packet Communications
Systems," IEEE Trans. Commun., vol COM-28, pp. 468-488, April 1980c.
.IP 9.
Bertsekas, D., and Gallager, R.: "Data Networks", pp. 274-282
Prentice-Hall 1987.
.IP 10.
Kahn, R. E., Gronemeyer, S. A., Burchfiel, J., and Kungelman, R. C.
"Advances in Packet Radio Technology," Proc. IEEE.  pp. 1468-1496.  1978.
.IP 11.
Takagi, H.: "Analysis of Polling Systems," Cambridge, MA
MIT Press 1986.
.IP 12.
Tobagi, F. A., and Kleinrock, L. "Packet Switching in Radio Channels:
Part II - The Hidden Terminal Problem in CSMA and Busy-Tone Solution,"
IEEE Trans. Commun.  COM-23 pp. 1417-1433.  1975.
.IP 13.
Rivest, R. L.: "Network Control by Bayessian Broadcast," Report
MIT/LCS/TM-285.  Cambridge, MA.  MIT, Laboratory for Computer Science.
1985.
.IP 14.
Karn, P. and Lloyd, B.: "Link Level Protocols Revisited," ARRL Amateur Radio
Fifth Computer Networking Conference, pp. 5.25-5.37, Orlando, 9 March 1986.
.IP 15.
Karn, P., "Why Do We Even Need TNCs Anyway", Gateway, vol. 3 no. 2, September
5, 1986.

------------------------------

Date: 28 Jun 90 05:26:31 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Richard Loken) writes:
>What does buying a Taiwanese XT clone and downloading Phil's gift wrapped
>software have to do with building, fixing, and modifying?  That is just as
>much appliance operating as an Icom, a microphone, and a triband beam.
>

There's one important difference: I provide full source code, so if
you're interested you can go into the code, take it apart, figure out
how it works, add new features, change those you don't like, etc.
Software hacking is as much a form of homebrewing as building hardware.

Phil

------------------------------

Date: 26 Jun 90 13:42:13 GMT
From: usc!cs.utexas.edu!helios![e-mail]  (William Gunshannon)
Subject: Parallel port vs SCSI
To: [e-mail]

Speaking of using the parallel port, does anyone know where I can find
the packet driver for the Xircom Pocket Ethernet adapter??  I believe
this uses the parallel port.

bill gunshannon

------------------------------

Date: 27 Jun 90 19:35:57 GMT
From: maytag!focsys![e-mail]  (Jack Houde)
Subject: SCSI Support For NET
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>I'm planning to build a SCSI card for my computer, and since everyone is
>talking SCSI, perhaps someone would enlight me on selecting the right
>SCSI chip to use.  I have Fujitsu MB87030, National Semi 5380 and
>8490 spec sheets but I wonder which to use.  I know that the 8490 and MB87030
>can handle to up 4Mbytes/sec transfer, but which chip is easier to program
>and which is easier to interface to differential SCSI bus.
>
>John

While your at it, check out the Adaptec AIC-6250.

------------------------------

Date: 28 Jun 90 07:31:48 GMT
From: swrinde!cs.utexas.edu!texbell!nuchat!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: SCSI TNC Comments
To: [e-mail]

In article <[e-mail]> [e-mail] (John G. DeArmond) writes:
>The reason you got the responses relative to PC architecture machinery
>is that PCs are the overwhelming choice for amateur packet.  Yes, there
>are 5 or 6 workstations out there (Atari?  Really? :-) but for medium
>speed networking, the PC is the obvious choice.

Even for those of us who are lucky or rich enough to own
workstation-class computers for home use, the PC may well be a better
choice for packet work. I'm planning a shack network and packet server
around an NCR Tower XP I've recently acquired. Even though it has both a
SCSI interface and a multiprotocol communications adapter, it'll be
connected to the packet network across an Ethernet connection to a
dedicated PC packet/IP switch. The reason is simple: that way, I don't
have to write device drivers.

>Every unix box I've had
>the opportunity to work with either comes with or can be configured for
>a bisync port.  These ports, usually implemented as intelligent peripherals,
>are more than capable of 56kb.  A driver and pump code to assemble ax.25
>packets should be trivial to construct - at least trivial in the same
>context as writing an SCSI driver and making it co-exist with other
>SCSI devices.  So why not just write the driver and provide cabling
>information to connect the modem directly to the bisync port?  I'll bet
>GRAPES would even distribute this information with the kits.

I'll probably do this with the MPCA, but it's more for educational value
than production (there's that nasty word again!) use. My Unix system has
better things to do than stuff bytes into packets.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
[e-mail]       (eieio)| adequately be explained by stupidity.
"I don't usually do vicious;        +----------------------------------------
 I try to stick to depressing." -- Janis Ian, in concert, 6/6/90

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri, 29 Jun 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #70
To: packet-radio


Packet-Radio Digest         Fri, 29 Jun 90       Volume 90 : Issue  70

Today's Topics:
               Interested in packet...
           Use of tcp/ip over Rose switches

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 29 Jun 90 02:40:16 GMT
From: zaphod.mps.ohio-state.edu!sunybcs!canisius![e-mail]  (Karl Vesterling)
Subject: Interested in packet...
To: [e-mail]

    I am studying for my HAM liscense, and I am only interested in PACKET
operation.  I love Phil Karn's (KA9Q) package, I am using it to do SLIP
between my PC, and my UNIX Box at my home.  I have been in CB radio for
about 5 month's now, and I would like to stop playing around and get serious.

    I have been into data communications since 1984, BBS'ing it over the
phone lines.  I made up my mind to get my HAM liscense when I got Phil Karn's
package via anonymous FTP looking for something to do SLIP with on a PC, and
I found out that you could do data communications over the radio, and better
yet, TCP/IP!  I immediately called a local board, and downloaded a learn
morse code program.  I almost have it down enough to get my novice, but I want
my General.

    To make this short, I am not here to do 1200bps over the radio, I want
9600bps, I'll even settle for 4800.  I know that there is stuff out there to
do it with, but I'm not sure which is the best configuration. (And I don't
want to make an expensive mistake!)

    I would appreciate any feedback on what modems will go that speed,
which is the most reliable, which has the most options, etc...  And most
of all, which radio will work with it.

    Packet is the reason I am getting into HAM, no doubt about it.
Otherwise I'd stick with CB and put up with the garbage (noise, skip, bad
attitudes, etc...)
                Thanks in advance...

--
------------------------------------------------------------------------------
Karl J. Vesterling                              [e-mail]
716-634-1643 (Answering machine, Box 1)         [e-mail]
Buffalo, NY                                     [e-mail]

------------------------------

Date: 28 Jun 90 20:55:03 GMT
From: zaphod.mps.ohio-state.edu!swrinde!dptspd![e-mail]  (Lee Ziegenhals)
Subject: Use of tcp/ip over Rose switches
To: [e-mail]

The netrom node owners in this area are considering a switch to the
Rose software.  There are several of use who are running the ka9q tcp/ip
code over netrom, and we would like to know what impact this will (or
hopefully, will not :-) have on tcp/ip operation.

Does anyone have any experience with operating tcp/ip through Rose nodes?
I know next to nothing about Rose, so any information would be appreciated.

73/Lee, N5LYT
[e-mail]

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat, 30 Jun 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #71
To: packet-radio


Packet-Radio Digest         Sat, 30 Jun 90       Volume 90 : Issue  71

Today's Topics:
           Interested in packet... (3 msgs)
             mac packet frontend
            Network Models (long) (2 msgs)
              SCSI TNC Comments (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 29 Jun 90 15:32:03 GMT
From: zaphod.mps.ohio-state.edu!swrinde!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Interested in packet...
To: [e-mail]

In article <[e-mail]> [e-mail] (Karl Vesterling) writes:
>
>       I am studying for my HAM liscense, and I am only interested in PACKET
>operation.  I love Phil Karn's (KA9Q) package, I am using it to do SLIP
>between my PC, and my UNIX Box at my home.  I have been in CB radio for
>about 5 month's now, and I would like to stop playing around and get serious.
>
>       To make this short, I am not here to do 1200bps over the radio, I want
>9600bps, I'll even settle for 4800.  I know that there is stuff out there to
>do it with, but I'm not sure which is the best configuration. (And I don't
>want to make an expensive mistake!)
>
>       I would appreciate any feedback on what modems will go that speed,
>which is the most reliable, which has the most options, etc...  And most
>of all, which radio will work with it.
>
>       Packet is the reason I am getting into HAM, no doubt about it.
>Otherwise I'd stick with CB and put up with the garbage (noise, skip, bad
>attitudes, etc...)
>                               Thanks in advance...

The best advice I can give is for you to get in contact with others in
your area and find out what they are planning to use. Our GRAPES 56
kilobaud RF modem is currently the fastest production system, but it
is of no use if you don't have partners who are also using it. One
step down is the G3RUH 9600 baud modem. It requires a TNC2 for digital
drive and a direct varactor modulated radio. Below that is the HAPN
4800 baud system and the Kantronic 2400 baud system followed by the
ever popular Bell 202 1200 baud modem built in by default to all
TNCs.

Remember that you must cut your thruput in half for each relay hop
you use and that you must count the serial links between your computer
and TNC and your partner's computer and TNC as hops. Thus, if you are
using 1200 baud modems, 1200 baud serial links, and one relaying digi-
peater, your maximum net thruput is considerably less than 300 baud.
The reasons that it's less  include transmitter keyup delay (Txd),
receiver unsquelch delay, PLL lockup delay, and the fact that you
must send a packet then wait for an acknowledgement before sending
another. Add to this contention for the channel with other users
and you should expect thruput on the order of 150 baud. With faster
modems, digital interface cards direct on the bus of your computer,
and longer packets, you can expect correspondingly higher thruput.
Example: with direct connects between 56 kilobaud modems, response
is similar to a hard wire 19.2 kilobaud link.

A rough guide to system pricing:

56 kilobaud:
    RF modem (28Mhz output) $250
    Transverter to 220 Mhz  $229
    Digital interface board $130
Total                           $609
Cost per baud                   $0.0109

9600 baud:
    G3RUH modem             $100
    TNC2                    $130
    220 Mhz FM radio        $450*
Total                           $680
Cost per baud                   $0.0708

1200 baud:
    TNC2                    $130
    144 Mhz radio           $450*
Total                           $580
Cost per baud                   $0.4833

*You may find used FM radios for considerably less than the above
 quoted new pricing. But if you have to buy everything, the most
 cost effective route is the 56k system.

Gary KE4ZV

------------------------------

Date: 29 Jun 90 23:30:17 GMT
From: [e-mail]  (Brian Kantor)
Subject: Interested in packet...
To: [e-mail]

The K9NG modem is a semi-kit for $25; you have to add another $10 of
parts to it.  It is a simple FSK with scrambler system; does direct-FM
on your radio.  It switches from receive to transmit; you have to have
two of them in the unlikely case that you're doing full-duplex.  About
half the parts on it are for PTT switching of the old FM-5 transceiver
and may be omitted in a lot of other applications.  For some radios you
have to apply compensation to make up for unexpected nonlinearities.

The G3RUH is a similar design except that it is full duplex and has a
compensation circuit on it that is designed to compensate for both the
transmitter AND receiver, which implies that a homogeneous network is
required.  In practice, that isn't quite true; it will work with several
different kinds of radios in the system.  Many people use the G3RUH for
medium-speed satellite work.

The California medium-speed backbone on 6 meters is all K9NG modems on
old commercial radios.  Because of the modulation acceptance of some of
the radios, we backed down to 4800 bps - although that's not that much
of a loss anyway, since a standard TNC-2 running net/rom doesn't do
much more than that in overall throughput anyway.  We don't use the
backbone for user access; it's an intercommunity link.
    - Brian

------------------------------

Date: 29 Jun 90 19:42:52 GMT
From: cs.utexas.edu!asuvax!mcdphx!phx.mcd.mot.com![e-mail]  (Dave Fritsche )
Subject: Interested in packet...
To: [e-mail]

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
> . . .
>One step down is the G3RUH 9600 baud modem. It requires a TNC2 for digital
>drive and a direct varactor modulated radio.
>

How about the K9NG (I think) 9600bps modem offered in partial kit form
from TAPR for ~$25?  I'm interested in knowing the differences/
advantages/disadvantages between the G3RUH & TAPR's offering.
Why would someone want to use one over the other?

Dave Fritsche ([e-mail])

------------------------------

Date: 29 Jun 90 23:46:39 GMT
From: xanadu![e-mail]  (Jeff Crilly (N6ZFX) )
Subject: mac packet frontend
To: [e-mail]

Does anybody know of a terminal program for the mac that works well
on packet?  I'm think of something that has a split screen where one screen
is for xmit and the other screen contains incoming data.  Sorta like
"talk" on unix (or "phone" on vms).  I am using a Kantronics All Mode.

----------------------------------------------------
Jeff Crilly (N6ZFX)
AMIX Corporation
2345 Yale St.
Palo Alto, CA  94306
[e-mail], {uunet,sun}!markets!jeff
----------------------------------------------------









--
----------------------------------------------------
Jeff Crilly (N6ZFX)
AMIX Corporation
2345 Yale St.

------------------------------

Date: 29 Jun 90 09:31:54 GMT
From: mcsun!ukc!axion!galadriel![e-mail]  (Robin Gape)
Subject: Network Models (long)
To: [e-mail]



------------------------------

Date: 29 Jun 90 18:40:35 GMT
From: [e-mail]  (Patty Winter)
Subject: Network Models (long)
To: [e-mail]

In article <[e-mail]> [e-mail] (Robin Gape) writes:
>
>You might add that to get Phil's software actually working requires
>rather a lot of hacking in itself, but that's another story!

Robin-
Could you elaborate on that? When I first used the KA9Q package, all
I had to do was add my personal information (callsign, IP address, etc.)
to the NET and BM startup files, toss a few lines into the ftpusers
file, and and make sure I had the latest hosts.net list for this area. I've
always assumed that setup on an IBM system is just as simple. Isn't it?


Patty

--
*****************************************************************************
Patty Winter N6BIS                        INTERNET: [e-mail]
AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
*****************************************************************************

------------------------------

Date: 28 Jun 90 20:37:28 GMT
From: zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: SCSI TNC Comments
To: [e-mail]

In article <[e-mail]> [e-mail] (John G. DeArmond) writes:
>The reason you got the responses relative to PC architecture machinery
>is that PCs are the overwhelming choice for amateur packet.  Yes, there
>are 5 or 6 workstations out there (Atari?  Really? :-) but for medium
>speed networking, the PC is the obvious choice.

    PCs are CURRENTLY very popular, and don't show any sign of going
away soon. I concede that willingly. The point I've been trying to make
all along is that THERE ARE OTHER THINGS OUT THERE. Amigas, Atari STs,
Sparcstation SLCs, machines that are pretty appealing to users who want
to do more than just log into the local bulletin boards. Please don't
feel compelled to "stomp out" anything else just because it is different.
The AM people felt compelled to fight with the SSB people many years ago.
It wasn't that long ago I heard CP/M people fighting with the DOS people.

   There is another issue with the argument "Oh, I'll just have an XT
clone in addition to my new Unix box/workstation.". Every computer
presents a source of RFI. The fewer the computers in your shack, the
easier it will be for you to clean up RFI sources. Many of the newer
machines, like Amigas and Ataris, are quite clean already. Many of
the XT clones are notoriously dirty.

>Every unix box I've had
>the opportunity to work with either comes with or can be configured for
>a bisync port.  These ports, usually implemented as intelligent peripherals,
>are more than capable of 56kb.  A driver and pump code to assemble ax.25
>packets should be trivial to construct - at least trivial in the same
>context as writing an SCSI driver and making it co-exist with other
>SCSI devices.  So why not just write the driver and provide cabling
>information to connect the modem directly to the bisync port?  I'll bet
>GRAPES would even distribute this information with the kits.

   I cry FOUL! on the comment "can be configured for". Do you mean an
adaptor card can be purchased? How much does it cost? Hmmm... Don't
fall into a common trap, which can be summarized in the following line:

  "I've got a better solution for this one piece of specific hardware"

   If I was designing a interface for PS/2s and PS/2s only, I might make
an MCA plug in card, or use the bi-directional parallel port. If I was
designing a connection for a system which has a useful Multi-Protocol
port, I would probably build a cable and write a driver. If I was making
an XT only interface, I'd use one of the evil plug in cards.

  But my design is not just for one system, and it isn't intentionally
limited to just those systems that exist today. Workstation class machines
are dropping in price, and the ones in use today may be available as
used gear in a few years. Furthermore, it isn't JUST workstations that
are coming out of the box equipped with SCSI (is an Amiga a workstation?).
Please keep in mind I started out with something like a "what if?" attitude.
What if people had a SCSI TNC? What are the benefits and disadvantages? As
I started to build a clear picture, SCSI started to look pretty good. I have
received many comments of the nature "Oh, I've already got a SCSI adapter
in my PC for my disk drives; I could plug a SCSI TNC into that?" or "Hey,
this would be a good reason to buy that SCSI interface I've been putting
off".

    This is not a "PCs vs. Workstations" battle. This is simply one new
idea that may ease the use of future new computers in packet radio. But,
given the way the amateur community is today, I can see how a new idea
may be offensive.
*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

Date: 29 Jun 90 14:44:11 GMT
From: philmtl!philabs!briar![e-mail]  (Robert Casey)
Subject: SCSI TNC Comments
To: [e-mail]

In article <0Y7-FC:@splut.conmicro.com> [e-mail] (Jay Maynard) writes:
> I'm planning a shack network and packet server
>around an NCR Tower XP I've recently acquired. Even though it has both a
>SCSI interface and a multiprotocol communications adapter, it'll be
>connected to the packet network across an Ethernet connection to a
>dedicated PC packet/IP switch.

Though I'm no expert in this area, I wonder if this thing called
"homebus" (a network for the house so the various devices in the house
can be controlled by a computer or similar) might be usable (whenever
homebus comes out) for the above application.  Hook up the TNC (and
server) to the homebus up in the attic, and sit at the homebus computer
somewhere else in the house and do packet radio.  Probably turns out
that the bandwidth is not enouugh to do more than 1200baud.

------------------------------------------------------------------------
A notice found on a piece of test equipment made in Japan:
"IT PUT ON THE VINYL SHEET ON THE SURFACE OF UPPER & LOWER PANEL FOR THE
PROTECTION  PLEASE USE AFTER TEAR OFF VINYL SHEET WHEN USING.

------------------------------

Date: (null)
From: (null)
And in case anyone had missed the point you can hack the Icom, the
microphone _and_ the triband beam if you've a mind so to do. These days
I don't often have the time to hack hardware or software but that of
itself wouldn't, and shouldn't, stop anyone coming on the air and using
other people's efforts.

You might add that to get Phil's software actually working requires
rather a lot of hacking in itself, but that's another story!

73

Robin
G8DQX

------------------------------

End of Packet-Radio Digest
******************************