1. Home
  2. Embedded Programming
  3. 68K disasm

68K disasm

An old client contacted me to "decompile" some 68K code for a product line he purchased (but failed to verify that ALL the sources were available! So, there are portions of the production image that a "build" fails to recreate)

"Sorry, not interested"

[the first time I reverse-engineered a product was an "interesting" experience; the second time was "skill enhancing"; a THIRD time would just be "a job" -- boring!]

This morphed into a discussion of folks I could recommend for the job (no one that *I* know would be interested). And, finally, a discussion of *tools* that he could purchase to undertake the task.

I'd tackle it with an ICE -- especially if he has the target hardware available! A "poor man's" approach might be a logic analyzer (with appropriate disassembler) -- but tedious. A colleague suggested Ida Pro (apparently it can handle some number of different targets beyond x86).

Any other approaches/tools that I can suggest?

Reply to
Don Y
Loading thread data ...

IIRC, the GNU binary utilities, binutils, can be configured for M68K. From the tools, objdump should do the job.

--

-TV
Reply to
Tauno Voipio

Sorry, forgot to mention perhaps the most interesting part of it in my other messages.

Having all the asm sources for a 68k product means it can be ported to power - e.g. to one of the 603e derivative cores - without too much pain. This is what I did some 15 (17?) years ago, this is how vpa got started (having a few megabytes of good sources I did not want to part with was the main drive). CPU32 user level code will still assemble into power directly, obviously supervisor level has to be rewritten but usually it is a tiny part of the code (was - is - so in DPS at least).

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

I might be interested in taking on this project.

1yknuj at neysocim dot moc
Reply to
Iquag

I don't know their ultimate goal. Obviously, they can't "produce" the existing design (unless they bought the entire related resources of the company -- including any NOS components that they had in inventory).

I suspect they are just trying to find an easy/straight-forward way to port the device's functionality to a more modern implementation. And, have decided that it is complex enough that a clean-room reimplementation would be too expensive.

Or, they could have picked up the rights to the product by purchasing a (defunct) *company* and are looking for inexpensive ways to exploit those assets.

As I said, I don't want to get too involved in THEIR problem as I've got enough on my plate to keep me "intellectually engaged" for quite a while! Any effort thinking about their needs would just be at the expense of *mine*! :>

Reply to
Don Y

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.