Standard Configuration for Radar Systems

From: Jeff 
Subject: Re: DSP questions
To: You 
Date: 04/16/00

You -

>OK, Let me explain more about our system.  >(Current system that we have :
SBC K2-400MHz with PC104 & PC104 PLUS, and A/D 500KHz SE PC104.)

Problem:  the above A/D board does NOT connect directly to DSP board.  So this 
means that K2 processor must read data from A/D board, then write data to DSP 
board.  This "double bus transfer" is very slow, and will damage performance.  
A/D board must connect and transfer data DIRECTLY to DSP board -- this is the 
standard configuration for radar systems.

For standard radar systems in PC/104 format, the A/D board connects to PC/104 
only to get power and gnd signals; all data signals go through different 
(dedicated) connector to DSP board.
 
>I want to take FFT of FMCW radar signal and compare with FFT of radar without a 
>target (0 degree).  Depending on the target appearance, there will be difference 
>between the two FFT spectrum.  

Ok.

>Radar signal: lowpassed signal  freq=0~30kHz.  A/D 12 bit 500KHz with 8KFIFO 
>PC104 based by  rtdusa.com  model 6420-8.  Radar scans +15 degree to -15 degree.  
>I try to sample around one degree ( 1ms for around 1 degree).
>500KHz for 1ms ->  500 samples for a degree.  I want to do 0.5k FFT so that 
>30KHz/500 is around 60Hz resolution. (??)
>Radar scanning frequency is 10Hz (1Hz means = move from –15  degree to 15 
>degree and back to –15 degree)

Ok, 512 input points for each FFT.  I recommend that you do two (2) 512 pt. 
FFTs, with 50% overlap and Hamming window.  This will avoid "edge noise" and 
give you better SNR in frequency measurement.  You might also try using 1024 pt. 
FFT size, with some zero-fill over 2nd 512 pts.  This would improve Hz/pt resolution.

>There are few ways to sample:
>(1)
>I can sample 0 to +15 degree (25ms)  and use next 25ms as processing time when 
>radar moves from +15 to 0 degree.
>It samples 0 to –15 degree every degree (25ms), and use next 25ms as processing 
>time when radar moves from -15 to 0 degree.
>Also, I can use the 2nd scanning time with out sampling 100ms.  If I do not 
>have enough time, I can use one more 100ms for processing time.

So every 25 msec means (25) 512 pt. FFTs.  This may be very close to limit for 
Texas Inst. C44 DSP running at 60 MHz.  512 pt. real FFT on 60 MHz C44 requires 
just less than 1 msec, so it may be possible, but the 50% overlap may not be 
possible.

>12 bit  500KHz.  rtdusa.com 6420-8  8K FIFO  PC104 based.

Ok, see comments above.  I have checked the RTD 6400 series and other boards, 
and they do NOT have dedicated DSP connection for data transfer.

>I am going to use single channel.  It has 16 SE channel.

These are not independent, separate channels; these are multiplexed channels.  
For example, if you use 2 channel, then maximum sampling rate is 250 kHz; if you 
use 4 channel then max Fs is 125 kHz, etc.

>I do not use analog output

Ok.

>If DSP board has PC104, it can be connected directly.  I do not know about 
>software support yet with direct connection with a DSP.

Again, see comments above.  PC/104 bus SHOULD NOT be used to transfer data to 
DSP; this method is extremely slow and will impact the FFT performance.  Here is 
another explanation:  PC/104 bus rate is same as ISA bus, about 750 kbyte/sec 
maximum data transfer rate.  If you have 500 kHz 12-bit data, then this is 1 
Mbyte/sec transfer rate, which exceeds bus capability.  So PC/104 bus is not 
good choice for 12-bit data being sampled more than 300-400 kHz.

Also, if you use 8K FIFO to avoid data transfer rate problem, then you still 
have two problems:

  -excessive delay after data is acquired until it is processed  (16 msec)

  -still must drop every other 25 msec frame, because effective data rate is faster
   than bus transfer rate.  This means you cannot do successive 25 msec frame, but
   only frame 0, 2, 4, etc.

>Only target distance and angel information will be out to serial port through 
>RS232 with 9600Kbyte speed

That's not what I meant.  I only meant group delay between analog input and 
output.  Since you have no analog output in the system, this is a non-issue.

>First, I am going to develop the DSP with a SBC with PC104 base. Since it is 
>easy. The SBC has video and everything.  If it is impossible to make stand alone, 
>I will leave the SBC with A/D & DSP with out a hard drive disk since it can 
>be damaged easily. To have a system with out hard disk, I have to download the 
>executable to a flash memory

Ok.

>For the final product, I better have a stand alone since it will save a unit 
>price.  First, I have to show that my system is working with the SBC, then 
>stand alone system.

Ok.

>The SBC (VSBC 6 by versalogic.com) has AMD K2-400MHz 128MB.  Spec. is following:
>8 to 128 MB system RAM, 256 KB level 2 cache, 32-pin DiskOnChip site, 10BaseT 
>Ethernet interface, PCI based video, Flat Panel Display support , PC/104-Plus 
>expansion site (can be used with PC104), Dual PCI based IDE controllers, Dual USB 
>interfaces, 4 COM + 1 LPT port

This sounds fine.

I suggest you re-consider SigC44-PC/104 board plus AIX module plus adapter 
board, as documented in previous e-mail.  AIX module has 4-channel 16-bit 1 MHz 
input; each channel is independent, separate A/D converter.

> 9600Kbyte serial RS232 output that I needed.  It received a request signal 
>from a MAIN PC, and transfer target angle and distance information.   (High byte 
angle: low byte angle: High byte target distance : low byte sistance).  
>The format might be change.

Ok.

Thank you for the excellent system description.  I understand much better now 
what you are trying to do.  I think you must decide between dedicated analog 
input to the DSP.  The other choice is to not use DSP board at all, and allow K2 
processor to do FFT processing; maybe in this case the 8K FIFO will work and the 
K2 can process data fast enough.

Jeff Brower

Develop FFT with C Code vs Assembler

From: Jeff 
Subject: Re: msgblast.ocx and FFT questions
To: Lionel 
Cc: Yolanda 
Date: 07/06/99

Lionel-

>Hi Yolanda,

>Concerning the FFT computation, I would like to know if your 
>software allows me to develop the FFT with C code instead of assembler.

Yes, in the DSP (SHARC) code, you can replace the current FFT .asm function with 
a C version.  There are two (2) things you would have to worry about:

 1) Calling C function from .asm code.  If you want to maintain full
    compatibilty with Hypersignal (or use Hypersignal to test your
    new FFT.c function), then you should modify modul3.asm to call
    the new C function.  The main concern is pushing parameters
    onto the stack before calling the C function, then re-adjusting
    the stack after the function returns.

 2) Your C version should accept the following parameters:

      pRIData
      nFFTSize
      nFFTOrder
      nFFTDir

    where pRIData is a pointer to real/imaginary input data, which is
    a buffer with values stored as R,I,R,I..., nFFTSize is the length
    of the FFT and should be a power of 2 (i.e. nFFTSize = nFFTOrder^2),
    and nFFTDir is -1 for inverse FFT, and >=0 for forward FFT. Note
    that output data is also stored at pRIData as M/P/M/P, or
    alternating magnitude and phase values.

Note also that the current .asm version that you have is doing a "decimation-in-time" 
algorithm, which means it FFTs first, then bit-reverses afterwards.  

Jeff Brower

Packing Multichannel Data

From: Jeff 
Subject: Re: packing multichannel data
To: Scott 
Date: 08/03/99

Scott-

>Thanks for the last email. I've got that squared away now.

Ok.

>Now for multiple inputs it is stated in the doc that the input would be arranged as tr0, 
>tr1, tr2, tr0, tr1, tr2, etc for 3 channel input.

Yes.

>Before I can take the FFT of a frame, it seems that you would have to
>pack them in linear arrays to feed as input to the function(s).
>Is this correct? is there an efficient way to handle this with a DS call?

Do you mean in DSP code or host code?

In either case, yes you need to "de-multiplex" the analog input data 
and arrange into single channel arrays before calling fft or other functions.  
In the DSP code, you can set variables like:

   ribufk  (starting address)
   fftsiz  (fft size)
   fftord  (fft order)

and call the fft function, which is an optimized asm. version, located in fft.s file. Note 
that you have to set the above variables in your C code first, I think something like:

  void fft();
  extern long int ribufk, fftsiz, fftord;

  ribufk = (long int)&my_array[0];
  fftsiz = 1024;
  fftord = 10;

  call fft();

would work, but I know it's not exact.  Note that if your array is less than the 
fft size, you should "zero fill" the remainder, since the fft function only 
works with array sizes which are powers of 2.  Also, there may be a need to 
window data prior to the fft in your algorith.  The window function 
(window.s file) can handle this.

Jeff Brower

Memory Address Specifications

From: Jeff 
Subject: Re: your code
To: Gilles 
Date: 09/10/99

Gilles-

>I have a problem with your code because I don't understand where you 
>specify the memory adresses of the different sections. I don't 
>understand what do the ".DEF".  I don't understand where are the 
>input and output of the FFT/IFFT (where are they in the memory?) 
>Is the number of points prescibed (128, 256...) or not?

...  The real/imag data (input data for FFT/iFFT, and also output data 
for FFT/iFFT) is stored at the pointer specified by "ribbfk" variable.  
For example, if ribbfk = 0x1000, then R/I data is stored at 0x1000.

The size of the FFT is in variable "fftsiz".  If fftsiz is set to 1024 (and 
ordval is set to 10) prior to calling fft, then size is 1024.

So you need to set:

  ribbfk
  fftsiz
  ordval
  fdrval  (direction, 0=FFT, 1=iFFT)

prior to calling FFT/iFFT.  ...  You can probably eliminate the stuff at start 
and end about storing status registers in NSTAT.  This is used for real-time 
implementation, where we do not want the FFT to cause any problem with interrupts 
or analog I/O because it changes ST register bits.

>And now the t54BEG file. This file seems very big and I think there are a 
>lot of things not useful for my application. What is the signification of all 
>these variables at the beginning and wat are these differents modes at the end?

I only included t54beg.asm because of the small amount of initialization for the 
FFT routine.  Look for the label "fftini".  There are just a few lines that 
matter having to do with STFOR1 and STFOR2 variables; you can ignore the rest fo 
t54beg.asm.  These lines have to do with initializing a few instructions inside 
the FFT routine.  We do this method so the routine is fast and does not change 
if the size of the FFT changes.

As for the variables at start of t54def.asm, these are "DSP properties" set by 
the host.  You have to remember I sent you a small part of a larger software 
product called the C54x Source Code Interface (SCI), which is used by Hypersignal, 
Real-Time Composer™, and DirectDSP software.  DSP properties are shared 
variables between host and DSP which both instruct the DSP on what to do and 
what mode to operate, and also provide status and monitoring for the host.

>Perhaps can I explain you what I must do with your program.  First I must 
>stock any data in a memory place. When I have stocked for example 100 bits, 
>the processor give an interruption and go to a subroutine where is your 
>IFFT source.A combination of the 100 bits are the input and I must send the 
>output plus any samples. At the reception, I must stock the signal and execute 
>your FFT code on it.  Excuse me for the trouble, but can you please show me 
>a concrete example of your code to operate on the DSKplus card? And 
>can you please give me any expalanations about my differents questions?

To give you this example, including analog input and analog output, with FFT in 
the middle, would be more or less the whole C54x SCI.  

Jeff Brower

Buffer Structure for isr5.asm

From: Yolanda 
Subject: Re: Need some explanations
To: Lionel
Date: 10/04/99 

Hi Lionel-

>I would like to know how can modify isr5.asm in order to have 3 buffers instaed 
>of 2 buffers and 2 buffer of FFT. In fact we want to do the overlapping FFT in this way:
>We want 3 buffers for time acquisition of FFTSize/2 length, let's call them D1, 
>D2, D3.  For the first time, D1 is filling, we wait for D2. When D2 is ready, we compute 
>FFT on D1 and D2 while D3 is filling. When FFT ready, we bring back to the PC 
>FFT1 and D2. When D3 is ready, we compute FFT on D2 and D3 while D1 is filling. 
>When FFT2 ready, we bring back to the PC FFT2 and D3.
>When D1 is filled, we compute FFT1 on D3 and D1. and so on....
>
>We will have a FFT with 50% overlap.
>
>Do you think it's a good way to do that ?
>
>Can you tell me how can I modify the isr5.asm in order to have 3 analog buffers.

We suggest you keep the 2 buffers structure that isr5.asm is now and use the 
method that we had suggested to you previously.

Please refer to the e-mail that I sent to you on Sept1, 1999.  It also include a 
FFT.DOC that depicts the implementation graphically.

Yolanda

Modify modul5.asm To Do 8 Channels FFT

From: Jeff 
Subject: Re: 8 channels FFT
To: Lionel 
Cc: Yolanda 
Date: 10/04/99

Lionel-

>I tried to modify modul5.asm in order to do a 8 channels FFT.
>Here's what I did :
>For the first time, RIB_1 and RIB_2 are equal to RIBUFK.
>After the first loop, RIB_2 is equal to RIB_1 + 2*FFTSIZE.
>After the second loop, RIB_2 is equal to RIB_2 + 2*FFTSIZE
>And so on...
>
>I suppress the lines concerning the transfert function.
>
>But when I run my program, it crashed.

A quick reply:

Don't worry about RIB_2.  It is only used for transfer function, and you are not 
using this (at least that's my understanding).  Either comment-out the 
references to RIB_2 or just make it the same as RIB_1.

Additional input channels are stored in interleaved format in the ANABFK analog 
input buffer area, so you have groups of 8 channels inside each analog buffer:

  ch0,ch1,ch2,ch3,ch4,ch5,ch6,ch7,ch0,ch1,ch2...

Then in the channel loop, each channel is extracted from the analog input buffer 
and moved to RIBUFK.  Only one channel at a time is processed by FFT, magnitude, 
sqrt, phase, arctan, etc. at one time.

The results are then stored in the MPBUFK magnitude/phase output buffer area (in 
spaout.asm), also in interleaved format, for example:

  Mch0,Pch0,Mch1,Pch1,Mch2,Pch2,Mch3,Pch3...

where M is magnitude (linear or log, depending on LOGFLG properties) and P is phase.

So one problem you need to watch out for is that there is enough room in the 
MPBUFK area; your host program has control over this, because it sets the value 
of the base addresses for all of the buffers.

My suggestion would be to try first THREE channels, and see what happens.  See 
if you can get from 2 to 3 channel operation without a crash, and verify that 
all memory areas are correct.  Then continue to take more steps.  What is the 
FFT size you are using?  Enough memory could become an issue; the Blacktip SHARC 
has 64k x 32 onchip memory available total, for both program and data.

Jeff Brower

Compute FFT on Board

From: Jeff 
Subject: Re: FFT computation
To: Lionel
Cc: Yolanda
Date: 08/25/99

Lionel-

>I'm using the acquisition capacity in my onw program and it seems to work!!! 
>Yesterday, I change my PC, now I don't have a Gateway anymore. But I 
>have another problem to be solved :
>I want to compute FFT on the board and I want to pick up either time data 
>and FFT data. How can I do this with your software without having to write 
>it in assembler code because I don't want to do assembler code.
>Please, Tell me how can I do that ?

Here are some brief notes, I think Yolanda can add more info later today:

1) Change the 2106x code operating mode to 5, which is "Spectrum Analyzer" mode. 
This means setting the "DSP_OPMODE" property to 5.

2) Note that in mode 5 (and also in mode 2, digital scope mode) after each 
buffer ready message, and GetMem() call, you have to toggle the buffer number 
and notify the 2106x code by setting the DSP_HOSTBUFNUM property to the new 
buffer number value.  For example, in the spcana.cpp code located on 
\dspower\hwlib subdir, you should see something like

  bufnum = 1 - bufnum;
  DSPutHVarMem(hBoard, DSP_HOSTBUFNUM, bufnum);

or similar.

3) The spcana.cpp code has some general initialization and other examples which 
you will need to port into your VB strip32 program to get the mode 5 working.  
Look for any property set calls, window data initialization, and other 
initialization required for Spectrum Analyzer operation that you see in 
spcana.cpp that you don't already have in your strip32 program.

4) When reading data after each buffer ready message (i.e. GetMem call), you can 
read time data at time domain buffer location, and linear magnitude data at freq 
domain buffer location.  For example, if you had initialization code which 
(before RunProcessor) which did:

  Dim tim_addr As Long
  Dim mag_addr As Long

  tim_addr = DSGetHVarMem(hBoard, DSP_TIMDATAADDR)
  mag_addr = DSGetHVarMem(hBoard, DSP_MAGDATAADDR)

then later in your buffer ready message handler, you might do:

  Dim TimeBuffer(MAXBUFLEN-1) As Integer
  Dim MagBuffer(MAXFFTLEN/2-1) As Integer

  ret = DSGetMem(hBoard, DS_GM_LINEAR_DATA, tim_addr,
                 DS_GM_SIZE16, TimeBuffer(0), buflen)
  ret = DSGetMem(hBoard, DS_GM_LINEAR_DATA, mag_addr,
                 DS_GM_SIZE16, MagBuffer(0), FFT_size/2)

to read the time data and then the linear magnitude data.

5) I will double-check with Yolanda to see if you need any new file updates.  I 
think she has sent you a file update about 2 weeks ago.  It may be that we 
should send you another one (hsmacro.zip, ad2106x.zip) just to be sure.

6) We have continued to add functionality to the 2106x Source Code Interface, 
and the last report I had is that everything--all functions--are now fully 
implemented, with the one exception being real-time digital filtering.

Jeff Brower

Several Arrays in Output Parameter

From: Yolanda 
Subject: Re: A question
To: Lionel 
Cc: Jeff 
Date: 08/31/99

Lionel-

>In the userproc, how can I put severals arrays in output parameter.

I think Jeff explained earlier about using mode 5, which is Spectrum Analyzer, 
which I think you mentioned is needed in your application; please see copy of 
e-mail below (sent on Aug 25).  Userproc is used in mode 6; I don't think you 
want to use this if you need Spectrum Analyzer.

>In few words, I want to cut my buffer in several pieces and give it to my GUI.  
How can I do ?

Please explain more about your application.  As you can see from Jeff's e-mail, 
you can get a frame of time data, linear magnitude data (freq domain), or both, 
each time your VB program receives buffer ready event.  Do you mean you want to 
show the user one frame of same data, with continuous update?  Or multiple frames 
of different types of data?  Please explain more about your desired user-interface.

What controls are on the GUI?  What displays with what data?  How often is the update rate?

With regards,
Yolanda

Algorithm Language

From: Jeff 
Subject: Re: FFT Overlap
To: Lionel 
Cc: Yolanda 
Date: 09/03/99

Lionel-

>Is the GetSymbolAddress a Visual Studio procedure or a signalogic one? Where 
>can I find it ?

DSGetSymbolAddress is in hwlib32.bas (\dspower\hwlib\vb).  It has the form:

  ret = DSGetSymbolAddress(hBoard, filestr, symbolstr)

where filestr is the name of the DSP program (executable) file.  To use the 
currently loaded program file (i.e. file previously downloaded by DSLoadBoard or 
DSLoadProcessor call), set filestr to 0 (NUL).  symbolstr should be the name of 
a variable or buffer/array in your 2106x .asm or C code, for example 
"_input_buffer".

>Do you mean that when I will want to code my own algorithm such as source 
>separation or other signal processing algorithm, I will be obliged to code all 
>of them in asm ???

It depends.  First, you definitely do not want to get in a situation where you 
use the DSP board for some processing, bring data up to the host, and then send 
data back down again to the DSP board.  Board transfers over the ISA bus will 
become a bottleneck--much slower than either the DSP or the Pentium.

Second, for time domain data, prior to FFT processing, I would say the answer to 
your question is "yes", because the DSP is definitely going to most efficient at 
taking A/D samples, processing (adaptive filtering, difference equations, etc.) 
then doing FFT.

Third, after FFT processing, or after some amount of time domain processing 
(maybe when DSP limit is reached), things get into "grey area".  Certainly an 
MMX Pentium is extremely powerful, and Intel offers the "Native Signal 
Processing" (NSP) library at no charge (download from Intel website).  NSP is a 
C callable library which invokes MMX .asm language instructions on the Pentium 
to do basic DSP things; making VB header files for the calls is not a problem.  
MMX instructions are used extensively for "Win modem" and MP3 and other PC-based 
processing, but they do tend to bog down the PC, and note also that these are 
1/2 channel maximum "consumer" applications.  For example, we have one 300 MHz 
PC here with a WinModem, and quite a few things, like delayed disk access, too 
many programs running at once, etc. will cause the WinModem to drop carrier--it 
just doesn't get enough CPU cycles.  Certainly there comes a point when 
offloading time domain processing and FFT processing to the DSP makes a lot of 
sense--one of those situations is certainly 8-channel processing, which is what 
must happen in your application.

Also, there is the question of development (prototype) vs. final system.  To 
make sure things are working, it is faster to do some post-processing (say for 
example after FFT) on the host, then later work to move as much processing as 
possible to the DSP board, making the final system as efficient and "smooth" as 
possible.

Jeff Brower

FFT Overlap: .cpp vs .asm

From: Jeff 
Subject: Re: FFT Overlap
To: Lionel 
Cc: Yolanda 
Date: 09/03/99

Lionel-

>I receive your mail about the overlapping FFT but I still have a problem.
>
>I bought your software in order to AVOID CODING IN ASSEMBLER. I'm not used to 
>program in assembler and my project in so in late that I haven't time to learn 
>assembler and to study your .asm.
>Does it exist a way to program in C and to compile code in asm with the 
>software of the DSP from Analog ?

Yes, you can code in C, but the performance will be decreased.  Also, when 
calling .asm functions from C, the .asm functions often have to be modified (to 
save registers, use different calling parameter method, etc.) so you have to 
code in .asm anyway.  Generally, once you start programming DSP device in C, it 
is difficult to avoid requirement to learn about the underlying .asm language.

>I hope there's another way.

My suggestion is this:

  -for now, do not use overlap, use the FFT output from
   mode 5 as-is, and get your application working, including
   operator-interface

  -at the same time, hire Signalogic to add overlap to the
   mode 5 code, with a new DSP property that you can use to
   enable/disable the overlap and another new DSP property
   which specifies the address of the second result buffer
   (because for each buffer-ready event, there will be 2 FFT
   output frames available)

Jeff Brower

Array Allocation In DSP Memmory

From: Jeff 
Subject: Re: FFT Overlap
To: Lionel 
Cc: Yolanda 
Date: 09/03/99

Lionel-

>All I want to know is this :
>
>I've got C runtime library from Analog which propose a FFT algorythm. My idea 
is to put the DSP in mode 6 so as to call Userproc.c
>Once in the userproc procedure, i want to call Analog FFT. then I want to 
allocate an array in the DSP memory (how can I do that ?).
>
>At last I want to give this array to my PC.
>
>The important question is : HOW CAN ALLOCATE AN ARRAY SUCH AS DSP_TIMDATAADDR 
IN THE MEMORY OF MY DSP AND HOW CAN I FILL IT IN THE USERPROC.C PROCEDURE ?
>
>Please let me know the answer ?

The DSP_TIMDATAADDR property points to memory that is already allocated.  To 
allocate new memory, you declare it in your C code, and then use 
GetSymbolAddress to refer to the array by name and get the physical address.  
With the physical address, you can use GetMem and PutMem to transfer data 
to/from host memory and DSP memory.

But, if you use mode 6, you are making a lot of extra work.  You will have to 
call .asm functions, you will have to organize data and manipulate a lot of 
data, and you will have work out some synchronization with the host.  You are 
making way, way more work then just modifying modul5.asm and spaout.asm.  And in 
addition, the overall performance is likely to be less, because you have the DSP 
running C code.  And I don't think you will be able to avoid learning about 
2106x .asm code anyway.  Mode 6 is continuous input and output, and is intended 
more for control systems or audio processing, where some input data must be 
modified in real-time, then sent back to output.

You have the 2106x Source Code Interface software, so it's not like you have to 
learn about the board resources and every file and every function.  Just start 
by making small changes, for example to modul5.asm.  Yolanda has already spent 2 
hours making a nice diagram and document to show you how.  2106x .asm code is 
actually fairly readable, one of the advantages of the SHARC.

Jeff Brower

Compile Error with 1d21k Call

From: Jeff 
Subject: Re: Problem with compiler
To: Lionel
Cc: Yolanda 
Date: 09/08/99

Lionel-

>Here's my problem :
>I use DSP in mode 6, I modify userproc.c to use the FFT algorithm from 
>Analog library.  I have the function prototype include in a file name trans.h.
>So as others C program I declare :
>  #include  or #include "trans.h" (I tried the 2)
>
>But when I'll try to compile it gives me an error :
>Undefined symbol      First reference             _rfft1024                                                    
>userproc.o
>  ...
>  ...
>      ld21k -a a60link.ach -i a60link.cmd -o spad.exe -m
>      The error is given me with the ld21k call.

Here are some comments:

  -first, you do not need to assemble/compile all of the .asm
   programs each time (compile.bat).  Once you have a .obj for
   each file, then you can assemble/compile only a file only
   when it has been changed

  -second, be *sure* to put new files into the a60link.cmd file
   the .cmd file is the "Linker Command" file and tells the
   linker which files to link

  -third, remember to to copy the new output file (in your
   example above, spad.exe) to the \hsmacro subdirectory,
   and also be sure to change the DSLoadFileBoard (or
   DSLoadFileProcessor call in your VB program to reference
   the new file.  I think you have to do something like:

      ret = DSLoadFileBoard(hBoard, ByVal "spad.exe")

  -you might want to experiment with a simple external C
   function call (file) first.  For example, make:

      foo.c  (contains void foo() )
      foo.h
      add foo.obj to a60link.cmd file

   then include foo.h into userproc.c, and call foo() from
   the UserProc() function.  Once you can do this, then
   you know for sure that linking and re-running VB program
   are Ok.  Then the next step is to make a "real" function
   call instead of foo().

Jeff Brower

8 Channel FFT