HDTenEightyP/NetNews huggingface dataset:
From: jeff@dsp.sps.mot.com (Jeff Enderwick)
Subject: Re: Motorola's gcc diffs?
Organization: Motorola DSP Compilers
	<BzvJAM.H8C@world.std.com>
Date: 31 Dec 92 09:23:57


> The one I tried is called Version 1.03.  When you try to compile
> something with it, it bombs when it gets to the point of looking
> for the non-existent optimizer.  The illegal instruction sequences
> include using an address register on the instruction after loading it,
> and doing a subroutine return on the instruction after modifying
> the system stack (i.e. popping the status).

How hard is this? Motorola has a product named DSP56KCC. It is a C 
compiler system that generates executable programs for the Motorola 
DSP5600X family of chips. Much of the aforementioned system is based 
gcc. The sources to the gcc based portion have been made available.
You have part of the system, and you expect everything to work? The 
compiler system doesn't generate illegal code sequences as you say;
nop insertion is performed later in the code generation process, and 
by non-FSF code. No, it isn't performed by the assembly language 
optimizer, it is performed by the assembler.

BTW, I really appreciate it when people point out real problems with 
the compiler. When we find out about bugs we fix them. I'm sorry if 
I sound grumpy, but hey, the thing works. If you later discover any 
real bugs, I would really appreciate hearing about them.

	no hard feelings,

	Jeff Enderwick
	jeff@dsp.sps.mot.com

PS: I would think that spending $709 (this is *not* a price quote) for
a compiler kit that includes an assembler, linker, librarian, libraries
(both ANSI and runtime support), a manual and phone support would be 
cheaper than fooling around with the sources. But I guess that's not my
decision to make.
Newsgroups: comp.dsp
From: phr@telebit.com (Paul Rubin)
Subject: Re: Motorola's gcc diffs?
Organization: Telebit Corporation; Sunnyvale, CA, USA
	<BzqIoE.35o@world.std.com> <JEFF.92Dec23232131@dsp.sps.mot.com>
Date: 23 Dec 92 22:49:47

In article <JEFF.92Dec23232131@dsp.sps.mot.com> jeff@dsp.sps.mot.com (Jeff Enderwick) writes:
   >  >you will find the complete...
   >This version seems to work all right, but it generates illegal instruction
   >sequences.  I was informed by Motorola that there is a post-optimizer
   >that is required, and that this code was not made freely available.
   >Although I was able to hack up a simple peephole optimizer to get rid
   >of the illegal instructions, the gcc code is very inefficient.
   >I threw the whole thing away.  Perhaps Motorola worked very hard
   >on their optimizer and it does miraculous things.  Perhaps not.

   This is all news to me. The post-optimizer isn't required, and it isn't 
   based on FSF source. 

	   Jeff Enderwick
	   jeff@dsp.sps.mot.com

What does the post-optimizer do?  How much does it improve
the code?  Thanks.

From: eric@hplvec.LVLD.HP.COM (Eric Waldheim)
Date: Sat, 2 Jan 1993 22:31:57 GMT
Subject: Mot 56k fp sin, cos, log
Organization: Hewlett-Packard Co., Loveland, CO
Newsgroups: comp.dsp

Howdy,

I'm looking for Mot 56000 floating point sin, cos, and natural log
routines (preferably written in assembly).  They're not provided in 
Dr. Bub's 56000 floating point library.  I already have the C/assembly
versions provided with Mot's G56KCC C cross-compiler.

Thanks,
Eric
Newsgroups: comp.dsp
From: jensenq@qcj.icon.com (Quinn Jensen)
Subject: Re: Motorola's gcc diffs?
Organization: Millenial Research Institute, Orem, Utah
Date: Fri, 25 Dec 1992 18:17:09 GMT

Don't forget that there are two versions of gcc for the 56k - one by
Andrew Sterian and one by Motorola.  Andrew posted his a long time ago.
I believe it is the one that is floating around all the archives.
The Motorola version has not been posted to the net as far as I know.

Quinn Jensen
jensenq@qcj.icon.com
Newsgroups: comp.dsp
From: jeff@dsp.sps.mot.com (Jeff Enderwick)
Subject: Re: Motorola's gcc diffs?
Organization: Motorola DSP Compilers
	<C051vt.9Ds@world.std.com> <JEFF.92Dec31160038@dsp.sps.mot.com>
	<C07886.M5t@world.std.com>
Date: 2 Jan 93 12:50:27


>By the way, I did pay the $120 upgrade fee.  I received an update
>of the assembler, which doesn't work on a 286 PC.  I did not
>receive the C compiler.  The distributor seems hopelessly
>confused about the part numbers, which are apparently the
>same whether it's $120 or $709.  Am I supposed to pay
>one $120 for the assembler update and another $120 for the
>compiler update?

No. It appears that your distributor is confused. Email me your phone
number and we'll get this straightened out. I'm sorry that someone
bungled your upgrade order. It will get fixed.

	Jeff Enderwick
	jeff@dsp.sps.mot.com
Newsgroups: comp.dsp
From: antsu@polaris.utu.fi (Antti-Pekka Virtanen)
Subject: Re: Motorola's gcc diffs?
Organization: University of Turku, Computing Centre
	<BzvJAM.H8C@world.std.com> <JEFF.92Dec31092357@dsp.sps.mot.com>
Date: 31 Dec 92 18:51:19

In article <JEFF.92Dec31092357@dsp.sps.mot.com> jeff@dsp.sps.mot.com (Jeff Enderwick) writes:

>   PS: I would think that spending $709 (this is *not* a price quote) for
>   a compiler kit that includes an assembler, linker, librarian, libraries
>   (both ANSI and runtime support), a manual and phone support would be 
>   cheaper than fooling around with the sources. But I guess that's not my
>   decision to make.

That's why I bought the 56000CLASA package. It's got the assembler etc.
(Is there a newer version than 4.5 ? and now can one upgrade ?)
The libraries might be nice but are not included with this package.
And I don't think they are not really necessary.
Also, you seem to get 90% discount when you are from a University :)

Regards, Antti-Pekka



--
 **************************************************************
 * Mail: Antti-Pekka Virtanen  E-Mail:   antsu@utu.fi         *
 *       Arholankuja 3 as 21             antsu@mea.utu.fi     *
 *       SF-21100 Naantali               antsu@nic.funet.fi   *
 *       Finland                         antsu@sandra.pp.fi   *
 **************************************************************
Newsgroups: comp.dsp
From: soemarwo@krusty.ee.udel.edu (Gatot Soemarwoto)
Subject: Matlab Comm. Toolbox
Organization: University of Delaware, Newark
Distribution: usa
Date: Sun, 27 Dec 1992 20:08:54 GMT

Hi all,
Would some kind souls out there tell me where I could get the Matlab
Communications Toolbox posted by Mehmet Zeytinoglu? I lost the information.

Thanks .... 
Gatot
From: 880840m@axe.acadiau.ca (MICHAEL ALEXANDER MCKAY)
Newsgroups: comp.dsp
Subject: Filters from genetic algorithms
Date: 21 Dec 92 15:59:21 GMT
Organization: Acadia University

Does anyone have references on using genetic algorithms to design digital 
filters? I've started using this method, breeding pole and zero locations, 
and evaluating the fitness of the resulting filters by finding the RMS of 
|H(z)|-Ideal(z) over 0<z<pi.
   This technique works well, but I think I could improve it with a better 
fitness function. Ideas?
Newsgroups: comp.dsp
From: phr@telebit.com (Paul Rubin)
Subject: Re: compilers for DSP processors
Organization: Telebit Corporation; Sunnyvale, CA, USA
Date: 22 Dec 92 19:14:19

    I did an application that decompressed G4 images and then scaled
    the images for a for a 300 page per minute printer . The C
    compiler was GNU and the risc was the Intel 80960CA. The code had
    beed optimized a lot in C and was still not fast enough.

300 pages per minute?  5 pages per second???  Yow!

    My usual experience with C compilers on DSP's that a 8 to 10 x
    increase in speed is possible in the c to asm port. After looking
    at the output of the GNU 80960 C compiler, I was impressed with
    the efficiency of the assembler output. I estimated that the
    increase in speed in the c to asm port would be a factor of 2 at
    best. I was able to attain a 3x speed increase on the G4
    decompression code and A 8X IMPROVEMENT on the scaling code.

    This speed increase was due to 1) using a machine instruction the
    complier was clueless about, and 2) an optimization of the scaling
    algorithmn that would have been not obvious at the compiler level.

You should report the missing machine instruction to the maintainers
of your compiler (I'm not sure which of the several available 960
GCC ports you were using), or simply extend the compiler yourself
to know about the extra instruction.  Having the compiler sources
is great.
Newsgroups: comp.dsp
From: benhogan@world.std.com (philip m simmons)
Subject: ECHO Cancelling
Summary: Request for Echo cancel Algorithm
Keywords: ECHO
Organization: The World Public Access UNIX, Brookline, MA
Date: Thu, 31 Dec 1992 16:22:40 GMT



Greetings, I am looking for an efficeint echo cancelling algorithm, for a
telephone system.  Other requirements are minimum processing horsepower, and
a convergence time of less than 2 seconds.

                                                   thanks for any help.

                                                   phil.


Newsgroups: comp.dsp
From: jpc@avdms8.msfc.nasa.gov (J. Porter Clark)
Subject: Octave-band analysis software
Organization: NASA/MSFC
X-Newsreader: NN version 6.4.19
Date: 23 Dec 92 02:42:51 GMT

Something to ponder over the holidays...

I'm looking for some software to do octave-band analysis of a file with
sampled audio data in it.  Third- and twelfth-octave would be even
better, but the immediate need is for whole octaves.

I thought about trying to roll my own using FFT's, etc., but I'd rather
not (he's going to say it) reinvent the wheel.

Right now, the best way I have of doing this is playing the audio file
back through a D/A into a Bruel & Kjaer real-time analyzer.  So I can
get the job done, but I sure would like to do it without the
intermediate analog step.

I'll take recommendations for freeware and payware.

Send mail, I'll summarize unless I get flamed really bad. 8-)
--
J. Porter Clark    jpc@avdms8.msfc.nasa.gov or jpc@gaia.msfc.nasa.gov
NASA/MSFC Flight Data Systems Branch
Newsgroups: comp.dsp
From: kohjin@marina.prug.or.jp (Kohjin Yamada)
Newsgroups: comp.dsp
Subject: Re: Motorola's gcc diffs?
Date: 1 Jan 93 04:16:56 GMT
Organization: I'm alone

In article <JEFF.92Dec31092357@dsp.sps.mot.com> jeff@dsp.sps.mot.com (Jeff Enderwick) writes:
|PS: I would think that spending $709 (this is *not* a price quote) for
|a compiler kit that includes an assembler, linker, librarian, libraries
|(both ANSI and runtime support), a manual and phone support would be 
|cheaper than fooling around with the sources. But I guess that's not my
|decision to make.

In regarding to Motorola BR526/D (1987) and BR541/D (1988);
	There is only for SUN-3 (DSP56000CLASC or DSP56KCCC).
Is the package for SUN-4 platform available?

//kohjin


-- 
    *----/----*    CompuServe: Kohjin Yamada, JR1EDE [76662,111]
  Q-----T------H   504-55 Shimo-Yamaguchi, Hayama, Miura, Kanagawa, Japan
*------/|-------*  Phone:+81-468-75-6750   Fax/Modem/Voice:+81-468-76-1176
Newsgroups: comp.dsp
From: rspence@cix.compulink.co.uk (Richard Spence)
Subject: Format of .AU Sound files               
Cc: rspence@cix.compulink.co.uk
Reply-To: rspence@cix.compulink.co.uk
Date: Thu, 31 Dec 1992 13:32:00 +0000

christos@kuhub.cc.ukans.edu () writes:

> Hello there,

> I am using the Public Domain program Sound Tools on the Sun station
> to record speech. The speech samples are saved in a mu-law 8bits/sample
> encoding rule with a standard ".au" header precceding the data. What I
> would like to know is what the format of the speech samples is? In other
> words, I am reading the bytes that correspond to 8-bit speech samples but I
> don't know whether they are in signed binary format(2's complement) or
> unsigned binary format or anyother format. I have tried both binary signed
> (2' complement) and unsigned but it doesn't work. Does anybody know how the
> samples are stored?

> I would appreciate any relevant response.

The most likely encoding will be a standard telecomms encoding at 64kbps or
8kHz audio. One second of information will be 8000 bytes, not 8kbytes.

The 'original' samples are 12 bits wide and a compression algorithm is
applied to get down to 8 bits. The USA (and dependants) use the mu-law
encoding scheme. We Europeans use an A-law scheme.

So much for background. If I remember correctly, the most significant bit is
a sign bit, indicating positive (0) or negative (1) value. The remaining 7
bits are the encoded amplitude of the sample. Manipulation will require you
to decode the sample correctly, and I don't have the details of mu-law
encoding to hand. But, I know where it is described. Try and get hold of the
CCITT's G.7xx series recommendations which is one large volume. Try a
technical library of a university. Alternatively, you could ask very nicely
and I will try to mail the relevant pages when I'm over in the US in January.

Richard Spence
rspence@cix.compulink.co.uk
CompuServe: 100112,304

>>>MATRIX version  1.21e
Newsgroups: comp.dsp
From: albertk@cs.kun.nl (Albert Koppes)
Subject: Wanted: power consumption for C40 or T9000
Keywords: TMS320C40, T9000
Organization: University of Nijmegen, The Netherlands
Date: Wed, 23 Dec 1992 16:33:49 GMT

Is there anyone that has some information about
the power consumption of the TMS320C40 or
some preliminary data on the power consumption of
the T9000 ?


Thanks in advance.



Newsgroups: comp.dsp,sci.image.processing,sci.math
From: gideony@microsoft.com (Gideon Yuval)
Subject: Mathematica packages for wavelets & got image-processing?
Date: 01 Jan 93 01:43:07 GMT
Organization: Microsoft Corporation

Are there any Mathematica packages available for wavelets?
for image-processing?

Thanks
-- 
Gideon Yuval, gideony@microsoft.com, 206-882-8080 (fax:-883-8101;TWX:160520)
Newsgroups: comp.dsp
From: vjh21@cas.org (Vince Herried ext 2877)
Subject: Motorola HC16 EVB communications
Organization: CAS
Date: Wed, 23 Dec 1992 20:09:42 GMT

I'm trying to figure out how to talk to my HC16 via the parallel port.
It came with lots of fine documentation and programs that run on an
ibm pee cee.  The pee cee development system chats via the pee cee
parallel printer port.  No documentation was provided on this protocol.
Another netter called Motorola who refered him to the software company
that made the support software.  The support software company said
nah, we ain't gonna tell, its propriatary.

I would like to use my Motorola 68030 based Amiga to interface with 
this little board.

What I've found so far about the parallel port interface.
It appears that d0 - d6 are output from the pee cee to the board,
the BUSY and ACK lines are the only other lines connected and they are both
input.

D1 clocks incomming data on D0 on the rising edge of D1.
D5 looks like it only controls the little green 'run' light on the board.

Data comming from the board to the pee cee appears to be clocked in by
D1 also and is contained on the BUSY line.  In yure doc on the
debugging interface it talks about the DSI and DSO data lines and
when they are clocked.  It looks like the PAL (by the 2rd party software
house) just smooths things with a little hardware glue.


I hope to have a complete description of the protocol and a working communications
program soon.  Anyone interested in the protocol for their favorite platform
send me a note on the back of a $20.00 and I'll see what I can do  :-)
merry xmas.
v
ka8cte
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
				 |     Vincent Herried  (614) 447-3600 x 2877
				 |     Chemical Abstracts Service
 _____________________           |     P.O. Box 3012
(_)________________   \          |     Columbus, OH 43210-0012
  ________________|\   \         |
 (_)______________\_\   \        |     Current thought: People who cannot be
   ______________________\       |     understood are geniuses, so management
  (_)____________________|       |     assigns them the toughest projects.
				 |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Newsgroups: comp.dsp
From: williamb@ee.ubc.ca (william burchill)
Subject: Re: Filters from genetic algorithms
Organization: University of BC, Electrical Engineering
Date: Wed, 23 Dec 1992 07:48:00 GMT

	You could multiply (z domain) your fitness function
by a weighting function.

Newsgroups: comp.dsp
From: helmut@efads1.tuwien.ac.at (Helmut Gander)
Subject: Re: IO cards for the Motorola DSP96000 ADS (available?)
Reply-To: helmut@efads1.tuwien.ac.at (Helmut Gander)
Organization: INFA
Date: Wed, 23 Dec 1992 11:14:07 GMT

In article <1fjgtjINN7nt@agate.berkeley.edu>,
sriram@doppler.berkeley.edu (S. Sriram) writes:
|>Hi there,
|>
|>I was wondering if there are any add-on IO interface cards
|>available for the Motorola DSP96000ADS ( application
|>development system for the DSP96K). I am interested in 
|>A/D,D/A cards, serial interfaces and such.  
|>
|>Thanks,
|>Sriram.
|>
We are developing hardware that can be used together with the
96000ADSA.
Using a backplane for the edge connector (96) the modules can be used
all together.
We are using and developing the following modules:

ADC/Board with 2 channels, both with 16 Bit and 166kS/s.
TimerBoard with three timers for IRQA/B/C, fully programmable.
Digital I/O, each 32Bit wide, LEDs for current status.
Incremental interface (especially for angular encoders) with count up
and down (up to about 17Mhz)
Fully programmable square wave generator.

Additional cards will also be developed.
Bye
Dipl.-Ing. Gander Helmut
Vienna University of Technology
Institute of Flexible Automation
Group RobTec
Gusshausstr. 27-29/361
A-1040 Vienna
Austria
EUROPE
hg@flexaut.tuwien.ac.at
helmut@efasp1.tuwien.ac.at
helmut@efasp2.tuwien.ac.at
From: hjermann@cmr.no (Sigmund Hjermann)
Newsgroups: comp.dsp
Subject: Wanted: ANSI C/F77 FFT library w/source
Date: 22 Dec 92 12:42:46 GMT
Organization: Chr. Michelsen Research, Norway

I need a ANSI C or FORTRAN 77 advanced math and/or signal processing software 
library with source code. I specifically need the real Fast Fourier Transform analysis, 
statistical analysis, and complex math (C) part of the library(ies). The purpose is to use 
it in Intel's RMX part of the DOS/RMX API with Intel's compilers.
Newsgroups: comp.dsp
From: mcdowell@exlogcorp.exlog.com (Steve McDowell)
Subject: Wanted: power consumption for C40 or T9000
Keywords: TMS320C40, T9000
Organization: EXLOG, Inc.
Date: Wed, 23 Dec 92 18:50:02 GMT

In message <Bzq0oD.CnB@sci.kun.nl> albertk@cs.kun.nl (Albert Koppes) asks:
> Is there anyone that has some information about
> the power consumption of the TMS320C40 or
> some preliminary data on the power consumption of
> the T9000 ?

This is from the C40 user's guide (available from TI):

		MIN	NOM	MAX	unit
High out volt	2.4	 3		 V
Low out volt		0.3	0.6	 V
3-state curr	-20		20	uA
Input current	-10		10	uA
supply current		350	850	mA
in capacitance			15	pF
out capacitance			15 	pF


-- 
Steve McDowell             . . . . o o o o o 		Opinions are 
Exlog, Inc.	                  _____      o     	mine, not my 
mcdowell@exlog.com      _____====  ]OO|_n_n__][.    	employers..
		       [_________]_|__|________)<
From: mikael@terapin.com (Mikael Andersson)
Newsgroups: comp.dsp
Subject: Pitch shifting
Date: 1 Jan 93 05:18:10 PST
Organization: BBS

Was ther any results on the Pitch-shifting discussion in this conference?
Are there any shortcuts or do i have to use FFT to change it? (And still
keep the quality?)
 
Mikael
From: griff@ccwf.cc.utexas.edu (yo'man)
Newsgroups: comp.dsp
Subject: TI C40 integration
Date: 22 Dec 92 18:22:36 GMT
Reply-To: griff@ccwf.cc.utexas.edu (yo'man)
Organization: The University of Texas at Austin, Austin TX
Originator: griff@huey.cc.utexas.edu


Has anyone have experiencing integrating the TI c40 comm port
with other processors or peripheals?  I'm trying to go from a 
Motorola 56k to a c40, and any help on the subject would be
greatly appreciated.

Andrew Wheeler
Applied Research Laboratories
University of Texas at Austin

Newsgroups: comp.dsp
From: jeff@dsp.sps.mot.com (Jeff Enderwick)
Subject: Re: Motorola's gcc diffs?
Organization: Motorola DSP Compilers
	<BzqIoE.35o@world.std.com>
Date: 23 Dec 92 23:21:31

>  >you will find the complete...
>This version seems to work all right, but it generates illegal instruction
>sequences.  I was informed by Motorola that there is a post-optimizer
>that is required, and that this code was not made freely available.
>Although I was able to hack up a simple peephole optimizer to get rid
>of the illegal instructions, the gcc code is very inefficient.
>I threw the whole thing away.  Perhaps Motorola worked very hard
>on their optimizer and it does miraculous things.  Perhaps not.

This is all news to me. The post-optimizer isn't required, and it isn't 
based on FSF source. 

	Jeff Enderwick
	jeff@dsp.sps.mot.com
Newsgroups: comp.dsp
From: antsu@vega.utu.fi (Antti-Pekka Virtanen)
Subject: Re: Motorola's gcc diffs?
Organization: University of Turku, Computing Centre
Date: 22 Dec 92 23:04:40

In article <1992Dec21.221938.14602@cheops.qld.tne.oz.au> pclink@cheops.qld.tne.oz.au (Rick) writes:
>
>   Anybody know where I can the machine description/diffs for Motorola's
>   port of gcc to the DSP56K?
>
>   Rick.

You will find the complete Gcc source in 
nic.funet.fi:/pub/ham/dsp/dsp56k-tools/dsp56k-gcc.tar.Z

Regards, Antti-Pekka
Newsgroups: comp.dsp
From: brucet@extro.ucc.su.OZ.AU (Bruce Tulloch)
Subject: What are US DSP book prices like ?
Keywords: book multirate dsp 
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Mon, 4 Jan 1993 01:59:48 GMT

I am seeking the book

"Multirate Digital Signal Processing" by R. E. Crochiere and L. R. Rabiner
Prentice Hall, 1983.

Unfortunately, the publisher wants to charge me $149 plus $35
air-freight to buy it in Australia through their local distributors.
How much does it cost in the US ? I might buy it direct.

Thanks for your help one and all,

brucet


-- 
          bruce tulloch sydney australia - brucet@extro.ucc.su.oz.au
***complex problems have straight forward, easy to understand wrong answers***
Newsgroups: comp.dsp
From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Motorola's gcc diffs?
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Thu, 31 Dec 1992 16:56:48 GMT

In <JEFF.92Dec31092357@dsp.sps.mot.com> jeff@dsp.sps.mot.com (Jeff Enderwick) writes:
>PS: I would think that spending $709 (this is *not* a price quote) for
>a compiler kit that includes an assembler, linker, librarian, libraries
>(both ANSI and runtime support), a manual and phone support would be 
>cheaper than fooling around with the sources. But I guess that's not my
>decision to make.

Except for those who already have that package or want to use it on
a different platform.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
From: christos@kuhub.cc.ukans.edu
Newsgroups: comp.dsp
Subject: Format of .AU Sound files
Date: 30 Dec 92 20:18:51 CST
Organization: University of Kansas Academic Computing Services

Hello there,

	I am using the Public Domain program Sound Tools on the Sun station to record
speech. The speech samples are saved in a mu-law 8bits/sample encoding rule with a 
standard ".au" header precceding the data. What I would like to know is what the 
format of the speech samples is? In other words, I am reading the bytes that 
correspond to 8-bit speech samples but I don't know whether they are in signed
binary format(2's complement) or unsigned binary format or anyother format. I have
tried both binary signed (2' complement) and unsigned but it doesn't work. Does
anybody know how the samples are stored?

	I would appreciate any relevant response.


Thanks,
Internet Address: rsl11@kuhub.cc.ukans.edu
Bitnet Address: rsl11@ukanvm.bitnet