Mine works along the same principal as a virus scanner.  I known sig for a location which reads the target map.  I then scan through a target rom and note any direct matches excluding absolute addresses.

If that fails I move to byte / word swaps, using ram at page 0xe1, and finally a distance value from the current sig to the current chunk of the target rom - a bit like a spell checker.

When I get a hit, I parse the code looking for the scanning routine call, then locate the register loaded with the offset and DPR of the table.  Then I drop the result along with the program counter in to a data grid view.

Sometimes it doesn't work out and I have to do it manually.

Doing it automagically and getting the correct axis based on the machine code is hard, but I am getting there.

Checking work - I create from D rom.  I scan F, M, H and G roms and compare the results if there are any which don't line up I investigate.

There's no way to be 100%.  I catch errors in my own work.  I catch errors in Nyes!  There is even an error in an ASAP file out there.  Only the machine code is 100% accurate.

NO.  You misunderstand I think, I don't expect that addresses are pointing to maps that are identical.

I am assuming the code which looks for the specific map does not change much between revs of code.  The code moves location - so the addresses change always, both program counter and target addresses, but the function structure remains almost static.  When the structure of the routine changes the Levenshtein distance is not great FOR THE STRUCTURE OF THE FUNCTION AS A WHOLE, not it's location.  I search for 0 distance in routine structure first as it is fast.

I'm not assuming the map is identical, they aren't even if the function is the same. 

If I just assumed that because G rom, read data at program counter 0x88a43b, that in every rom a map is read at 0x88a43b I'd be off by miles on every single target.

OK. good discussion here.

Tangent question: do we want to write our own checksum-maker for files or keep using Andy's? I am hazy on the details of how to do all this right now, but if it is possible we'll find a way to do it.

chksum shouldn't be hard.  I can post the routines which calc the checksum blocks.  Andy Whitaker posted most of the 'how'.

There is even a codeword to ignore the checksum routine.  However someone inserted two NOP instructions over the jmp in the checksum routine, effectively breaking the codeword function.

It shouldn't be too hard to work out where the jmp_nz should jump to, then we can forget about checksums - useful for those of us with an eprom emulator who want to map the car live.