Path: utzoo!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!sdd.hp.com!think.com!mintaka!ogicse!ucsd!sdcc6!sdcc13!cpenrose
From: cpenrose@sdcc13.ucsd.edu (Christopher Penrose)
Newsgroups: comp.sys.next
Subject: Re: Help needed getting 4096 pt. FFT to work on DSP
Summary: too big
Keywords: FFT, dsp, 56001, 68040
Message-ID: <17334@sdcc6.ucsd.edu>
Date: 8 Mar 91 20:34:01 GMT
References: <7MAR91221326@uazhe0.physics.arizona.edu>
Sender: news@sdcc6.ucsd.edu
Distribution: usa,local
Organization: University of California, San Diego
Lines: 24

In article <7MAR91221326@uazhe0.physics.arizona.edu> zazula@uazhe0.physics.arizona.edu writes:
>
>I can run this program for 1024 data-points.  2048 kills it (it just
>sits there).  Is 2048 points too many for the data space of the DSP?
>Could I reduce the size of the sinTab and cosTab arrays?  How can I
>get up to 4096 data points?  (I'd like to take my 2048 points and 
>zero pad out to 4096...).

Sorry, there just isn't enough data space for a FFT with a size greater
than 1024 elements.  You can add more memory dsp ram however.  I am not
sure if they managed to get dma working with the NeXT 2.0 software or 
not.  With the 68040, floating point FFTs do not need to be scaled down
to 24-bit integers; hence, if you are converting floating point data, a
generic C FFT is not only faster than a dsp 56001 FFT, but it also provides
better amplitude resolution, and is much easier to code and interface.  Also,
you have the facility of larger N sizes.  If the dsp chip were a 96000, 
I gather that I would have to take all of this back.  If you are willing to
brave assembly code, you could hand-optimize a floating point FFT algorithm 
for the 68040.  Wow, if you did this, I would definitely be your friend :)

Christopher Penrose
jesus!penrose