"starfire" <starfire151@cableone.net> wrote in message
news:13ohrc4u6lqv5b@news.supernews.com...
>
> "Ian Malcolm" <valid.address.in.signature@invalid.invalid>
wrote in message
> news:fm9gru$1qj$1@inews.gazeta.pl...
> > robb wrote:
> >
> >> I have a (8051) micro-controller that i would like to trace
it's
> >> runtime program to understand how the program works for
purpose
> >> of potentialy modifying code. (The only info of program is
the
> >> program binary copied off ROM )
> >>
> >> The micro-controller consists of (usuall stuff):
> >> ---------------------------------------
> >>
> >>>Siemens 8031, ROM, SRAM
> >>>servo motors (+ driver ICs)
> >>>simple user 16 char (14 seg) interactive display
> >>>grid of buttons (24)
> >>
> >>
> >> Any ideas on how to do this? how possible ?
> > The *ONLY* practical ways of tracing the *actual* program
execution on the
> > *actual* hardware are either with a high end logic analyser
preferably
> > with support for displaying 8051 instructions or with an
in-circuit
> > emulator. ...
> ...snip...
>
> To give you an idea of where to look... I used to have an old
logic analyzer
> made by Arium (which merged with American to become
American-Arium) called
> the ML4100C. It had plug in microprocessor pods for various
> microcontrollers, including the 6502, the 8039 family, the 8051
family, etc.
> I used it extensively for debugging microcontroller flow on
several 8031
> projects I had developed. It was indispensible. It showed
exactly how the
> program was executing and showed the instructions in assembly.
>
> I've since then gotten rid of the logic analyzer (donated to
our local
> college) but it was sure nice when working on 8031 projects. I
don't know
> if you'd have any luck in trying to find such an animal
anymore...
>
> Good luck.
> Dave
>

Thanks Dave,
lots of good info heer in usenet.

thanks again for info and reply,
robb

>
> one treats the (02096f) in the first 3 bytes as a (long jump to
> 096F) where the other disassembles the (02096f) into something
> else like this ...
>
> 0000 : 02 " " db 002H
> ;
> 0001 L0001:
> 0001 : 09 " " inc r1
> ;
> 0002 L0002:
> 0002 : 6F "o" xrl a,r7
>
02 09 5F is LJMP to 096F. dump the other disassembler.!

In article <vOMij.47141$745.31820@newsfe1-win.ntli.net>,
Someone@ntlworld.com says...
> >
> > one treats the (02096f) in the first 3 bytes as a (long jump to
> > 096F) where the other disassembles the (02096f) into something
> > else like this ...
> >
> > 0000 : 02 " " db 002H
> > ;
> > 0001 L0001:
> > 0001 : 09 " " inc r1
> > ;
> > 0002 L0002:
> > 0002 : 6F "o" xrl a,r7
> >
> 02 09 5F is LJMP to 096F. dump the other disassembler.!
>
>
>
I ran into quite a number of problems of that sort in
APPLE II assembly code where whatever system
generated the code would intersperse defined constants
with the generated code. The disassembler would
try to disassemble string constants and debugging
data (such as function names, etc.) and would then
miss the first instruction of the next function.

Sometimes you may have to look at instructions
such as LJMP 096F and make sure that the
bytes at 096F really are executable code.

It's little things like that which make disassembling
and reverse engineering a non-trivial excercise.
Which is OK by me as it paid the bills for almost
half a year back in the '80s.


Mark Borgerson