Yeah I know how you guys proceed. I was trying to find a way to ease the pain since there is repetitive part... but you seem to have your script to do that...
maybe more can be automated?
Quote:
dis.py now takes a "-m" command-line argument, which applies Mitsubishi-specific fixups to the ROM. Right now, that means it automatically locates/disassembles jump tables (as indicated by use of MOVA), and also tries to locate the MUT table (and seems to mostly succeed). Both are borrowed from acamus' onload.idc script; he should get the credit for the way I implemented determination of their locations.
Mart
dschultz wrote:
Mart wrote:
well I think it can be expanded to automatically label known stuff and produce a def file from parsing back?
HEX -> auto labelling -> parse back -> generate def file
make sense?
I do that right now but in a manual way. I take a ROM that is well known and close to the unknown ROM I want to define. I use IDA so the known ROM is all marked up. I then locate similar locations in the unknown ROM and mark them with the same references as the known ROM. Once the references are marked I dump those to a text file. I then take that text file, the known ROM def file and update the address and size attributes in the def file to create a new def for the unknown ROM. I wrote myself a utility to do this part automatically. So from start to finish I can define a unknown ROM with extended logger parameters in about a day. The part that I have not got my head around is how to automate the marking in the unknown ROM. There has to be many checks and balances to validate that the location being marked is correct. Many routines can be identical for some tables. Also, sometimes the compiler re-orders steps in the routine or uses different registers but the result is the same. This is the development area that would really help in new def creation.
