-- o ICOM

a large digital component. There are many.
ma ny software p rograms on d isk a nd
ca nridge for your ham shack. The future o f
ham radio is ve ry much tied to the future of
co mputing. A great deal of the stuff that's
produced is public domain software, but
much of it, especially the more user-friendly
software. is comme rcially developed. If the
developers see that they cannot trust the ham
rad io community. they may deal themsel ves
OUI of ou r market. This , in addition to
amateu r radio 's trad ition of ethics and selfpolicing
.
Interview \,"ilh UF2AU
The first step is to determine whether or not
the Th eN el chip was developed by independent
developme nt or by reverse-engineering.
In a telephone inte rv iew, G iese staled that
he felt forced to ma ke a clone version of
Net/RO M because no source code was supplied
with the product, and there were some
bugs in the first version. Using an analogy ,
Hans explained: " You have a radio which
has spurious emissions. It came without a
circuit diagram. You make such a d iag ram.
and say this is it. this is how 10 re pa ir the
radio."
Hans appeared to waffle o n the question of
whether or not he d isassembled the Net/ RO M
chip. AI first he denied having copied Ron's
program by loo king at the ROM with a disassembler.
one of the tools of software programme
rs. " We did a new source code in C
and made it available : it was not di sassembly
.· · Later in our inte rv iew. however, Hans
said. " I disassembled some part of it." When
I repealed that 10 him for clarification, he
considered for a long moment, and then reiterated
that disassembly was nol part of the
process. This am biguity may or may not be
due to Ihe language difference.
After 1comment ed on the e xtreme sim ilarity
of the two ROMs. Giese continued, " If
he 's (Ron Raikes) go ing to cha rge sixty-five
bucks for a ROM , he has to live w ith be ing
cloned. Let's no! call it revenge. Let's say
that , am an angry consumer, Normally . we
would have made The Net d ifferently. but for
Ron 's high -nosed attitude."
Raikes' " high-nosed attitude. " accord ing
to Giese. is his refusal to release the source
code for Net/ROM when it was first marketed
. Yet. bear in mind that it's unusal for a
company to release the source code for o ne of
the ir copywriter products , for the obvious
reason that it leaves the product open for
bootlegging.
Government. Business Stance
I spoke to Ralph Haller, the FCC's Chiefof
Rules and Regulations. He was aware of the
controversy, but maintained that the FCC is
unable to act without a court ruling . I the n
turned 10 the Tucson Amateur Packet Rad io
(TA PR) organization for guidance. The
present head o f TAPR. And rew Freeborn
NOCCZ . said, - r encourage the FCC to resolve
it. Th e only way we as an o rganizat io n
ca n co me out and say an ything would be
because of a lawsuit . " They will not investi ­
gate because they will not pull thei r own
programmers from development work on
other projects. Andy ex plained that TA PR is
not a big organizat ion. but just a handful of
people employed full-time in developme nt.
Who Can Act?
Clearly , investigation had to go on at the
ind ividual level , and it has. In January 1989,
Thomas Allen WA6IGY. an experienced C
progra mmer, compared copies of the Net/
ROM and 1l1cNet source code. Allen ootained
the Net/RO M source code from Ron
Raikes . and a copy o f me TheNel source
code. He created a cross- reference table of
rout ine names and file names in each program
listing . He then compared the two source
codes with the following results , qu oted with
his permission:
"There are 234 Net/ ROM routines in v ersion
1.3. Of. ..232 routines in Net/ROM. all
are du plicated in TheNet with ide ntical numbers
and typeso f passed parameters. In every
TheNet C fun ction, an identica l number and
type of auto variable are allocated in the stack
in the same order as they are in the correspond
ing Net/ROM routine. " After many
suc h ex amples. Tom repon ed : " It is my
conclusion . . . that TheNet is not an origina l
development. bUI rather a d irect copy of Net/
ROM ... ..
Some people have questioned w herhcr o r
nOI the source code Ron has been handing out
to people is the real source code. This was
easy enough to verify, which Eric williams
WD6CMU did. Eric keyed in the Nel/ROM
source code obtained from Raikes and suecessfully
compiled it imo a Version 1.3 chip.
F urther Investlganon
I then called on IWO independem computer
consultants. e xpe rts in the C language . to
verify or dispute Tom' s cla ims. Each co nsultant
was sent both TheNet and Net/ROM
source code and a copy of Torn Allen ' s report.
Neither is a ha m radio operator.
Both indepe ndently arrived at the same
conclusion: Tom Allen's report is correct in
derail and in its conclusion.
O ne of the consulta nts, Jerry whimel l
(President of BC Software), said: " The rea ­
sons I agree wit h Tom are that if you look at
bot h sources with an eye toward what kind of
code a compiler would ge ne rate, you would
have to co nclude they arc the same . . .. If
they were developed separately, even from
the same de finition , I would expect to sec a 101
more d ifferences than I do." The source
codes varied only by some variable names.
The othe r consultant, Phil Reed. an internal
compute r consulta nt for Clark Equipment
, stated: " ...It is impo ssible for me to
be lie ve that two people could come up with
th e same rouunes t h rough this m uch
sluff ..; "
What To I>o?
Amateur rad io is self-policing: that 's always
been our c redo and to our credit. In the
absence of an ex pe nsive lawsuit, it must be up
to each indi vidual ham to examine the cvidonee
and to dra w thei r own co ncl usio ns.
We spo ke to one ham. T add T orborg
KA 2DEW. who ru ns abou t
100 The Net
nodes in the New England reg ion . He told us
he would soon be in contact with Raikes . If
Ron ca n sho w him proof that the primed
source code from Software 2lXJO, which appea
rs identica l to TheNet's alleged copy, ac ­
tually prod uces a production Net/ROM ch ip,
he wi ll pull down all ofhi s Thejcet nodes . He
may or may 001 bring them up as Net/RO Ms.
There are many alternatives . This is the son
of action that all affected ha ms should be
considering.
There will probably not be a formal court
case because o f the vast expense of suc h an
undertaking. In this case. the ham radio community
itself must serve as its own court. Are
we up to abiding by ou r own verdict? m
Bits of Background
There are three essential hardware ingredients
10 a packet stalion-a transceiver,
a microcomputer, and a data controller
thai inte rfaces (i.e. patches logethe r) the
first two. Data controllers are responsible
for converting the information that flows
between the micro and the rig to forms
each ca n accept. A telephone modem
serves essennauy the same function as a
data controller. Data controuers require
some inte lligence to perform their functions,
and so are computers in their own
right. Data controllers dedicated to modulating/de
modulating just packet radio data
are most often called Te rmina l Node Contro
lle rs (TNCs) .
like all c o m p ute rs, TNCs require
" soflware"--one or more computer programs-to
know what to "do." These are
instruction that a re stored on a "chip" (IC).
Since these programs are vital 10 Ihe TNC
opera tion, and typically ne ver need altera
tion, they are sto red on a Read Only
Memory (ROM) Chip. A ROM chip is an IC
from which you ca n " read" (draw from) the
information stored within, but to which you
ca nnot easily " write " (add/alte r mtormalion).
One of the many unique functions of
packet radio is its ability for different packet
stations to time-share a frequency. It can
do this successfully because a packet radio
syste m monitors a channel and transmits
on ly when it senses a clea r channel.
Packet stations that act as relays for packet
signals are called digipeaters (digis) .
They act like re peate rs , except that they
operate 00 on ly one channel (simplex).
When a packet to be relayed arrives at the
digipeater, the digi stores tne packet into a
buffe r and keeps il there until the digi
doesn't detect a ny activity on the channe l.
At that point, it tra os mits the packet
This is a neat concept in itself, for you
co uld theoretica lly send a packet anywhere,
provided there are digis en route. A
packeteer, however, slill had to know the
route and specify all the intermediate digi
addresses in their correct order when
sending a packet to a destinalion address.
This can be very cumbersome for long.
ha ul transmiss ions . Fortunately, much of
the routing has been automated through
systems such a s Net/ROM. which you ca n
read about further in the article ....
... de NS18
73 Amateur Radio • June , 1989 35