I've been looking at the difference between the contents of the Nanocom .map format and the firmware image for an ECU loaded with the same variant and fuel mapping.
I'd initially thought that the Nanocom wrote over all of the EEPROM programming expect to the block containing the VIN. Paying a bit closer attention to the .map I realised yesterday that the first block of memory is untouched by the .map upload.
This section the eeprom contains the Vector Interupt Tables which tell the ECU how to respond in certain circumstances, including the memory location at which to start execution of the ECU program. The program start address points to code in this first block of memory.
I've also worked out that any unprotected .map file can be pasted into a .bin firmware image with mininal changes. The biggest issue is that the .map has some additional cruft that needs to be removed (td5map at the head of the file for example), and the byte order needs to be swapped.
The easiest way I have found to do the byte swap, on a Mac or Linux machine is to use the dd utility from the commandline:
dd if=[input file] of=[ouput file] conv=swab
the conv=swab option swaps the order of the bytes in the input file.
Update: Just noticed there is a typo in the graphic. The last address should read 3FFFFh not 37FFFh.
Looking at the "Base Code" from 000120 and 500030 firmware images, it seems that this code is essentially identical across these variants. There is a single 14 byte section which contains either data or a string located at 0x0F000 that differs between the two.
The Fuel Map section of the firmware consists of lookup tables, rather than code. The format appears to be a header which specifies the dimensions of the table followed by the data rows.