HDTenEightyP/NetNews huggingface dataset:
From: stettbac@isibee5 (Juerg Stettbacher)
Newsgroups: comp.dsp
Subject: DSP56000 memory
Date: 4 Sep 92 11:10:51 GMT
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
X-Newsreader: Tin 1.1 PL5


Hello world

The DSP56001 has 3 memory spaces (X, Y and P).
X and Y are data memory spaces. Their sizes depend on
the particular application. P holds the program.

Question: What's a reasonable size for program memory P.
(Common DSP applications with  monitor for stand alone.
Software development in C and assembler).

Any suggestions?


Thanks
juerg at ethz switzerland
Newsgroups: comp.dsp
From: u8801763@cc.uow.edu.au (Radivoj Kouzan)
Subject: Re: TMS320C25: Continuous speech problem
Organization: University Of Wollongong
Date: Thu, 3 Sep 92 06:12:20 GMT

u9066624@cc.uow.edu.au (Tippu Hassan) writes:

>Hello anyone,

>My name is Tippu and I live in Australia. I am working with the TI
>"SWDS" (Software Development Systems) board which is a support tool
>for the TMS320C25 dsp chip. I am using the TMS320C25 serial port to
>read in digitized speech samples and then storing them on external
>RAM memory which is on the SWDS board. The SWDS only has 32K bytes
>of onboard RAM avialable and therefore I can only store 2 seconds
>worth of 16-bit digitized speech. So in order to record continous
>speech I am using the cpu processor to upload these speech samples
>from the SWDS board RAM and store them on files once the RAM is full. 
>This is done via C applications written for the cpu. 
>My problem is that in order for the cpu to access the SWDS RAM once 
>it is full, it MUST place the TMS320C25 in halt mode, then upload 
>the speech samples and then unhalt the TMS320C25 to resume reading 
>in the next load of speech samples. But the cpu cannot execute this 
>process quite enough, and TMS320C25 loses some speech samples while 
>it is halted. I cannot uses the grep command on the TMS320C25, which
>makes the external RAM global, because it requires external circuitry
>for the TMS320C25 and it is wired onto the SWDS board. Can anyone offer
>any ideas or help as it would be much appreciated.




Sell it and buy yourself a DSP that works for Digital Signals.
From: Michael.Malak@halluc.com (Michael Malak)
Sender: UUCP@halluc.com
Newsgroups: comp.dsp
Subject: Free 386 fft code
Date: 25 Aug 92  08:00:00 EDT

(Perhaps this is another candidate for the FAQ)

Does anyone know of any free FFT assembly code for the 386?


Newsgroups: comp.dsp
From: gtalatin@vartivar.ucs.indiana.edu  (Gerard V. Talatinian)
Subject: Any FTP'able documents describing Federal Standard 1016 CELP?
Reply-To: gtalatin@ucs.indiana.edu
Organization: Indiana University
Date: Tue, 25 Aug 1992 19:51:04 GMT


I am aware of the following three references from the Audio File Formats  
(version 2.3) FAQ posting. I would like to obtain any FTP'able versions of  
these or any other documents describing the 1016 CELP standard:

   Campbell, Joseph P. Jr., Thomas E. Tremain and Vanoy C. Welch,
   "The Federal Standard 1016 4800 bps CELP Voice Coder," Digital Signal
   Processing, Academic Press, 1991, Vol. 1, No. 3, p. 145-155.

   Campbell, Joseph P. Jr., Thomas E. Tremain and Vanoy C. Welch,
   "The DoD 4.8 kbps Standard (Proposed Federal Standard 1016),"
   in Advances in Speech Coding, ed. Atal, Cuperman and Gersho,
   Kluwer Academic Publishers, 1991, Chapter 12, p. 121-133.

   Campbell, Joseph P. Jr., Thomas E. Tremain and Vanoy C. Welch, "The
   Proposed Federal Standard 1016 4800 bps Voice Coder:  CELP," Speech
   Technology Magazine, April/May 1990, p. 58-64.

Thanks.


************************************************************
* Gerard Talatinian               gtalatin@ucs.indiana.edu *
* University Computing Services   Voice: (812)855-0962     *
* Network Research & Planning     FAX:   (812)855-8299     *
* Indiana University                                       *
************************************************************
Newsgroups: comp.dsp
From: nieto@trantor.harris-atd.com (John Nieto)
Subject: C40 Application Card
Date: Wed, 2 Sep 1992 14:33:41 GMT
Organization: Advanced Technology Dept, Harris Corp, Melbourne, FL


   Has anybody heard of a C40 application card with an A/D
 and possibly a D/A. 

   Thanks in advance.

-- 

John Nieto				ARPA  : nieto@trantor.harris-atd.com
Harris Corporation 			Usenet: ...!uunet!x102a!trantor!nieto
PO Box 37, MS 16/1912			AT&T  : (407) 727-4404
Melbourne, FL 32902			FAX   : (407) 729-3363

Let's do pizza. - TMNH

Newsgroups: comp.dsp
From: stettbac@isibee14 (Juerg Stettbacher)
Subject: DSP56001 monitor
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
X-Newsreader: Tin 1.1 PL5
Date: Wed, 2 Sep 1992 08:35:46 GMT


Does anyone have a monitor program for a DSP56001 customer board?

I'm looking for something like that..


Thanks
juerg at ethz switzerland


Newsgroups: comp.dsp,news.answers
From: seimet@rhrk.uni-kl.de (Uwe Seimet)
Subject: Re: DSP56000 memory
Organization: University of Kaiserslautern, Germany
Distribution: eunet
Date: Fri, 4 Sep 1992 16:39:22 GMT

stettbac@isibee5 (Juerg Stettbacher) writes:

>Question: What's a reasonable size for program memory P.
>(Common DSP applications with  monitor for stand alone.
>Software development in C and assembler).
DSP applications in assembler are normally quite short. The NeXT has 8 KB
memory for its DSP, that seems to be enough. The Atari Falcon030, however,
has 32 KB memory. The Falcon's OS supports loading multiple programs in the
DSP memory at the same time, so it makes sense to have more than 8 KB.

***************************************
*        Uwe Seimet                   *
*        seimet@rhrk.uni-kl.de        *
*        seimet@chemie.uni-kl.de      *
*-------------------------------------*
* I really hate this damned machine,  *
*     I wish that they would sell it. *
* It never does that what I mean      *
*     but only what I tell it.        *
***************************************
From:  (Prof. Blum)
Newsgroups: comp.dsp
Subject: Research Assistant in Signal Processing Postion Available
Date: 29 Aug 92 00:58:50 GMT
Organization: Lehigh University

Research Assistantship in Signal Processing 

The Department of Electrical Engineering and Computer Science at
Lehigh University in Bethlehem, Pennsylvania wishes to announce
a limited number of research assistantships (tuition and stipend) 
available for graduate research in signal processing 
(specifically signal detection and estimation).
These highly competitive positions are for important basic research 
and may be funded for three years.  
Only highly motivated students with top grades and good mathematical skills 
should apply.  Students with electrical engineering degrees are desired 
and those with backgrounds in signal detection and estimation 
or statistical signal processing are preferred.  Students interested 
in this opportunity should a resume with references, transcripts, and a copy 
of a technical paper or report they have written to: 

             RA in Signal Processing
             Professor Blum 
             Department of Electrical Engineering and Computer Science 
             Packard Lab # 19 
             Lehigh University
             Bethlehem, PA 18015

Indicate your interest a PhD or a Masters
degree and give a brief indication of your relevant experience.

All students must go through the normal graduate admissions process. 
A student could begin study in the Spring term and 
the deadline to apply for admission for the Spring term is Nov. 15. 
An application for admissions can be obtained by writing to:
 
             Graduate Admissions Office
             Whitaker Laboratory 5
             Lehigh University
             Bethlehem, PA 18015

Indicate your interest in the Electrical Engineering and Computer Science
Department.  

A description of the research is given below. 

Brief Description of Research 

	 Distributing multiple sensors over a large area 
for the purpose of detecting a signal in noise is becoming 
increasingly attractive.  
In such cases it is generally too costly to transmit all the data
generated by each sensor to some central location for use in decision
making.  
Schemes that provide
acceptable performance while requiring only limited transmission capacity 
are of interest.
Locating a detector at each sensor and transmitting
only its decisions to a fusion center is one common approach.
The bulk of the research work concerning the design of such distributed 
detection schemes has focused on  
signal detection problems where a complete observation 
model which categorizes the environment 
under consideration is known.   
We will pursue research to investigate distributed 
detection schemes for cases where a complete observation model is 
not available due to incomplete knowledge of the operating 
environment. 
This is an extremely practical case which has applications in 
air traffic control,   
radar weather monitoring, military radar and sonar,  
and medical diagnostic systems.
From: phil@hansen1.ncd.com (Phil Graham)
Newsgroups: comp.dsp
Subject: DSP article in September QST
Keywords: DSP
Date: 28 Aug 92 20:43:15 GMT
Organization: Network Computing Devices, Mt. View, CA, USA

There is a pretty good article in the September QST (ham radio) magazine.

This article describes a DSP filter using the TMS320C10.  There are two basic
filters that are available (Notch/Denoiser and CW bandpass filter).

These look like good starting points.  Source for these filters are on 
Compuserve.  What I need now is an assembler for this that is cheap?

Any ideas?


DE KJ6NN
Phil
Newsgroups: comp.dsp
Subject: TI TMS320C30 C Compiler
From: psyxsgp@otago.ac.nz
Date: 2 Sep 92 14:57:34 +1300
Organization: University of Otago, Dunedin, New Zealand

Hi,
	I'm trying to compile some TMS320C30 code using TI's
compiler version 2.10. This does not appear to support function 
prototyping.

	In addition it seem to have had difficulty with some typedef statements

	I have included some of the errors from the compiler, and the
corresponding code statements below.

	Are these errors due to problems with the TI compiler, or am
I not recognising some errors in the code.

	Also, what is the current state of the TI compiler .. cost 
and availability.Is there an alternative?

	Thanks
	Stephen pearce


[record.c]
C Pre-Processor             Version 2.10   
(c) Copyright 1987, 1989, Texas Instruments Incorporated 
TMS320C30 C Compiler        Version 2.10   
(c) Copyright 1987, 1989, Texas Instruments Incorporated 
"sp.h", line 35: syntax error
"sp.h", line 36: syntax error
"sp.h", line 37: syntax error
**
 35 	>typedef int  (* SPProc)     {(SP_Ptr pSP)};
 36 	>typedef void (* SPCtrlProc) {(SP_Ptr pSP)};
 37	>typedef int  (* SPResProc)  {(SP_Ptr pSP, unsigned long val)};

   "record.c":  ==> main
"record.c", line 209: val undefined
**
actually do not have any variable called val in main()


"record.c", line 368: syntax error
**
 368    >void do_rec_play(void){ etc

"record.c", line 368: redeclaration of do_rec_play
   "record.c":  ==> do_rec_play
   "record.c":  ==> c_int05
   "record.c":  ==> c_int06
   "record.c":  ==> c_int07
>> Fatal errors found: no intermediate file produced

-- 
Stephen Pearce, University of Otago, Dunedin, New Zealand.
ph 064-3-4740999 ext 8166 home 064-3-4763778
From: jjw@precipice.chi.il.us (John Welch)
Newsgroups: comp.dsp
Subject: Hilbert Transform (?)
Date: Wed, 02 Sep 92 17:08:20 CDT
Organization: Welch Research

    I would like to make a DSP project that would digitize
voice grade audio (300-3000 Hz) and provide the original signal
and that signal phase-shifted by 90 degrees.  I believe this 90
degree phase shift is done with a Hilbert Transform.  I have found
the name, but no info on *how* to do a Hilbert Transform.  Any
assistance would be greatly appreciated.  -->jjw

Newsgroups: comp.dsp
From: shari@creek.eel.ufl.edu (Shariar Emami)
Subject: test
Organization: UF EE Department
Date: Wed, 26 Aug 92 15:03:56 GMT

 this is just a test, please ignore it.
Newsgroups: comp.dsp
From: mklai@eng.ie.cuhk.hk (Edmund M K Lai)
Subject: Development System Costs
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Fri, 4 Sep 1992 00:03:38 GMT

I would like to get hold of the prices for TMS320C30, Motorola 96000
and Analog Devices 21020 DSP development kits.

Could anyone comment on their relative merits?

Edmund Lai
Department of Information Engineering
The Chinese University of Hong Kong
Shatin, N.T.
Hong Kong
Email: mklai@eng.ie.cuhk.hk
From: raffi@aero.org (Raffi Krikorian)
Newsgroups: comp.dsp
Subject: Re: Any 96002 C compilers Users?
Date: 25 Aug 92 20:12:30 GMT
Organization: The Aerospace Corporation, El Segundo, CA

In article <1992Aug17.222334.13572@news.Hawaii.Edu> denault@galileo.ifa.hawaii.edu (Tony Denault) writes:
>I been writing some 96002 DSP code for Ariel's MM-96. I am using
>Motorola's 96002 Macro Assembler. I would like to purchase a C compiler.
>I've heard Motorola and Intermetrics sells a C compiler for the 96002. 
>If you are familiar with these products, can you  email me you 
>opinions/experiences with these product. 
>
>Thanks
>
>Tony Denault
>--
>/------------------------------------------------------------------------\
>| Tony Denault, Institute for Astronomy,  | denault@uhifa.ifa.hawaii.edu |
>| 2680 Woodlawn Drive, Honolulu, HI 96789 |               (808) 956-8101 |
>\------------------------------------------------------------------------/

I've been using Microsoft C 7.0 and no problems so far.  Just make
sure to use the make files that come with the MM-96.

Raffi Krikorian
Newsgroups: comp.dsp
From: williamb@ee.ubc.ca (william burchill)
Subject: Re: Hilbert Transform (?)
Organization: University of BC, Electrical Engineering
Date: Thu, 3 Sep 1992 20:18:23 GMT

You are in luck, an audio grade Hilbert transform is one of the most
trivial transforms known to man.
Construct a FIR filter with samples from a windowed version of
1.0/(PI*t) and you're in business.

Newsgroups: comp.dsp
From: bil@cmn16.Stanford.EDU (Bill Schottstaedt)
Subject: Re: Finding how much DSP56001 RAM is installed via program??
Organization: DSO, Stanford University
Date: Wed, 26 Aug 92 13:46:37 GMT

In article <17fb61INN572@agate.berkeley.edu> izumi@pinoko.berkeley.edu  
(Izumi Ohzawa) writes:
> Failure on any one pattern should break the loop.
> The program just doesn't exit the loop...

I believe the program does not fail because the out-of-range NeXT DSP
external memory addresses are mapped back onto lower addresses.
For example, on an 8K dsp, an address like X:$B001 actually
writes to X:1 (external, of course = $A001).  This makes it
harder to figure out how much memory is actually out there.
From: jyrkkari@sara.cc.utu.fi
Newsgroups: comp.dsp
Subject: TMS320 DPS BBS help!!
Date: 31 Aug 92 09:05:02 GMT
Organization: University of Turku, Finland


  I live in Finland. I read from TMS320 Family Support Guide '90 about 
TMS320 DSP Bulletin Board Service. It uses 8 data bits 1 stop bit and 
no parity. The number is (713) 274-2323 (in USA). Possible speeds are
300,1200 and 2400 bps.
  I used SupraFAX modem v.32bis with kermit and after that with telix.
I used the highest possible speed.I dialled the number. I could hear 
the BBS answering but the modems couldn't make the connection. No carrier.
  Can someone help me out ? Has TI changed the configuration ? Do they now
also have an internet address ? Does anyone know an anonymous FTP site where
the same programs and information could be available? It is expensive to use
phonelines.
                Kari Jyrkkala
From: ghoti+@ANDREW.CMU.EDU (Adam Stoller)
Newsgroups: comp.soft-sys.andrew
Subject: Re: Hasn't the message line bogosity gone on long enough?
Date: 28 Aug 92 18:42:25 GMT
Distribution: world
Organization: The Internet

Criag is, I believe correct - it may very well have been in BX - and yes
it is quite likely, given the format of warning/error-messages in the
AMS code that the AMS code was responsible for the time-stamps - not the
message-line itself.

--fish
From: rdew@ALW.NIH.GOV (Bob Dew)
Newsgroups: comp.soft-sys.andrew
Subject: Re: "slow networks"
Date: 27 Aug 92 20:57:36 GMT
Distribution: world
Organization: The Internet


> Simple things:

> Get EZmail onto the Andrew disk in place of vui.
> Advertise cui as a testing program not a user program.
> RIP OUT the message server, throw it away, and replace 1 meg of
> impossible code with 100K of simple code that uses pop and/or nntp and
> a unix filesystem.

Certainly a principal design criteria, and perhaps the motivating
impetuous behind ATK's development was its ability to work in a
distributed fashion across different architectures, securely, within
AFS.  That's a tall order for off-the-shelf unix utilities to comply
with, and that's a leading reason why ATK's interoperability with common
unix communications systems is somewhat difficult.  

While many sites which use the ATK are not AFS participants, I think it
would be a great disservice to ATK's incredibly rich design effort to
bring its code down to the level of common client-server models, as
would likely be the case if ATK's message server were replaced with
something compatible with POP and nntp.

A good vui replacement is "a consummation to be wished", but I don't
think scrapping AFS support, if favor of a simple unix-like design, is
the answer.


-Bob
From: gk5g+@ANDREW.CMU.EDU (Gary Keim)
Newsgroups: comp.soft-sys.andrew
Subject: Re: DECnet mail
Date: 3 Sep 92 18:29:01 GMT
Distribution: world
Organization: The Internet

Excerpts from netnews.comp.soft-sys.andrew: 3-Sep-92 DECnet mail Eric
James Ewanco@irenae (825)

> Is there any way to convinced CUI/messages to send DECnet style mail
> (HOST::USER)? I am using Ultrix sendmail so it will work as long as AMS does
> attempt to send it.  I thought I had turned off all address validation but
apparently not.

Exactly how did you disable address validation?  I image you looked in
the setup help file and saw this little ditty:

AMS_LocalDatabaseValidation: integer
    Default: 0
    A value greater than 0 specifies that there is a local mechanism for
    local name validation being used.  0 specifies that there is no
    other local mechanism for local name validation being used. 
    Note:  If you want to use this option you must change the procedure
    LookupInLocalDatabase in "andrew/ams/libs/ms/mswp.c" to implement
    your local mechanism.

That is actually incorrect.  The LookupInLocalDatabase routine is in
site.c in that same directory.  Here is a comment from that file:

/* This routine, LookupInLocalDatabase, is a site-dependent routine for
performing non-standard name validation. */
/* A trivial change to this would validate all local names as OK.  The
body would have 3 lines:

  *Answered = 1;
  *MswpCodeP = (CheckAMSFmtOK(Domain) <= 0 ? MSWP_GOODNETMAIL : MSWP_GOODUSER);
  return(0):

(Sigh.  MSWP_GOODUSER is a user who is ready to receive ATK-formatted
mail; MSWP_GOODNETMAIL is a user who is not necessarily ready for that. 
To say that a local name is NOT valid, set *Answered to 1 and set
*MswpCodeP to MSWP_CRAP.)

Of course, the AMS_LocalDatabaseValidation variable would also have to
be turned on in mailconf.c, also, either statically or via an
AndrewSetup or AMS-Server file.
*/

So, you can do it if you don't mind building from source ;^)

Gary Keim
Andrew Consortium
From: rdew@ALW.NIH.GOV (Bob Dew)
Newsgroups: comp.soft-sys.andrew
Subject: Re: AMDS problem
Date: 1 Sep 92 19:04:31 GMT
Organization: The Internet

Well, egg on my face.

The problem with "messages" not being able to read new mail on sun hosts
appears to be due to our 1.8MB amsn.do exhausting the available swap
space whenever the "Read Mail" menu option is selected.

Short of killing off a bunch of processes, we'll have to opt for a more
streamlined mail reader in situations like this--e.g., "cat".

-Bob
From: wdc@athena.mit.edu (Bill Cattey)
Newsgroups: comp.soft-sys.andrew
Subject: Re: "slow networks"
Date: 28 Aug 92 22:52:00 GMT
Organization: The Internet

Craig, you're being more diplomatic than I deserve.
I confess, I am ignorant about most of the AMDS stuff.
I have only read some of the code, and perhaps drawn inappropriate
conclusions as to the design of the whole delivery system.

It is true I've not lived with it.

My bias (and tone) come from my (frustrated) attempt to figure out how
to do these things:

Make messages start up faster.
Simplify my configuration.
Enable netnews reading with messages.

I'd love to be able to read netnews with messages, but the prospect of
plugging nntp into the message server libraries proved too daunting.
I did attempt to read the code at the libms and the libcui layers, but I
just couldn't get it.  Everywhere I looked were all these special cases
that violated the abstraction barriers and got in the way.  Take the
problem of trying to decide if one should use an nntp connection or a
filesystem connection.  The library is so-structured that for every
operation you would perform, you have to include all the mail path
parsing code so you are able to pick either nntp or unix filesystem.

At the present time, it appears that I get to wait for one meg of
amsn.do code to be loaded in to my messages with internal message
server, so that I can ignore all the functionality, and read mail from
Mailboxdir, save it in .MESSAGES, and post it with sendmail.

There is truly a mismatch of functionality to my needs.  I allow myself
to use the user interface because I like it, but I pay in start up time
and in incompatibility with the other mail archiving formats.  Every
time I try to answer for myself, what the amsn.do code is doing, I get
hopelessly lost.

Forgive my inaccurate critique of the design.  I have misunderstood.  I
couldn't really find a client/server model in what I read.

-wdc
From: wdc@ATHENA.MIT.EDU (Bill Cattey)
Newsgroups: comp.soft-sys.andrew
Subject: Re: message line bogosity
Date: 27 Aug 92 04:37:12 GMT
Distribution: world
Organization: The Internet

I like the idea of dynamic resizing.

Currently the message line works very hard at shrinking itself smaller when you
enlarge it.  Example:  I visit a new file with a long path name.  I enlagre the
message line.  When the new file is read, since it's displayed in a new
"buffer" the message line goes back to the default size.  This too can
often be a lose.

Making everything be a dialogue box may or may not be a good thing.

Now that ATK has real pop-up dialogue boxes, maybe someone could code
one of those allegedly winning macintosh file dialogue boxes.  The ones
I've used on the Mac suck, but maybe a decent one exists somewhere.

-wdc
From: tinglett+@rchland.ibm.com (Todd Inglett)
Newsgroups: comp.soft-sys.andrew
Subject: Re: message line bogosity
Date: 26 Aug 92 20:32:13 GMT
Reply-To: "Todd Inglett" <tinglett@rchland.vnet.ibm.com>
Distribution: world
Organization: The Internet

Excerpts from ext.misc.info-andrew: 26-Aug-92 Re: messageline bogosity
Adam Stoller@RCHGATE.rch (1472+0)

> The only thing I can see that would be an improvement - is if
> the(vertical) size of the message-line were able to change on the fly -
> dependantupon the length of the message being displayed - and then
> automaticallydecrease in size again afterwards (heuristic needed)

I give this my vote for long messages.  This really shouldn't be
toodifficult--all you need to know is whether the message line is tall
because ofa long message, or because the user stretched it.  When the
next message isdisplayed, it could shrink as long as it wasn't
stretched.  In fact, I wouldprefer a keybinding that would ``reset'' it
back to one line so I can stretchit at will without having to mess with
it to put it back ``just right.''  Infact, this really means that the
message line could customized for height (#of lines) so a user could
have it 0 lines tall  and it would stretch up anddown as the message
line displays and is cleared.  I'd personally think thatbehavior would
be annoying, but screen-space lovers would probably like it.

I also would like a history (let 'em customize it like in typescript),
historyrecall and completion (again, like in typescript).  I can dream,
can't I?

-todd inglett