Order Cart | Contact Us | Home | SIGs | Login

Motorola DSP56002EVM

This product is no longer available.

DSP56002EVM The DSP56002EVM is a low-cost Evaluation Module (EVM) designed by Motorola to familiarize engineers and experimenters with the Motorola DSP56002 Digital Signal Processor (DSP) chip. The DSP56002EVM is very popular with Amateur Radio enthusiasts interested in DSP techniques. The EVM has been programmed to perform as a 1200 AFSK modem, 9600 bps FSK G3RUH modem, and various filters, just to name a few.

The DSP56002EVM was made popular by Johan Forrer, KC7WW, in the August 1995 QEX article entitled "Using the Motorola DSP56002EVM for Amateur Radio DSP." Johan created a software package for the DSP56002EVM.

Greg Jones, WD5IVD, President of TAPR, arranged for TAPR to have access to a large number of evaluation units from the Motorola DSP group. The purpose was to distribute these units to the amateur radio community for the support of DSP related research and development. Over a three year period, TAPR provided over 500 evaluation units into the amateur radio community.

The DSP56002EVM was discontinued by Motorola, but EVMs do appear on eBay or amateur radio for sale web pages.



For technical documentation on the DSP56002 and other DSP chips manufactured by Motorola. Visit the Motorola Digital Signal Processing web page. The DSP56002 Technical Documentation page has a link to DSP56002EVM Documentation and an overview of the DSP56002 chip.

Prentice Hall has published a text book entitled "Digital Signal Processing Applications With Motorola's DSP56002 Processor, 1/e" by Mohammed El-Sharkawy, Copyright 1997, ISBN 0-13-569476-0.

Using the Motorola DSP56002EVM for Amateur Radio DSP Projects

Motorola's low-cost DSP evaluation module covers all the bases for amateur use and development.

By Johan Forrer, KC7WW
Originally published in QEX August 1995

This article is about the Motorola DSP56002EVM, a low-cost, powerful DSP evaluation module (EVM) intended for those experimenting with digital signal processing (DSP). It is ideally suited for filtering CW and EME signals, audio processing applications such as denoising and autonotching and DSP modem work for HF digital and VHF/UHF modems for use in terrestrial and satellite applications. I'll cover hardware and resources for application development and present a collection of advanced DSP applications ready for amateur experimentation. (See the Collection of Utilities and Application Package for the DSP56002EVM that appeared with this article.)


One way to learn about new computer hardware, especially processor chips, is to actually try your hand at programming them. Unfortunately, for an amateur experimenter with limited resources, mastering a complex processor like the Motorola 56002 DSP is a formidable task. This is not something for the faint of heart. 

The recent introduction of low-cost EVMs by DSP chip manufacturers, however, has helped make DSP technology available to experimenters. These EVMs include sufficient educational materials to get you started: a small printed circuit card that contains the DSP chip, software to develop and evaluate educational programs and essential technical reference material. In an amateur-radio environment where cost and availability are major factors, these EVMs have been received with great enthusiasm. The DSP56002EVM is Motorola's entry into this market. The DSP56002EVM may be used either as a DSP development platform or for a free-standing application when using its onboard E(E)PROM memory. The DSP chip used on the EVM has an impressive track record in communication engineering. Its DSP chip is from the same Motorola DSP family as the chips used in the HAL PCI-4000 [1], AEA DSP 1-232, DSP 2-232 [2] and the DSP-12 [3]--and even in commercial and military products. If judged by these success stories, the 56002 presents splendid opportunities as it offers high clock speed and the advantages of its on-chip hardware emulator. 

A Peek at the 56002 DSP 

The computing engine of the DSP56002EVM is a 40-MHz 56002 DSP. This is a 24-bit processor, meaning that each instruction is 24 bits wide. Data and instruction words are kept in separate memory spaces. Instructions are stored in the "P"-space, short for program space. Two separate, independent data spaces, "X" and "Y" are available. This separation of data and instructions is called a Harvard architecture. This is quite different from the Von Neumann architecture used, for example, in the 80x86 processors. The Harvard architecture is typically used in DSPs and allows for extensive instruction parallelism. 

The value of this parallelism becomes evident when one considers that the strength of DSP processors lies in their ability to multiply and accumulate (MAC) very efficiently. The 56002 scores high in this regard. It can multiply two operands, accumulate (sum) the result, fetch two new operands from its two independent data spaces, do address adjustment and fetch the next instruction--all in one clock tick. For a 40-MHz 56002, this happens 20 million times per second. Other DSP chips may have similar features, but having two data spaces and a 24-bit code/data architecture is a distinguishing feature of the 56000 family. 

The 24-bit architecture of the 56002 allows a richer instruction set than that of comparable 16-bit DSPs. It also allows an impressive selection of extended addressing modes. These addressing modes are available in one-word instructions and also in a two-word instruction format. Which instruction format to use becomes a trade-off between ease of programming and programming for efficiency. Obviously, the additional dynamic range of 24-bit data (144.5 dB) over 16-bit data (96.3 dB) may prove valuable in certain applications. Higher computational accuracy, or perhaps the ability to detect weaker signals buried in noise, is possible. 

The 56002 allows for a considerable degree of flexibility in interfacing configurations. Access by the outside world to the DSP is through several I/O pins, arranged as general-purpose I/O ports named, "PA," "PB," and "PC." Depending on the application, several of these I/O pins double up for use as signals for onboard peripherals such as a synchronous serial interface (SSI) or serial communications interface (SCI). When using these on-chip peripherals in applications, some of these I/0-port pins become dedicated and are no longer available for general-purpose I/O. Port PB in the DSP56002EVM is available at header J7 and is available for the user's interface. Initialization and use of these peripheral devices are documented in the 56002 user's guide. [4] Other DSPs have similar peripherals, particularly with respect to their capability to directly interface high-speed CODECS. But the 56002 SCI and OnCE peripherals are unique for the class of fixed-point DSPs. 

The 56002 user-programmable phase-locked loop (PLL) determines the DSP clock rate. A 4-MHz crystal clock is available on the EVM to drive the PLL. This clock, incidentally, also serves as the clock for the on-board 6805 OnCE-interface microcontroller. Such a programmable system clock may serve several purposes. It may allow the designer to meet a variety of internal timing constraints. Or for portable equipment, a variable clock rate may be used for power management. The DSP consumes more power at higher clock rates than lower rates. Power consumption may thus be regulated by selecting the lowest internal clock rate that meets the requirements of the application. 

One extremely useful feature of the 56002 is the inclusion of an on-chip sine-lookup ROM that comes in handy for use in communication applications, especially numerically controlled oscillators (NCO) for demodulators. 

An Overview of the DSP56002EVM 

Figure 1 shows a much simplified overview of the basic hardware components of the DSP56002EVM. 

Figure 1 -- Basic hardware components of the DSP56002EVM.  ((A)/(B) Stereo input/output ports for analog/digital signal conversion.  (C) RS-232 signals for interfacing the DSP56002EVM to a PC computer through a serial interface/used mainly for debugging.  (D) RS-232 signals for serial communications. 

CODEC Interface (SSI) 

A Crystal Semiconductor CS4215 coder-decoder (CODEC) handles analog signal conversion. This chip is designed for high-quality multimedia audio purposes and is capable of converting two analog signals to 16-bit digital values (A/D). It also contains two 16-bit digital-to-analog (D/A) converters. These A/D and D/A converters form the analog input and output capabilities of the EVM. The CS4215 is a flexible device, capable of a variety of user-programmable data conversion rates, programmable input gain and programmable signal output attenuation. The CODEC interfaces with the DSP via the DSP's SSI using a minimum of interface signals. DSP software must initialize the serial clock rate and framing method of the SSI for the particular CODEC. Additional control lines for reset, and data/control select, are required to fully command and control the CODEC. In the EVM's case, these control signals are assigned from peripheral port "C," as shown in Table 1.  

Table 1. DSP56002EVM assignment of M56002 peripheral port "C" control lines.

M56002 port C  



SCI Receive (host port)


SCI Transmit (host port)


CODEC Data/Control (D/C)


Not used (used for DCD in Leonid code)


CODEC reset


CODEC Frame synchronization


CODEC Serial clock


CODEC Receive (SSI Rx)


CODEC Transmit (SSI Tx)

Note that the DSP56002EVM only implements a subset of the CS4215's capabilities. Of particular importance is the following: There is only provision for "mike" input, as the line input is disabled. Only one crystal is used, 24.576 MHz, which is connected to the "XTAL2" position of the CS4215--this normally is reserved for a 16.9344MHz crystal. XTAL2 must be selected when initializing data sampling rates. Typically, 8, 9.6, 16, 27.42857, 32 and 48-kSPS rates are available. These are commonly used rates for communications applications. 

On-Chip Emulation (OnCE) Interface 

A 6805-family microcontroller greatly simplifies the OnCE debugging interface. This single-chip solution not only saves board space, but also helps to keep costs down. Its purpose is to translate commands received via the serial interface from the PC-hosted debugging software into parallel control commands for controlling OnCE operation. The low-level OnCE interface logic is very intricate, consisting of several handshaking strobes and intricately-timed pulse sequences--not an easy task to program. The 6805 microcontroller takes care of all this low-level complexity and hides a great number of details from the user without restricting the capabilities of the OnCE, or perhaps only to a small extent: speed. The microcontroller, in its present form, is only capable of operating at a maximum speed of 19200 baud. At this speed, large DSP programs may take a while to download. 

Although it is not crucial for a developer to know about the low-level debugger interface protocol to use the DSP5600EVM, it may be valuable when embedding OnCE capability into your own programs, or even to make it possible to use the EVM on other, non-DOS platforms. A summary of the OnCE interface protocol follows. [5] 

Communication with the 6805-family microcontroller is eight-bit serial at 19200 baud. The host issues a command code that may consist of a single byte or may be multiple bytes, depending on the command. The response from the microcontroller is also coded, consisting of a single byte or multiple bytes. In certain situations, such as reset, there is no response, in which case the host should confirm that the EVM is in a usable state by a status query. Table 2 summarizes the command structure.  

Table 2.  OnCE command structure.

Host (Hex) 


EVM Response (Hex) 

A0 Rx   Read OnCE register Rx   D7 RaRbRc (4 bytes)  
A1 Wa   1-byte write   D1 - success,  
D2 - failed  
A2 WaWbWcWd   4-byte write   D1 - success,  
D2 - failed  
A3   Reset DSP   no response  
A4   Reset DSP   no response  
A5   Force OnCE into debug   D3 - DSP dead  
D5 - success  
A6   Release OnCE   D4 - success  
A7   Read DSP status   D7 Sa (2 bytes)  
A8   ..not used  
A9   Reset the 6805   no response  
AA-AB   ..not used  
AC   Check if 6805 is alive   D6 - 6805 responding  
AD   Obtain what code level   La - code level  

Host Port Interface (SCI) 

The ONCE port is mainly used for debugging purposes. A more traditional serial interface is provided by the SCI. The DSP56002EVM provides a host connector (an optional feature) for this purpose. When the SCI interface is used, PC0 is programmed for SCI data receive and PC1 for SCI data transmit. (These assignments are also shown in Table 1.) Applications that use this interface for communicating with a host may use either ASCII or KISS format. [6] In stand-alone mode, the SCI port is the only means of communication with the EVM. Note that there is no provision for hardware flow control on the DSP560902EVM in its present form--applications must provide software flow control when needed. 

Static RAM Memory 

The 56002 DSP has 1024 24-bit words of on-chip static RAM (SRAM) that is divided as 512 words of P-memory, 256 words of X-memory, and 256 words of Y-memory. This on-chip memory runs at processor speed and usually is reserved for code that needs to run at the fastest possible speed, such as critical interrupt handlers or variables that need to be accessed very often. 

An additional 32K words of SRAM is provided by three (32K x 8) 6206A SRAM chips. Dealing with address decoding logic for these fast DSP chips is very tricky due to the short access times and propagation delays in decoding logic. The EVM designers opted to use a simple, effective method of partitioning the address space. Address lines 14 and 15 and enables X/Y effectively allow for two addressing schemes. These are selected by jumper J12 (16K/32K). The resulting memory layouts are shown in Figure 2. 

Figure 2 -- Static RAM layout for the DSP56002EVM.  Jumper J12 allows selection of memory configuration.

Both schemes lead to compromises--for example the 32K scheme has P, X and Y all residing in the same physical space. The programmer then has to guard against aliasing side-effects. For example, address P(220) is the same physical RAM location as X(220) or Y(220). In the 16K scheme, on the other hand, P and X share the same space with Y being independent. In this case, the programmer should watch out for aliasing P and X RAM locations. In addition, memory locations above 4000 are "shadow" RAM, that is, address decoding does not distinguish between locations in the range (0000 to 3FFF) and corresponding locations in the range (4000 to 7FFF). 

These peculiarities have led programmers to take advantage of the hardware in clever ways. One programming trick that is often used to speed up DSP algorithms on the 56002 is to use a single location pointer for addressing two equal-sized I/O buffers. For example, let one buffer be used as a data source and another for a data destination. If X and Y are then set such that the corresponding elements of the input and output buffers reside at the same numeric address, for example: Input(10)is at address X(080), Output(10) is at address Y(080), then a common single pointer register (R2 in this case) does both fetching and storing of data at the appropriate locations. 

    move   X:(R2),x0    ;Input comes from X
   move   y0,Y:(R2)    ;Output goes to Y

An example of how this is used can be found in the Leonid kernel's CODEC interrupt handler, where code efficiency is crucial. Some of these peculiarities become important considerations when porting 56002 code across different platforms. The amateur-radio application programs in this article all use the 16K memory mapping. 

One fact that is often overlooked pertains to external RAM: No matter which scheme is used, any data accessed in off-chip RAM involves multiplexing/demultiplexing of the address and data busses--the ultimate penalty is speed of execution. It is thus imperative that time-critical code reside in the on-chip RAM if at all possible. 

Memory E(E)PROM 

The DSP56002EVM includes an option to use an E(E)PROM for booting. This is essential for stand-alone applications. An EPROM such as a 27C256 would be suitable, but this assumes that the user has access to all the necessary tools to convert 56002 object code to a form suitable for booting the DSP. A much more elegant and useful alternative is to use an EEPROM, such as the Atmel At29C256PC FLASH PROM. It is relatively easy to program this device in-place using the software tools supplied with the DSP56002EVM. 

Other Miscellaneous Glue Logic 

Besides the DSP, CODEC and 6805 OnCE interface, very little additional logic is required to make a functional system. Shifting RS-232 levels to logic levels is handled by a MAX232--both transmit and receive pairs for the OnCE and host interface port are provided for. The 56002 reset logic also requires attention, as the DSP can be forced into one of several operating modes at reset time by presenting the hardware with a special reset signature. For the DSP56002EVM, a 74LS157 chip is used to present a binary "100" pattern to IRQA~, IRQB~, and NMI~ that places the DSP in "EPROM BOOT" mode. [4] Upon recognizing this state, and if a valid E(E)PROM device exists, the DSP's internal boot ROM then performs a bootstrap from this ROM, regardless of whether the ONCE port debugger is used or not. 

Development Software and Tools for the DSP56002EVM 

The DSP56002EVM ships with the Motorola 56002 version 5.3.2 assembler, Domain Technologies version 1.02 debugger and some (minimal) coding examples. [7] The assembler, as far as I can tell, is very similar to Motorola's professional edition. It generates COFF-format object code. No loader (a program that combines several preassembled objects) is used. This implies that all assembly code is assembled in one step--something that may become awkward when dealing with large projects. The generous use of include statements to read in different source code modules is one solution that helps. However, some public-domain software that includes a C language compiler, assembler, linker and 56000 simulator is available that may be of interest. [8] 

Domain Technologies, Inc, developed Debug-EVM for the DSP56002EVM. This debugger bears similarities to professional in-circuit emulators in both appearance and capabilities. Such sophistication is made possible by the 56000 OnCE interface that effectively provides in-circuit emulation capability on silicon. Debug-EVM provides access and control over the internal workings of the DSP, memory and peripherals during the debugging process. 

Debug-EVM is a DOS-based program that interfaces to the DSP56002EVM through a serial port at 19200 baud. Well-organized multiple-window displays allow for viewing data, program code, DSP registers and processor status in various formats. During the debugging stage of code development, DSP code and data is downloaded from the host PC to the DSP's memory. The developer can then manipulate registers and data, and place breakpoints as required. It also is possible to interact with a running DSP in a non-intrusive manner. This means that the DSP may be debugged at full speed. The debugger offers the following features: 

  • fully symbolic (data and code labels)
  • source level debugging
  • on-screen editing
  • mouse support
  • built-in assembler/disassembler
  • character graphics (for plotting memory arrays)
  • multiple memory display modes
  • trace with count
  • single step with count
  • subroutine jump
  • true real-time hardware breakpoint
  • up to 128 software breakpoints
  • up to four memory windows
  • requires no on-chip monitor code

Amateur-Radio Applications for the DSP56002EVM 

The software examples that come with the DSP56002EVM contain only the bare minimum to get you started. One of the included routines is a CODEC support routine, CODEC.ASM. This routine contains a collection of functions that initialize the CODEC and get it up and running. It is a complicated piece of code that requires that the programmer be knowledgeable of both how the CODEC chip works and also all the intricacies of the 56002 SSI interface. Fortunately, the use of define statements makes setting up the CODEC a fairly routine procedure. Transferring data to and from the CODEC is fully interrupt driven using agreed-upon buffer locations. 

To make the DSP56002EVM more useful to other experimenters, I've put together a program package of useful additional programs. A listing of the programs included in the package is shown in Table 3. 

Table 3. Contents of the KC7WW experimenter's program package for the DSP56002EVM.  This program package is available for downloading. [11]

Native DSP56002EVM applications (KC7WW)

INOUT.ASM    -- CODEC talk-through test  
RTTY.ASM     -- KC7WW's HF RTTY/AMTOR/Pactor (use with PCTOR)  
RCOEFFS.ASM  -- filter coefficients for above  
TTYCD.ASM    -- CODEC support for RTTY modem  
EVM56K.PLT   -- KC7WW's EVM radio interface schematic (HPGL)  
EVM.PS       -- KC7WW's EVM radio interface schematic (Postscript)  

Ported applications based on the Leonid kernel
Original work by the Alef Null group: Jarkko Vuori, OH2LNS
Kaj Wiik, OH6EH and associates

TALK.ASM     -- INOUT equivalent for Leonid BIOS  
BIOS.ASM     -- The source for the ported Leonid kernel  
BIOS.CLD     -- loadable module  
INTEQULC.ASM -- essential include files  
LEONID.ASM   -- KC7WW's ported Leonid include file  

FSK.ASM      -- Jarkko's 1200 baud Bell 202 modem for the EVM  
BANDPASS.ASM -- Jarkko's narrow CW filter  
COEFF.ASM    -- filter coefficients for above  
QRMQRN.ASM   -- a slightly modified version of Jarkko's LMS denoiser  

Contributed programs by Jalocha, SP9VRC

CORELNW.ASM  -- Correlation-based filter  
FFT-CUT.ASM  -- Denoiser based on the spectral subtraction  
PARLL1.ASM   -- Early experimental 12-tone OFDM HF modem  

The native DSP56002EVM programs work with the code that came with the EVM--the Leonid kernel is not used. As the simplest code example, the INOUT.ASM program is particularly useful to a beginner to verify the operation of the EVM and carry out some experiments with the CODEC. RTTY.ASM is a bit more advanced and requires further background in FIR filter design. Note that it uses a modified version of the CODEC support routines. The program contains a thorough description of how the DSP modem works. A schematic for a radio interface is included for use with this program. 

One code module that may be of general interest is the author's port of the Leonid kernel. This module runs some exciting amateur-radio programs developed by the Finnish Alef Null group. [9] The Alef Null group has been active in the development of DSP projects since 1992--the DSP CARD 4 is their fourth generation DSP card. The DSP CARD 4 is very similar to the DSP56002EVM in many respects, except that it uses a 56001. However, the DSP CARD 4 is a forerunner of the DSP56002EVM. The striking similarity in hardware and software allowed the author to port the Alef Null software to the DSP56002EVM. 

Porting Alef Null programs requires only minor changes: pay careful attention to the CODEC input source, P, X, Y and L memory allocation. Then, preload BIOS.CLD before loading the Alef Null application. Finally, start the application using "GO 0." This allows the last-loaded application to gain access to the low-level kernel services. Review the included code examples in the experimenter's package for further details. 

The experimenter's package would not have been complete without the contributions of Pawel Jalocha, SP9VRC. These include several excellent examples for advanced DSP experimenters. Pawel has been particularly helpful in including assembly directives that makes his programs run on both platforms. 

A Brief Overview of the Leonid Kernel 

A DSP kernel is loosely defined as a sort of "command module": a collection of DSP-resident code functions that control, manage and interact with a user's DSP application. An in-depth overview of a complex piece of DSP code the size of the Leonid kernel is beyond the scope of this article. I encourage you to obtain the Alef Null documentation and read it together with BIOS.ASM. The code is reasonably well commented. 

The Leonid kernel consists of two parts: the low-level BIOS and a higher-level abstraction that contains several macro calls. The low-level BIOS is contained in BIOS.ASM while the higher-level macro calls are contained in LEONID.ASM. Be sure not to mix the ported versions with the original Alef Null code--these are not quite compatible. 

The Leonid kernel contains several critical components necessary for amateur-radio networking applications. A low-level routine handles the HDLC protocol for assembly and disassembly of AX.25 data packets. In addition, the KISS protocol is used together with the HDLC routines. It is thus possible to use the DSP56002EVM with a TCP/IP (NOS) program without any additional hardware. All that is required is the radio, EVM and a PC running NOS. Besides these support routines, additional low-level support is also included for time-out detection and carrier detect--necessary requirements to successfully operate in a network environment. Jarkko's Bell 202-compatible 1200-baud FSK modem (FSK.ASM) is a good example that gives further insight into how this all is put together. 

(1) Initialize CODEC: 
        ctrlcd 1,r2,buflen,MIC,0.0,0.0,LINE|HEADP,0.0,0.0 
(2) Start CODEC: 
        opencd 16, NOHPF 
        Jump via P(0028) 
(3) Collect data from the CODEC: 
        waitblk r2, buflen, batch 

Figure 3 -- Command interaction between user program, Leonid interface and BIOS.

A few hints may help you follow the interrelation of the different program modules. Figure 3 illustrates how a user program interacts with the kernel. Examine this in conjunction with TALK.ASM, a simple example that illustrates how to use the Leonid code and BIOS. The TALK program starts by initializing the CODEC using the "ctrlcd" call (step 1 in Figure 3). This is a macro call (defined in LEONID.ASM) that primes the CODEC's buffers and prepares various pointers and registers that work with the CODEC. The parameters used in the example shown are as follows:  

1--initialize data buffers. 
r2--use R2 as a data pointer for reading/writing to the CODEC's buffers. 
buflen-defines the internal size of the CODEC's circular buffers. 
MIC--A define that activates the microphone as input source. 
0.0, 0.0--sets the left/right input gain (see CS4215 data sheet). [10] 
LINE|HEADP--defines that activate line/headphone output. 
0.0, 0.0--sets the left/right output gains (see CS4215 data sheet). 

The CODEC is started in step 2 using the "opened" call. This macro requires two parameters: the first is the sampling rate (ie, 16 means 16 kSPS), the second is whether the on-chip high-pass filter is required or not (see the CS4215 data sheet for its implications). Note that this macro includes a jump instruction to P-address 0028. This location is part of a jump table that routes the command to the appropriate section within the BIOS. This jump table is shown in Table 4(b) as part of the low-order P-address space. The jump to P(0028) will be routed to the CODEC startup code that in turn will bring the CODEC to life. It is imperative that once the CODEC comes alive, its interrupt vector and all associated pointers and data buffers are ready. Otherwise, the code will crash and burn. Jarkko implemented a very efficient CODEC interrupt handler in the BIOS routine by using the so called "fast interrupt" feature of the 56002. The way this works is, instead of a proper interrupt handler routine, two instructions are placed in the interrupt vector address. When a CODEC interrupt occurs, only these instructions are executed, then program execution resumes. These fast interrupts are shown in Table 4(a). The actual instructions in the interrupt vector locations are indirect read/write via register R7, so it is imperative that R7 be reserved for this purpose. Similarly, R3 is used as a SCI buffer pointer (see the SSI interrupt vector in BIOS.ASM for further details). 

Table 4(a): Simplified block diagram for low-level BIOS functionality: Interrupt vector table.

Interrupt vectors: P(0000-001F) 
Reset               vector 
Stack Error         vector 
Trace               vector 
Software interrupt  vector 
IRQA                vector 
IRQB                vector 
SSI TX   ------- Fast interrupt 
SSI Tx error        vector 
SSI Rx   ------- Fast interrupt 
SSI Rx error        vector 
SCI Rx              vector 
SCI Rx error        vector 
SCI Tx              vector 
SCI Tx error        vector 

Table 4(b): Simplified block diagram for low-level BIOS functionality: Jump table.





opencsi Opens serial interface. 
(a)=KISS command routine address else 
(a)=0 for regular 8-bit serial I/O 
(b)=Tx on/off routine address. 


putc Places a character in output queue
returns Z is buffer full, NZ otherwise.


getc Retrieves a charater from the queue
returns with argument in (x0)
returns C if no data available, else NC


tstc Checks state of queue
returns C if no data available, else NC


endc terminates a KISS frame.


rejc Rejects the current KISS frame.


putbit Places the current KISS frame.


getbit Gets next bit to be sent
returns with bit in C
Z if end of transmission.


opencd Opens CODEC at a specified sample rate
Sample rate code is in (x0).


closecd Shut CODEC down.


stimer Request a specified time delay
(x0) contains number of (1/baud) ticks.


putio Writes to port PB
LSB of (x0) contains argument.


caron Set transmision "in progress" state
Subject to persistence and DCD logic.


caroff Set "end of transmission" state.
Subject to persistence logic.


not used.


Illegal interrupt

Actual data collection occurs in step (3). The "waitblk" macro requires three arguments: "R2" indicates that register R2 is to be used as an input/output buffer pointer, "buflen" is the name of the input/output buffer to be used and "batch" contains the block size. The block size feature provides a flexible programming environment. This is illustrated by the following example: If you need to process one sample at a time, the block size will be one. But keep in mind that the data collection process occurs as a background task--often it may take longer to process a block of code than the period between CODEC interrupts. By working with chunks of data at a time, data collection can continue in parallel with processing. This remains valid as long as the time it takes to process a block of data is shorter than the time to acquire a new block of data, so the I/O buffers won't overflow. A further example to illustrate this method of data acquisition is doing real-time FFT processing. Assume that 256-point blocks are acquired and processed and 256 points are written back out. Now suppose it takes longer to process a 256-point FFT than the time between CODEC data interrupts. Clearly, it is not possible to output a continuous stream of processed FFT data. However, collecting a chunk of data first, the FFT calculation can now proceed to completion before the next 256-point chunk arrives. Thus, a continuous stream of data can be collected, processed and written back out, without gaps. There would, however, be a time delay between input and output of duration equal to the time it takes to fill a block. 

A number of additional function calls are available that deals with the SCI, timer, KISS and HDLC interface routines. These are listed in Table 4(b). 


This article shows that the DSP56002EVM is in a class of its own--outstanding in flexibility and capability that should be hard to beat for some time to come. It is capable of serving the needs of beginners and advanced experimenters in DSP. Amateur-radio experimenters in DSP can also take advantage of an established base of applications. 


Jarkko Vuori and the Alef Null group's permission to use and publish their code is gratefully acknowledged. This contribution is an outstanding achievement in software engineering. 

It was a pleasure to work and discover many new aspects about the 56002 with Pawel Jalocha. His advice, assistance and permission to use and publish his code is acknowledged. 

I am also indebted to George Hawkins, K15X, and the folks at Motorola Digital Signal Processor Systems for their keen support. 


1 PCI-4000. HAL Communications Corp, PO Box 365, Urbana, IL 61801, tel: (217) 3677373. 

2 DSP-1232 and DSP-2232. AEA Advanced Electronic Applications, Inc (AEA), PO Box C2160, Lynwood, WA 98036, tel: (206) 774 5554. 

3 DSP-12 Multimode Communications Controller. L.L. Grace Communications Products, Inc, 41 Acadia Drive, Voorhees, NJ 08043, tel: (609)751-1018. 

4 The following literature may be ordered through Motorola's Literature Distribution Center, PO Box 20912, Phoenix, Arizona 85036 (Phone: 1-800-441-2447). Please note that some of these materials are free, others not:  

DSP56000 Family Manual (DSP56K FAMUM/AD). 
DSP56002 Digital Processor User's Manual (DSP56002UM/AD). 
DSP5600010SP56001 Digital Signal Processor User's Manual (DSP56000UM/AD). 

5 EVM56002 EVM ONCE Interface, Rev 1. 1. Craig Heller et al, Motorola Digital Signal Processing Division, Semiconductor Products Sector, 6501 William Cannon Drive West, Austin TX 78735-8598. This software is supplied with some versions of the kit. 
6 Chepponis, M. and Karn, P. "The KISS TNC: A simple Host-to-TNC Communications Protocol," Proceedings of the Sixth ARRL Computer Networking Conference, ARRL 1988. 

7 Domain Technologies, Inc, 1700 Alma Drive, Suite 245, Plano, TX 75075. Developers of the Debug-EVM. Version 1.02 was shipped with the author's system. An updated version, 1.0402, is available for downloading from Domain's BBS (214) 587-1090. Domain also offers a professional version of the debugger, the LINK-56002 development system. In addition, a 56002-based, ISA-bus development card is also offered. Domain Technologies may be contacted via the Internet at: domain@metronet.com. 

8 Public-domain software for the 56000-family is available from several Internet locations. One such location is ftp://nic.funet.fi in file /pub/ham/dsp/dsp56k-tools/gcc5616.tar.Z. This program is the work of Andrew Sterian and was intended for the 56116/56156 DSP but, with some reservations, is useful for the 56002. There also is a C language compiler for the 56002, by the same author. This one is named gcc56k.tar.Z. The Alef Null software package mentioned in Note 9, includes a (somewhat dated) assembler, linker, and simulator. These were placed in the public domain because they are not the latest official Motorola versions. However, they all work well. Another useful source for software is Motorola's Dr. Bub BBS (512) 891-3771 or (512) 891-3773. 

9 Kaj Wiik, OH6EH and Jarkko Vuori, OH2LNS. Alef Null DSP CARD 4, User's Manual. Manual and software package available for downloading from jeeves.hut.fi. Look in the alefnul directory for program libraries and documentation. 

10 CS4215 16-bit Multimedia Audio Codec. Crystal Semiconductor Audio Databook. Crystal Semiconductor Corporation, PO Box 17847, Austin TX 78760. 

11 "KC7WW's experimenter's code package for the DSP56002EVM is available for downloading from: ftp://ftp.tapr.org/ hfsig/upload/EVM56Kl.ZIP. 

Converted to HTML by N7HPR (www)

KC7WW's Collection of Utilities and Application Package for the DSP56002EVM

Note: The latest firmware based on the KC7WW code is available at Doug Braun, NA1DB, website at http://www.dougbraun.com
Radio Interface
Johan designed a daughter board that provides a radio interface for the DSP56002EVM.

PCB Solder Side
PCB Component Side
PCB Silk Screen
evmpcb.pdf (15K)
evmpcbs.pdf (65K)
evmpcbc.pdf (49K)
evmpcbl.pdf (5K)

Collection of Utilities and Application Package for the DSP56002EVM
Version 3 - March 1996
Johan Forrer, KC7WW (forrerj@peak.org)


The code, schematics, and examples in this package are provided for personal use without any warranty on an "as is" basis -- "what you see is what you get." The code examples or schematics may not be used for resale or in any commercial or government applications without written concent of the author(s). The author and authors of the included software examples are not liable for any mishaps due to the use and/or abuse of this software package.

This version of the package accompanied the article in the August 1995 issue of QEX:

Using the Motorola DSP56002EVM for Amateur Radio DSP
by Johan Forrer, KC7WW

This package will get you started developing amateur radio applications with the Motorola DSP56002EVM. It assumes you have some prior experience with the DSP56002EVM, i.e., have assembled code and used the debugger a little bit.

The package evm56k3.zip is available from ftp://ftp.tapr.org/dsp/Motorola/dsp56002/evm56k/kc7ww/

Native EVM56002 Applications (KC7WW)
KC7WW's EVM radio interface schematic in HPGL format.
KC7WW's EVM radio interface schematic in ORCAD format.
KC7WW's HF RTTY/AMTOR/Pactor (use with PCTOR).
Filter coefficients for RTTY.ASM.
CODEC support for RTTY modem.
CODEC talk-thru test.
Contributed program by Chris Hanna. Please read comments carefully before using.
Some fixes to the released programmer. Please read comments before using.

Applications based on the LEONID kernel port
The source code for the ported Leonid kernel
Loadable object
essential include files
KC7WW's ported Leonid include file
KC7WW's CODEC talk-thru test
Jarkko's 1200 baud Bell 202 modem for the EVM
Jarkko's narrow CW filter
filter coefficients for above
a slightly modified version of Jarkko's LMS denoiser

Pawel's (SP9VRC) Programs
Correlation-based CW denoiser.
Denoiser based on the spectral subtraction method.
Experimental OFDM modem (15-parallel tones).
1200 baud packet modem.
FSK interface for FAX, HF FSK etc.
Checking transmitter filter response.
Real-time FFT signal analyser for weak signal detection. Great set of programs for real-time FFT displays.

Danie's (ZS6AWK) Programs
Some notes on EVM usage and NOS hints.
Interface layout in Tango format.
Interface schematic in ORCAD format.
Test code for SCI interface.

(NOS) a collection of notes for running the EVM with NOS
Suggestions for running NOS with modem programs FSK.ASM, FSK1200, NEWQPSK.ASM
KC7WW's setup for the EVM.


The bulk of the more interesting applications are based on the work of the Alef Null group. I acknowledge the efforts of Jarkko Vuori (OH2LNS), Kaj Wiik (OH6EH), and their associates, for their excellent work. I am also most grateful for Jarkko Vuori's permission to port and post the Leonid monitor code for the EVM56K.

I recommend that the documentation of the Alef Null Project be obtained for reference purposes from ftp://jeeves.hut.fi in the alefnull directory. There are several components: source, tools1, and doc. It contains an appropiate introduction to what DSP is and also discusses modem theory as applied to the various software modules in the package. Makes for interesting reading.

Some exellent examples from Pawel Jalocha (SP9VRC) are included with his kind permission. Thanks Pawel for sharing your fine workmanship! I can recommend all the modems, denoiser/filters, and FSKIFACE works wonderfully with JVFAX7.1 (another outstanding program).

I also include a contribution by Danie, ZS6AWK - I am sure that this will also be appreciated by others.

Radio interface

    NOTE: Using this interface to your EVM requires NO modifications to your EVM.

I included the schematic of my radio interface for the EVM56K. This schematic is basically adapted from the DSP4 and simplified to the bare essentials. The reader is referred to the DSP4 documentation for further details.

Also note that if you want to use the interface schematic, that a few jumpers need to be changed:

  1. J8 should have all four jumpers in standard mode, i.e., parallel to the short edge of the PCB.
  2. J10 should have PC0 and PC1 jumpers installed.

Just a note about FLASH EPROM: I have used the Atmel chip and have had good luck with it. To program the FLASH EPROM, first load your code using the debugger, then load the FLASH program supplied with the kit. Finally execute the FLASH program. The start address is given in the FLASH program, just look at the source code. When all is done, remove the debugger and push the "reset" button. The DSP will then boot from the FLASH EPROM.


The EVM56002 and the DSPCARD4 are very similar in many respects - deceptive differences, however will puzzle the beginner and expert alike. When porting the code between these two platforms be mainly aware of the following:

1. The DSP4 has seperate spaces for P, X, and Y - the EVM56K only has P/X, and Y. Be careful with X memory allocation. Also be aware of tricks that use a common address pointer that addresses both X and Y at the same time. The DSP4 software examples occasionally uses this method.

2. There is only one audio source connected on the EVM, i.e., "MIKE" input. The DSP4 allows a selection. Thus make sure that any code that you port has "MIKE" selected. You may optionally put the 20dB pad in if you need more gain at the cost of poorer audio quality. Also note that there is only one crystal on the CODEC, i.e. 24.5MHz, and it is connected to the WRONG crystal port, i.e. where the 16MHz crystal is supposed to be. This is no problem, though when you initialize th CODEC, make sure it looks for the 16MHz crystal - the 24MHz crystal is then selected and all is fine.

3. To use the Leonid monitor on the EVM, first load "BIOS", then your application(s) and finally "go 0" to start the code. If you plan to use the "SPY" program, or any other program that use the SCI, for that matter, you need to switch to the "terminal" port on the EVM as all communications using the EVM's SCI port is through that port.

4. Please look at the code for BIOS.ASM before using it:

    a) You may wish to change the SCI baudrate to another value than the 9600 baud that I used.

    b) For a faster EVM clock, enable the speed you wish. I have been using 40 MHz to maintain compatibility between several old and new systems. My EVM will run quite happily at 80 MHz.

This goes for the 1200 baud FSK modem as well. In that case you also need to make sure that you use a program that can talk in "KISS" mode, i.e. something like NOS will do just fine.

Note there are two experimental 1200 baud modems in the package. The OH2LNS version, FSK.ASM, is somewhat sensitive to audio input level - set this not more than 180 mV. Pawel's modem, FSK1200.ASM, is fairly insensitive to the input level.

5. If you are not a NOS guru, the following commands will let you monitor raw traffic (make sure you have the appropiate serial port, attached in your autoexec.nos file).

    trace ax0 211 (then push F9, I assume "ax0" is your ax25 device)

6. When NOS is used, ensure that NOS and the EVM is communicating at the same baudrate. Please check the baudrate that Leonid is using by the setting in "baud" (line 182) - set it to the required rate and re-assemble BIOS.ASM.

7. You must use my version of the leonid.asm include file when building programs that use the Alef Null Leonid monitor calls.

Other Hints & Kinks

The EVM has only a provision for using MIC input -- LINE inputs are grounded through a capacitor. If you wish, these LINE inputs can be enabled, though this modification should only be attempted by a skilled person. You will need to work under good lighting and use a magifier glass to inspect your work. This one voids your warranty - beware!

    Step 1). Referring to the CODEC: find the track running from pin 18, towards C207. Cut it close to C207. The LINE inputs are now disconnected from ground.

    Step 2). Turn the EVM upside down and find the feed-thru tracks from pins 15 and 16. Between these two feed-thru holes, is a "L" shaped short track that feeds through to pin 16. This "L"-shaped track ties LINEL and LINER together - cut it. Now LINEL and LINER are independant.

    Step 3). If you wish to connect LINEL and LINER to an independant input conditioning circuit, you may wish to use the feed-though holes on the bottom of the EVM for solder pads to gain access to LINER (pin 16) and LINEL (pin 18). I choose to bridge these pads so that MICR/LINER and MIRL/LINEL becomes connected.

I did this modification only to maintain software compatibility with some programs the use LINE as input. Otherwise it is best to leave this alone.

I trust that this collection of examples is of use. Please let the authors know that you are using their software and that you appreciate their indivdual efforts. The main thing is - please contribute your own efforts so that we all can grow in our experiences.

73, Johan, KC7WW

Danie Brynard, ZS6AWK

Danie, BRYD@KIDD.CO.ZA, has been experimenting and using the DSP56002EVM for a variety of projects. He has built upon some of Johan's work and added a few of his own. Here is Danie's contribution.

ICOM IC820H Radio Interface

Danie modified Johan's radio interface design and tailored his to work with the IC820H. Here is the evmawk.txt file and evmawk.zip.

Index of Software

Danie maintains an index of software for the EVM. It is available as evmindex.txt.

Jabi Aguirre, EA2ARU

Jabi, govier02@sarenet.es, has also been experimenting and improving upon Johan and Danie's work. Here is his contribution.

Photos of the pcb design Jabi modified from Danie, ZS6AWK's design.

Photos of the case Jabi has made for his EVM.

For more information on the pcb and case, contact Jabi at his email address above.

About Us | Privacy Policy | Contact Us | ©2005-2019 Tucson Amateur Packet Radio Corp unless otherwise noted.

Accept Credit Cards