Bootloader for the J series

[libor]

I am looking for a serial bootloader to be used in a 18F25J10. The challenge is, these J series chips have a flash erase block size of 1024 bytes, and a write block size of 64 bytes, so the 'normal' bootloaders supposing equal size erase and write blocks do not work.
Before I begin to write my own (or modify an existing one) I decided to ask you, guys, if someone has experience with these chips in this regard.

[asmallri]

The J series has lower flash program memory endurance. I implemented a number of techniques in my Ethernet bootloader for this family to minimize the number of writes by, reading the current page of program memory (in repronce to an Intel hex type 4 record) and caching the subsequent writes to the this target page in shadow ram until the bootloader was finished or attempted to cross the current 1K boundary at which point I then compare the target page contents with the contents of the shadow ram and only perform and erase - write sequence on the page if there is a difference between them.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[libor]

Thank you for the clues. I was thinking in the same way.

But - raising the challenge - these chips have only 1024 bytes of RAM, so how can I assign a shadow ram using literally all bytes of ram, with not a single byte left for the working variables ? (fortunately I would need not that many variables, maybe just 2-3: can I save them in an unused system register, like the unused stack locations, or some FSRxx register ? What do you think about it ?

Or as an alternative: Can I always rely on the .hex file files data coming in sequence of increasing addresses ? I looked at a few, they were all filling the flash from the beginning to the end with no jumping about. (you would have troubles with the 1K shadow ram buffer anyway if the .hex file address would jump about and return a second time to the same 1K block only partially filling it at a time ?)

If the .hex file's addresses are always continuously increasing, I can simply erase the next 1024 bytes when the write block crosses a 1024 boundary. (this is exactly what the built-in write_program_memory() function does btw.)
Only some extra hassle is required with the reset vectors' block and the fuses' block (these chip write the fuses in the last 8 bytes of the flash)

[asmallri]