Emulate DSP on PC

I am a complete beginner on this subject. So please correct me if I am
wrong
I'd like to run a DSP program on PC. There are some header files like
bus32.h that is not available from VS.NET. Also there are instructions
like LDI which are not available on PC.
So I want to run the program (legacy code) thru a debugger so I can
understand what's going on.
Any suggestions?
Thanks
Jack

Jack skrev:
> I am a complete beginner on this subject. So please correct me if I am
> wrong
> I'd like to run a DSP program on PC. There are some header files like
> bus32.h that is not available from VS.NET. Also there are instructions
> like LDI which are not available on PC.
> So I want to run the program (legacy code) thru a debugger so I can
> understand what's going on.
> Any suggestions?

...so you got some program for some DSP chip and want to
run the code on the PC? You would have to contact the
manufacturer of the DSP in question to get an emulator.

Having said that, I am not sure your approach is the best for
learning some arbitrary algorithm. Something that is
implemented on the DSP is likely to be very complex both
in terms of "non-trivial" algorithm tricks and elaborate use
of the DSP architecture, so somebody who is not an expert
on BOTH the algorithm that was implemented AND the
particular DSP chip that was used, might not understand
much about what is going on.

Rune

Dear Rune,
What the source is lacking is proper comments and naming. So sob....
Thanks
Jack

Jack skrev:
> Dear Rune,
> What the source is lacking is proper comments and naming. So sob....

Been there, done that.

If the code is really bad, you might consider
re-implementing the thing.

Those kinds of experiences generally provoke two
kinds of reactions. Either

"*I* struggled hard to get through that one, and I am
*NOT* to make easies for the next guy!"

and one then goes on writing at least as bad code oneself; or

"What a waste of my time! No need to obfuscate other people's
work more than necessary."

and one starts commenting and documenting one's own stuff better.

One guess as to what I prefer...

Rune

Jack--

>I am a complete beginner on this subject. So please correct me if I am
>wrong
>I'd like to run a DSP program on PC. 

If you meant "I would like to run a generic Digital Signal Processing
program written in ANSI-C for a PC under VC++ environment"- then you could
just go ahead and come unstuck,even if you have some initial trouble.

But if you meant, "I would like debug and run on my PC under VC++, a very
specialized piece of signal processing code written for a specific Digital
Signal Processor that is no longer popular in the market using a low level
of combination of embedded C and DSP assembly"- then you are in for some
greater trouble.

In this case, for starters, you could try and get yourself a set of
compatible tool chain, IDE or some other primitives like native
assemblers, linker-locators and debuggers relevant to the DSP chip for
which the program was written. 

Even trying to read & analyze a legacy code written for a specific DSP
chip using a PC debugger is dangereous. 

--Bhooshan

>There are some header files like
>bus32.h that is not available from VS.NET. Also there are instructions
>like LDI which are not available on PC.
>So I want to run the program (legacy code) thru a debugger so I can
>understand what's going on.
>Any suggestions?
>Thanks
>Jack
>
>

Rune Allnor wote:
...
> Those kinds of experiences generally provoke two
> kinds of reactions. Either
>
> "*I* struggled hard to get through that one, and I am
> *NOT* to make easies for the next guy!"
>
> and one then goes on writing at least as bad code oneself; or
>
> "What a waste of my time! No need to obfuscate other people's
> work more than necessary."
>
> and one starts commenting and documenting one's own stuff better.
> 
> One guess as to what I prefer...

You are a bad boy!

:-)

Andor skrev:
> Rune Allnor wote:
> ...
> > Those kinds of experiences generally provoke two
> > kinds of reactions. Either
> >
> > "*I* struggled hard to get through that one, and I am
> > *NOT* to make easies for the next guy!"
> >
> > and one then goes on writing at least as bad code oneself; or
> >
> > "What a waste of my time! No need to obfuscate other people's
> > work more than necessary."
> >
> > and one starts commenting and documenting one's own stuff better.
> >
> > One guess as to what I prefer...
>
> You are a bad boy!
>
> :-)

Maybe, but I am very lazy, too. I prefer to do things well once,
instead of being bothered year in and year out with the same
questions.

Actually, not long ago, after I left the university where I worked,
I got a question about some code I got 12 years ago from
somebody else. The code was undocumented, uncomprehensable
and unmanagable.

For 12 years I had asked for permission -- well, time -- to sit down
and re-implement that thing "properly". Almost the very minute
I walked out the door, some student wanted to use that code.
I am not interested in sorting out somebody else's mess, so I
very merrily directed the guy to the person I got the code from.

My motto is "after the project is completed, you ought to have
produced the documentation you would have needed when
you started." Not always possible to achieve, but worth
striving for.

Rune

Rune Allnor wrote:

   ...

> For 12 years I had asked for permission -- well, time -- to sit down
> and re-implement that thing "properly". ...

Twelve years is a long time. I had an eight-year story. One of my first 
microprocessor projects was an instrument that acted as an intermediary 
between a minicomputer and an Auger spectrometer. Originally, the mini 
controlled the spectrometer directly, using over 95% of its capacity and 
leaving little for the rest of the lab. My box accepted instructions 
from the mini, ran the spectrometer through its paces, collected and 
summed the results, then signaled the mini to accept a data dump when 
the run was over. The spectrometer thenceforth took about 2% of the 
mini's capacity.

The computer was all custom boards. One held the processor, code ROM 
(256 bytes would have been enough, but 1K was provided, working RAM for 
stack and variables (1K provided, 60 bytes needed), and three RAM boards 
of 16 K each for 16 Kwords of 24-bit data. The machine was delivered 
with code and hardware documentation; commented assembly code, an 
assembly listing, schematics, and notes on the interface requirements of 
the mini's I/O card. It worked without incident from the day it was 
installed. Once, the mini was replaced, but although the card was 
different, the interface was electrically the same and the lab tech got 
the wiring right. Eight years after the initial installation, the lab 
got a new spectrometer, one that required different commands. The lab 
personnel had turned over completely, nobody knew who had built the box, 
the documentation had been lost, and they needed to change the ROM. As 
luck would have it, they came to my shop for help making sense of the 
1802 disassembly.

When I pulled my own copy of the commented assembly code and the paper 
tape that made it from my file cabinet, the lab tech nearly wept. We 
made the needed alterations in about ten minutes, and I even had a 1K 
EPROM so we didn't need to erase the old one. He was gone in less than 
an hour. The original assembly had taken over two hours with a two-pass 
assembly using paper tape and an ASR Teletype. The revisions were done 
on a CP/M system with a pair of 8" disks whose speed rivaled the 5-meg 
hard disks of the time. The tape reader was 30 times faster than the 
Teletype had been.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins skrev:
....
> When I pulled my own copy of the commented assembly code and the paper
> tape that made it from my file cabinet, the lab tech nearly wept.
...

I have more than once been on the "nearly weeping" stage over
computer code, but never for joy. Hopefully, I pushed somebody
else, too, in that direction over that quick'n dirty magpie's nest of
shambles I was never allowed to re-implement... <diabolic grin>

Seriously: Smooth, streamlined computer code is like soccer
refrees: One never notices the presence of the best ones.
The game just flows along with no hickups, even after it could
have turned very ugly.

Oh well.

Rune

Jerry--

>Twelve years is a long time. I had an eight-year story. One of my first 
>microprocessor projects was an instrument that acted as an intermediary 
>between a minicomputer and an Auger spectrometer. Originally, the mini 
>controlled the spectrometer directly, using over 95% of its capacity and

>leaving little for the rest of the lab. My box accepted instructions 
>from the mini, ran the spectrometer through its paces, collected and 
>summed the results, then signaled the mini to accept a data dump when 
>the run was over. The spectrometer thenceforth took about 2% of the 
>mini's capacity.
>
>The computer was all custom boards. One held the processor, code ROM 
>(256 bytes would have been enough, but 1K was provided, working RAM for 
>stack and variables (1K provided, 60 bytes needed), and three RAM boards

>of 16 K each for 16 Kwords of 24-bit data. The machine was delivered 
>with code and hardware documentation; commented assembly code, an 
>assembly listing, schematics, and notes on the interface requirements of

>the mini's I/O card. It worked without incident from the day it was 
>installed. Once, the mini was replaced, but although the card was 
>different, the interface was electrically the same and the lab tech got 
>the wiring right. Eight years after the initial installation, the lab 
>got a new spectrometer, one that required different commands. The lab 
>personnel had turned over completely, nobody knew who had built the box,

>the documentation had been lost, and they needed to change the ROM. As 
>luck would have it, they came to my shop for help making sense of the 
>1802 disassembly.
>
>When I pulled my own copy of the commented assembly code and the paper 
>tape that made it from my file cabinet, the lab tech nearly wept. We 
>made the needed alterations in about ten minutes, and I even had a 1K 
>EPROM so we didn't need to erase the old one. He was gone in less than 
>an hour. The original assembly had taken over two hours with a two-pass 
>assembly using paper tape and an ASR Teletype. The revisions were done 
>on a CP/M system with a pair of 8" disks whose speed rivaled the 5-meg 
>hard disks of the time. The tape reader was 30 times faster than the 
>Teletype had been.
>
>Jerry

For all I could care -- with that kind of gift for prose -- you could be
writing bull and I would be still be ready to lap it all up. Its a
pleasure reading your posts!(Even if you dont know a spectrometer from a
spectrum analzyer!)

Keep 'em coming!

--Bhooshan