HDTenEightyP/NetNews huggingface dataset:
From: steve@taumet.com (Steve Clamage)
Subject: Re: Is this a Legal Way to Access a Specific Address?
Keywords: DSP, C, ANSI, Fixed RAM
Organization: TauMetric Corporation
Date: Thu, 28 Jan 1993 17:26:32 GMT

alan@elroy.Jpl.Nasa.Gov (Alan S. Mazer) writes:

>>>>We're programming a device that has a RAM cache at address 809800H.
>>>>Is it legal to address this memory in C as follows?
>>>>#define ON_CHIP 0x809800
>>>>...
>>>>   float *oc_ptr = (float *) ON_CHIP;
...
>>In all such cases, an integer *value* is being cast to a pointer type.
>>There are no literal pointer constants (except the null pointer) in C.
>>The results of casting an integer value to a pointer type are
>>implementation-defined and not portable.

>Okay, I'll agree with this.  But the net effect is the same.  If the constant
>fits in one of those types (if it doesn't we'll get a compile-time error),
>then the value can be usefully assigned to a pointer variable and used.  Note
>that this code obviously is unportable to begin with.  We're writing to a
>specific location in memory.  The danger in mixing pointers and ints is that
>either may be too short to hold the other.  In this case, assuming the poster
>knows what he's doing and isn't addressing outside his memory space, it's a
>moot point.  If pointers are too small to hold the address specified, he
>doesn't know what he's doing.  If they're not, then it works fine and there's
>no ambiguity.  In short, there is still no problem that I can see.

The problem is that you have no assurance that the compiler expects to
see machine addresses expressed as simple integers.  Compilers commonly
allow that but are not required to.  On a segmented or otherwise
complex architecture, an address might need to be broken into several
parts, and a simple integer value might not have the results you expect.

Just because the programmer thinks of the absolute machine address as
0x809800 does not mean that the compiler will recognize the address
when represented that way.  You have to read the compiler manual to
find out how machine addresses should be expressed.

Even on as common a machine as a PC I may have to jump through a few
more hoops to represent an address properly depending on the memory model.
For example, suppose I want to reference 1 byte at absolute address
0x1234.  If I naively write
	char *p = 0x1234;
it might point to the byte in my global data segment at offset 0x1234
rather than to absolute address 0x1234.  I need instead to do this:
	char far *p = MK_FP(0, 0x1234);
where MK_FP is a compiler-supplied macro which makes a far pointer out
of a segment and offset.  This isn't portable to any other system, but
the naive first attempt won't always work on a PC.

If I am programming on a Unix system, I can't get to absolute machine
addresses this way at all.  Every program address is a virtual address,
and I can't predict where the physical address will be.  I have to go
via the memory-mapping system to get to a machine address, and the
details vary with the flavor of Unix.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.dsp
From: lychou@elixir.e.kth.se (Leif Lychou)
Subject: 68HC16 C-Compilers
Organization: Royal Institute of Technology, NADA
Date: Tue, 26 Jan 1993 13:20:32 GMT

Hi!

Forgive me if this is not the correct newsgroup to post to, but I
could not think of any better one.

I simply wonder if there are any C-compilers available for the 68HC16
yet. I have been in contact with IAR Systems who developed a compiler
for the 68HC11 and the 8751, but they say that they have not yet
concidered developing a compiler for the 68HC16.

If any of you have information on this, I would appreciate if you let
me know.

Thank you

Leif Lychou

------------------------------------------------------------------------------
Leif Lychou  				 Email:
Departement of Electrical Engineering    UNIX: lychou@elixir.e.kth.se
Royal Institute of Technology             VMS: lychou@elin.e.kth.se
Stockholm, Sweden
-- 
------------------------------------------------------------------------------
Leif Lychou  				 Email:
Departement of Electrical Engineering    UNIX: lychou@elixir.e.kth.se
Royal Institute of Technology             VMS: lychou@elin.e.kth.se
Newsgroups: comp.dsp
From: janand@vela.acs.oakland.edu (Zombie Dude)
Subject: Hough Xform
Organization: Oakland University, Rochester MI.
Date: Thu, 28 Jan 1993 17:56:13 GMT

hi !
	I am working on a problem in Image Processing and have to
	deal with Hough Xform. My problem is more with inverse
	Hough Xform. Once the set of collinear points have been
	gathered by applying the HT, is there any algorithm or 
	thumb-rule to get back the possible set of straight lines
	which are represented by the set of collinear points.

	I would appreciate ur help and any pointers to sources.

	Thanks in advance.

J Anand.




-- 
!!!!!!!!!%-----+++++=====/**##!!!!!!!!!!!!!/**##=====+++++-----%!!!!!!!!
When you don't know what to do, walk fast and look worried.
!!!!!!!!!%-----+++++=====/**##!!!!!!!!!!!!/**##=====+++++-----%!!!!!!!!!
From: bobdavis@scumbag.viewlogic.com (Bob Davis)
Newsgroups: comp.dsp
Subject: programmable devices for dsp filter implementation
Keywords: filter
Date: 27 Jan 93 21:19:38 GMT
Organization: Viewlogic Systems, Inc.
Originator: bobdavis@scumbag


Seems to me a semi-purpose-built architecture for programmable DSP
filters would be a very useful alternative to either DSP processors
or totally custom design, at least in applications where the _type_
of filter to be used doesn't need to be maleable.  Potentially, the
performance, density, and/or cost could be better than the other
available approaches.

On the other hand, custom design with the right automation could be
made to be easy enough that it's not an issue for large production runs.
There is still the problem of development and prototyping, but this
could be done in other ways.

Thoughts or comments on this topic would be great.  Feel free to mail
me and I can summarize, or just chat on this group.  Cheers.
-- 
Bob Davis -- bobdavis@viewlogic.com
"Michael Bolten/Kenny G duets would be perfect for hostile interrogations."
From: marc@gauss.math.mcgill.ca (Marc Sokolowski)
Newsgroups: comp.dsp
Subject: Board/Software for Voice processing
Date: 21 Jan 93 16:04:35 GMT
Organization: Dept of Mathematics, McGill University


	Hi Everybody,

	I would be interested in having info about what Board/Software
combination (or package) can do voice recognition and synthesis on DOS or
UNIX based machines. I am new in the field (but I have already read some
literature, especially about the use of neural nets) and this is why I would
like to have some practical info. I will post a summary.
	Thanks in advance.

					Marc
Newsgroups: comp.dsp
From: picone@trdc001.trdc.ti.com (Joe Picone)
Subject: S-Bus C30 Boards For Sparcstation-2 With Sun OS 4.1.3
Organization: Tsukuba Research and Development Center
Distribution: comp
Date: Thu, 21 Jan 1993 21:59:40 GMT

Can somebody comment on C30 boards for the Sun?

My requirements are simple:

 (1) 1 S-Bus slot
 (2) 1 TMS320C30
 (3) Lots of memory - 512K bytes is ok - 2M is better - 16M ideal
 (4) Access to the serial port via an external jack
 (5) Sun 4.1.3 (or Sun 4.1.2) support
 (6) Software development tools (compiler, debugger, simulator...)
      under X windows or a tty mode
 (7) Hardware debugger under X windows or a tty mode
 (8) Audio module available?
 (9) SPOX not required

It has been a while since I looked at these, but I think Sonitech
and Pentek have products that meet some of these requirements.

Has someone recently published a roundup of the available boards and
environments?  What boards are people finding good/bad?

Thanks in advance.

----------------------------------------------------
| Joe Picone          | email: picone@trdc.ti.com  |
| Texas Instruments   | Phone: +81 298 501738      |
| Tsukuba R&D Center  | Fax:   +81 298 501729      |
| 17 Miyukigaoka      | Msg:   JP27                |
| Tsukuba, Ibaraki    | Alias: "The Terminal Man"  |
| Japan 305           |                            |
----------------------------------------------------





Newsgroups: comp.dsp
From: white@drwho.ee.ufl.edu (John White)
Subject: Need Opinions on Ariel DTK's
Followup-To: white@drwho.ee.ufl.edu
Keywords: Ariel, DTK's, 56001, 'C30
Organization: University of Florida, Electrical Engineering Dept.
Date: Wed, 27 Jan 93 16:30:25 GMT

I'm considering buying one of the low cost Ariel DTK's
for either the Motorola 56001 (DTK-56) or the TI 'C30
(DTK-C30 ?).

IF YOU OWN OR FREQUENTLY USE one of these kits, I'd 
greatly appreciate your opinions.  My questions are:

1. Would you buy it again now that you know its
   limitations, etc ?

2. Is it worth the $1300 to $1500 (w/out a C 
   compiler)...

3. Any other observations?

4. Obviously one is floating point, the other int.
   I'm leaning towards the 'C30.  Wise move ?


I'm a Ph.D candidate in EE (DSP/speech), and have
a strong professional audio background.  Application
of the board would be to learn more about DSP
assembly algorithms, and to find out about what
you can and cannot do with a single given DSP
chip and a PC platform.  My host platform is a
Gateway '486/33.

I'm pretty well versed on basic to medium-
level DSP _theory_, I'm just ready to get neck-
deep into DSP assembly, and am wondering what
hindsight previous folks can offer.

I also realize that the cheapest way is to build
my own PC board (plug-in or stand-alone), but I'm
not sure that I want to take the time to wrestle with 
the unfun tasks of host port interfacing, trouble-
shooting hardware, writing host drivers, and all
that other stuff. ... Thus the reason to buy
Ariel's package...

Note that this all will be paid for
from a small grant I got from the AES, so spending
$1500 won't wipe me out.  But I cannot afford more 
than this.

Please respond direct to me, and I will gladly post
results.  Thank you very much.

John White
white@drwho.ee.ufl.edu
Newsgroups: comp.dsp
From: jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
Subject: books
Reply-To: jeff@is.s.u-tokyo.ac.jp
Organization: University of Tokyo / Object Technology International
Date: Tue, 26 Jan 1993 09:53:30 GMT
Distribution: comp
X-Bytes: 1207

A while ago I posted looking for DSP books.  Thanks to everyone who
responded.  I've checked out a few of them and discovered that, while
they are useful, I may have expressed my main requirements
incorrectly.

I'm looking for books on signal processing applications (I guess?).
That is, I have a bunch of abstract data which I would like to treat
as a signal and apply various SP techniques.  The problem is that I
know relatively little about the properties of these algorithms.  Thus
I don't really know what is possible, desireable, easy, hard, ...

Ideally, I would find a book which had hands-on descriptions like "If
you have data like this, you can use these N techniques to get X
effects."  From what I've learned so far, things like filtering,
correlation, spectral analysis (FFT) and adaptive processing in
general are of interest in my domain.

I am not conducting SP research but rather would like to be a user of
SP.  The math behind it all is a bit off the topic for me but of
course, I'll try and learn what's necessary.

Thanks alot again.



--
ato de, |m        -- "Throughout my life I have sought peace and quiet"
                                                          - Ted Nuggent
Newsgroups: comp.dsp
From: gao@eecg.toronto.edu (Xiangyang Gao)
Subject: Email address of DSP product suppliers
Date: 23 Jan 93 18:43:49 GMT


Dear Netters,

I found that email is the most attractive way of communication: fast, 
economical, to-the-point, and easy-to-archive. However, it is not easy to 
get email addresses since email is not very commonly used (at least not 
as common as fax).

I volunteer to compile an email address for DSP hardware, software, and
firmware vendors for the people on this net.

Enclosed is a start. Hope it will attract good responses.
Contributions are cordially invited!!!
Please give a brief description of their products. (I didn't have descriptions
of products for two of the listed four vendors. I will add them later.)

Reply to gao@eecg.toronto.edu

Frank

The Math Works Inc.
24 Prime Park Way/Natick, MA 01760
Tel (508) 653-1415, fax (508) 653-2997
email info@mathworks.com

Zola Technologies, Inc.
6195 Heards Creek Dr., N.W.
Suite 201, Atlanta, GA 30328
Tel: (404) 843-2972
Fax: (404) 843-0116
Internet: ZOLA@AppleLink.Apple.com
AppleLink: ZOLA
Product: DSP Designer, a software package on MAC.


Entropic Research Laboratory, Inc.
600 Pennsylvania Avev., SE, Suite 202
Washington, DC 20003, USA
Tel: (202) 547-1420
Fax: (202) 546-6648
email: esps@wrl.epi.com
Products: ESPS and xwaves. Both run on unix.

Integrated Systems
3260 Jay Street
Santa Clara, California 95054
Tel: (408) 980-1500
Fax: (408) 980-0400
email: xmath-info@isi.com

Newsgroups: comp.dsp
From: dsp_applications@analog.com
Subject: Re: Email address of DSP product suppliers
Originator: levine@bambam
Organization: Analog Devices, Inc.
Date: Tue, 26 Jan 1993 13:49:23 GMT

One more for the list:

Analog Devices DSP
1 Technology Way
P.O. Box 9106
Norwood, MA  02062-9106

DSP Applications Assistance Line: 617.461.3672
DSP Fax Line: 617.461.3010

DSP Bulletin Board System 
(up to 9600 baud v.32): 617.461.4258

e-mail: dsp_applications@analog.com


Note: Also newly introduced:
The Signal Computing BBS:
617.461.4259
(up to 14.4kbps, MNP compression)


-------------------
Noam Levine
Analog Devices DSP



Newsgroups: comp.dsp
From: yatrou@INRS-Telecom.Uquebec.CA (Paul Yatrou)
Subject: Re: WANTED: Info on TI's MWave DSP chip
Organization: Bell-Northern Research Montreal, Canada.
Date: 21 Jan 93 19:12:16 GMT

In <1jl489INNa58@uniwa.uwa.edu.au> pdcruze@tartarus.uwa.edu.au (Patrick D'Cruze) writes:

>I am after some info on Texas Instrument's MWave DSP chip (also known as
>the TMS320M500 ?).
>
>I contacted the local TI distributor the other day but he had no idea
>that the chip even existed (does it?) and he hasn't been able to get any
>info on it for me.

Not sure if the chip exists yet, but there is a product bulletin out by TI
on the "MWave Multimedia System" for IBM/PC Windows and OS/2 applications.
There's also a technical  brief out on the Mwave Multimedia system which
describes the TMS320m500 dsp. So i guess it exists...

I've had both items since beginning of January 93.
Maybe you can contact TI in the U.S. for info, if your local rep doesn't
help...

Paul Yatrou.
From: e-hung@ampex.com (Eric Hung)
Newsgroups: comp.dsp
Subject: Re: Newbie Question
Date: 25 Jan 93 18:19:01 GMT
Organization: Ampex Corporation, Redwood City CA


You can order creative lab 's SB development kit. It contains
some C library functions for you to manipulate data with a 
sound file.

I have tried using that to do some signal processing stuff. Remember
SB VOC format is only 8 bit and the board itself doesn't have good
shielding for A/D input. So don 't be suprised if your data has a
high noise floor (about 45 - 50 dB). 

If you do it for fun, sound blaster is quite adequate. But you
are serious then I suggests using Turtle Beach or Pro Audio Spectrum 16.
SoundBlaster did come out with their 16 bit ASP board. But again, when
I check out their board, I don 't see they do a good job in shielding the
analog ground plane.
 
If you are doing signal processing stuff just for fun, I think SB is an
inexpensive solution. I have done something like sampling frequency 
conversion, time compression and expansion. It 's really fun. 
Newsgroups: comp.dsp,comp.lang.c
From: scotty@verdix.com (Scott R. Chilcote)
Subject: Is this a Legal Way to Access a Specific Address?
Summary: Assigning Pointer = Constant
Keywords: DSP, C, ANSI, Fixed RAM
Organization: Lack Thereof
Date: Sat, 23 Jan 1993 04:26:26 GMT

Hi Folks!
 
We're programming a device that has a RAM cache at address 809800H.

Is it legal to address this memory in C as follows?

#define ON_CHIP 0x809800

int main(void)
{

   float *oc_ptr = (float *) ON_CHIP;


Our device-specific ANSI C compiler lets us do this in order to address the
on-chip memory, without a warning.  The emulator shows that it works.  I've
looked in several textbooks, however, and I've never seen mention of setting
a pointer equal to a constant in order to define a specific address.  Even the
new K & R book doesn't mention if this is legal.

Does anyone know if this is acceptable coding, and what kinds of problems could
crop up from using this method?

The other way we can achieve the same result is using the linker for this 
device to declare a section of memory at a specific address, and associate
a label with the section.  We can then use that label with an external pointer
declaration in the C program ( extern void *on_chip; ) to reference the 
specific address we need.  This method requires more CPU cycles than the one
above to resolve pointers, but at least the address space we're using is 
declared in the linker's memory map.

Note that this device has no operating system to speak of, so we're free to 
access all address space with impunity.

Thanks for any help!


-------------------------------------------------------------
Disclaimer: I do not represent Verdix Corporation, and my
postings do not represent their opinions.  
-------------------------------------------------------------
                                            Scott R. Chilcote
                                            scotty@verdix.com  - or -
                                            scotty%verdix.com@uunet.uu.net
From: anadeem@ampere.bit.listserv.tech-l (Ahmed Nadeem)
Newsgroups: comp.dsp
Subject: Edge Detection And Segmentation Using Khoros And PV-WAVE Software
Date: 27 Jan 93 07:54:11 GMT
Article-I.D.: ampere.ANADEEM.93Jan27005411
Distribution: comp.dsp
Organization: /home/ampere1/anadeem/.organization

Netters,
        I am currently working on a research project that involves generating
solid or geometric models from MRI images. Part of the procedure will require 
me to possibly perform Thresholding & Edge Detection on my MRI images in order
to find out which pixels lie on boundaries between two different regions. 
Thus, I would like to have an Image Processing Software package that has good 
Edge Detection and Classification ( Segmentation ) modules/routines.  
        I have heard a lot about Khoros ( University Of New Mexico) and 
PV-WAVE (Precision Visuals) and was curious if other professionals or students
had any experience on how good they are for the above purposes. Suggestions 
on other software packages are also much welcome.
                                                       Thanks,
                                                              Ahmed Nadeem
Newsgroups: comp.dsp
From: johned@cix.compulink.co.uk (John Edwards)
Subject: Re: Email address of DSP product suppliers
Reply-To: johned@cix.compulink.co.uk
Date: Mon, 25 Jan 1993 19:35:00 +0000


TITLE: Re: Email address of DSP product suppliers

Loughborough Sound Images can be contacted as follows :

Loughborough Sound Images
The Technology Centre,
Epinal Way,
Loughborough,
Leics. LE12 8LW UK.

Phone : +44 509 231843
Fax : +44 509 262433
email : johned@cix.compulink.co.uk

Newsgroups: comp.dsp
From: 4389750@mcimail.com  (TMS320 Hotline)
Subject: TI DSP C compiler 4.4
Nntp-Software: PC/TCP NNTP
Organization: Texas Instruments Materials and Controls Group
Date: Fri, 22 Jan 1993 04:00:09 GMT

In message <1j4nk6INNrt7@elroy.jpl.nasa.gov>, a request for release notes for
v4.4 of the TI TMS320 C compiler was made.

The compiler has been updated and the latest release is v4.5. The correct
procedure to receive the updated version is to fill out the registration card
you received with the compiler and return it to TI. Registration will entitle
you to one year of free upgrades from the date of purchase.

--
Regards,
TMS320 Hotline
(713)-274-2320       (voice)
(713)-274-2324       (fax)
(713)-274-2323       (BBS 300-9600,8,N,1)
4389750@mcimail.com  (Internet)


Newsgroups: comp.dsp
From: mek@guinan.psu.edu (Mark E. Kotanchek)
Subject: Mathematica Remez-Exchange Filter Design?
Organization: Penn State Center for Academic Computing
Date: Mon, 25 Jan 93 19:09:31 GMT

Howdy,

I was wondering whether any of you folk knew of a Mathematica notebook or  
package which did a Remez-Exchange/Parks-McClellan filter design. Right  
now I use Matlab on my Powerbook but my life would be easier if I could  
use Mathematica on my NeXTstation.

I posted this query to the Mathematica Users Group and got e-mail  
expressing interest in my findings...but, alas, no findings!

Thanks much,

Mark.
--
Mark Kotanchek
Guidance & Control Dept - 363 ASB
Applied Research Lab/Penn State
P.O. Box 30
State College, PA 16804

Newsgroups: comp.dsp
From: rosenkra@convex.com (William Rosenkranz)
Subject: Re: WANTED: Audio Effects Pro
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Mon, 25 Jan 1993 05:15:25 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <gate.g2BVXB1w165w@sytex.com> mbenson@sytex.com (Michael Benson) writes:
>
>JTS>    In an attempt to implement a multi-effects processor using a 486 an
>JTS>    Essentially what I'm looking for are proven algorithms or good refe
>JTS>                -flange
>   >                -chorus
>   >                -pitch shifting
>   >                -hall-type reverb
>
>Did you get many responses?  I would be interested in any of this
>information as well.

i found on atari.archive.umich.edu a DSP56001 assembler (with C src) that
includes 56k code for flange, chorus, and reverb. the file was:
	atarist/Newitems/as56.zoo
Newitems is a directory which holds new FTP posts for a few days so it
might find itself in another directory soon. there is an ls-RF.Z file
which should help locate it. i can't vouch for the code since i have
no way to test it. the algorithms seem reasonable, however. some of the
effects code was supposedly ported from csound (from MIT).

FYI: the new atari falcon has a DSP56001 in it, hence the assembler. there
was a mini review of the falcon in the feb Byte i believe.

-bill
rosenkra@convex.com

-- 
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: rosenkra@convex.com
Newsgroups: comp.dsp,comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Is this a Legal Way to Access a Specific Address?
Keywords: DSP, C, ANSI, Fixed RAM
Organization: TauMetric Corporation
Date: Mon, 25 Jan 1993 17:00:44 GMT

>In article <1993Jan23.181029.29389@uvm.edu> wollman@sadye.emba.uvm.edu (Garrett Wollman) writes:
>
>The ANSI C standard
>*does* guarantee (I believe, not having a copy handy) that there is
>some flavor of integer that can be cast back and forth to a pointer
>type. 

Not quite.  It is legal to cast an integer value to a pointer type,
and legal to cast a pointer value to an integer type.  The results
are implementation-defined, which means that such code is not portable.

Further, it is not guaranteed that there exists an integer type which
is large enough to contain all the bits in a pointer.  For example,
implementations with 48-bit pointers and 32-bit longs exist, and
are allowed by the C Standard.  Similarly, there are implementations
where pointers cannot contain all possible integer values, and this
is also allowed.

Implementations commonly allow casting back and forth between ints
(or longs) and pointers, but you have to check the compiler manual
to see what is actually supported.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.dsp