Here is the problem

* if you try to swap pcb 701640 with external ROM chip with another pcb you will need to move the external ROM from the old pcb to the new pcb.
*but if your old pcb have died external ROM chip then you will need to write rom to your new pcb with suitable backup taken with any kind of tool like pc3k or Wd doctor or whatever you have.

the problem is the backup taken with pc3000 or wd doctor or.... is 192 k.b .
* if you write this file with pc3k oe WD Doctor , your pcb will power down ?
why ? because this chip "the external ROM " is 25x20 or some thing like that . carry file 256 k.b not 192k.b so if you write the 192 your pcb ,itwill power down.

* BUT if you read the external ROM with any usp programmer it will read file with the size 256k.b and if you write the file to another chip it will work fine.

so if you want to use your back up ROM file in such case . you must convert your 192 file to 256 file otherwise your pcb will power down

_________________
Tawfeek Mokhtar
http://alsafwapc.net
Alsafwa Data Recovery Egypt

Why would it make any difference whether you write the last 64KB segment? It appears to be padded with 0xFF bytes.

FWIW, I have recently analysed another 192KB ROYL ROM and have determined that there are checksums for each of its code and data modules. AFAICS, the space between 192KB and 256KB is not included in any checksum, but I could be wrong.

The ROM begins with a table of LDSCs ("PM Loader Config String"), each occupying 32 bytes. The last byte of each LDSC is an 8-bit checksum which is calculated by summing the preceding 31 bytes.

Each LDSC contains the starting location and length, in bytes, of its corresponding PMCBlk ("Program Memory Code Block"). There are two length fields -- one is the length excluding the checksum byte, while the second is the total length including the checksum byte. These fields are 4-bytes long, in little endian format.

The 8-bit checksum for each PMCBlk is computed in the same way as for the LDSCs, with the result being placed at the end of the block.

LDSC 00 - 31 bytes + 1-byte checksum at the end
LDSC 01 - 31 bytes + 1-byte checksum at the end
...
LDSC nn - 31 bytes + 1-byte checksum at the end
PMCBlk 00 - variable length block of code + 1-byte checksum at the end
PMCBlk 01 - variable length block of code + 1-byte checksum at the end
...
PMCBlk nn - variable length block of code + 1-byte checksum at the end
ROM MODs - 32-byte zero sum - integrity bytes included in sum

One other test that I (and my colleague) performed was to compare the 192KB ROM contents before and after enabling PUIS (Power Up In Standby). We found that only two bytes, in ROM MOD 0D, were changed. These corresponded to the PUIS flag (changed from 01 to 02), and the MOD's checksum.

References:
http://nazyura.hardw.net/Part02.htm
http://nazyura.newmail.ru/Check_fl.zip
http://yura.projektas.lt/files/wd/mhdd/index.html

_________________
A backup a day keeps DR away.

I guess i know what you mean here, seems you are right here
i did some progress here, but seems u came here with results

good luck man, and nice work

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

I don't mean to dismiss the OP's empirical evidence, but here are my results after analysing the BIN file with NazYura's utility:



Note that the file's extension had to be changed to FLS, and its size had to be truncated to 128KB. CHECK_FL can't handle block sizes greater than 0xFFFF, so the results for LDSCs 07 and 08 had to be recomputed with a hex editor.

AFAICS, each data/code structure has its own checksum, so one would have to ask why the MCU is rejecting the 192KB ROM image.

_________________
A backup a day keeps DR away.