You need a logic analiser, loads of cheap ones on ebay. Once you capture a program loop you can load it onto your simulator and step through it, if its function is not obvious. Program the analiser to ignore that loop and repeat untill you have them all. The whole process is suprisingly easy if your source is not too big.
oops my reply went too early i had not finished so this is just continue of previos.
ok, i believe it. i thought maybe step through the real program in PAUMON with real feedback
*BUT*
my brain lapse/over active imagination/etc I see your point, the paulmonis not going to be doing any translation for me and certainly not clearing a path to all the I/O , i guess my hopes for paulmon (monitor) were too high
run
have the
:( alas another project i am working on
have built
*will* be
which company
well i am trying to do this hobby style so probably will not progress to that point sorry to put a wrench in your potential windfall earnibngs :)
I've started a bit down the path you suggest already. I printed out data sheets for all the onboard ICs for quick reference to what the inputs and outputs should look like. i started on creating a schematic/circuit diagram for the micro-board for understanding and easy lookup of interconnections.
i have dis-asembled the ROM code with a dis52 from the 8052 web site and i also used another dasmx130 that someone suggested but i get two different dis-assembles ?
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 ...
so that can not be a good sign , and leads to confusion so i suppose i will need to hand dis-asemble aways and confirm which dis-assembler is more accurate.
Looking at some used books on 8051 by MacKenzie and others
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.
It's not clear from your message what your goal is. Are you trying to find out where performance bottlenecks are (profile), learn its algorithms, or reverse-engineer the code?
There are a couple of things you can do cheaply. A few years ago we built a "real-time debugger" that would let us peek into a running system and see what it was doing. The trick was to connect one CPU as a watchdog for the other. We set aside a few bytes of common RAM. We inserted code in the CPU-under test to peek and poke a few registers and memory locations during each major cycle. It could do this with only a minor effect on execution time. Then we programmed the test CPU to peek and poke those same areas. We synchronized the two via enable pins. Finally, we wrote a hex monitor for the test system that could display the current values in RAM. This program only needed to run at operator speeds.
End result: We could watch any part of the program, by looking at data on successive interrupt cycles.
Come to think of it, this is exactly what Heathkit built into their H-8 computer, ca. 1978. At a 60 Hz interrupt rate, they sent selected CPU registers and RAM locations to a front panel hex display, and accepted hex inputs from a keyboard. If you only recreate the Heathkit electronics (which were minimal), you won't be far off the mark.
For profiling, there's also a way. It's called stochastic profiling. Basically, it interrupts the running program and finds out where the program counter is. Then you can draw a histogram of the time spent in each section of the program, and thereby find bottleneck spots.
So why don't you have the source code? (I know that there are sometimes valid reasons for not having the source).
What do the motors drive? Are there any safety implications if you mess around with the code?
[%X]
At least that method is non-intrusive and can give you access via a chip-clip over the processor part. However, that only gives you a view of what happens on the chip pins. You may still be blind on what is going on inside.
A good dis-assembly of the code so that you can at least see the structure of the code and data elements in the ROM might give you what you need to re-construct it. You will have to work out and add your own comments then you can re-build the ROM from scratch and have a much better view when you insert the break-points. You could even consider a change of implementation language and have much better tools.
--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.