> James,
>
> There has already been a discussion on the 16F87X programming algorithm. The
> only significant differences are that the Begin Program command switches from
> 0x08 to 0x18 and that the config fuses are in a different place (which I
> believe is an assembler problem).
>
> Let me see if I can rustle up the text of that Begin Program issue....
> Nope. I didn't save it. But I'm sure that the primary change was the change
> programming command.
>
> I'll go take a look in the PICLIST archive for the 0x08/0x18 issue.

I found it. Posted in August by Wojciech Zabolotny (wzab@ise.pw.edu.pl):
Funny, that's the same guy with the patches!
------------------------------------------------------------------------
On Tue, Aug 03, 1999 at 07:41:06PM +0300, Sam Laur wrote:
> > The only difference is the low voltage programming mode (so may be
> > the RB3 pin should be additionally pulled down with eg. 3k resistor).
> >
> > Have I missed something?
>
> Yes. If you're using a programmer designed for 16F84, there's a slight but
> important difference: for 16F877 (and 16F84A), there's Begin Erase Prog. Cycle
> which is 001000 and Begin Programming Only Cycle which is 011000.
>
> Now, for the 16F84 there's just Begin Programming which is 001000. So if you
> try to write to the program memory, it will fail because of this difference
> in commands.

I've once again analysed the programming spec's and Brian Lane's code of
picprog 2.2
I've stated that use of "001000" command in 16F8xx (instead of "011000")
will cause only erasing of data before the programming
(this may decrease the device's durability, because the PICPRG 2.2 performs bulk
erase of program & data memory before the programing).
The only problem is that such cycle requires more time then "programm only cycle
".
So this is why programmers dedicated for 16[CF]84 do not work with 16F8xx.
I can see two solutions for PICPRG 2.2 users:
1) Increase of delay after send_cmnd( 0x08 ); (change waitus(10000) to
   waitus(20000) or so)
   However this is not recommended due to double erasing of memory.
OR:
2) Change the send_cmnd( 0x08 ) to send_cmnd( 0x18 ) in the whole lowlvl.c file
   (without changing the delay).
   This second solution should solve the problem.
------------------------------------------------------------------------

So it would seem that changing the programming command would do the trick.
The next natural question is it possible to pick the device type from the
object file? Then you could automagically switch the correct programming
command without having to specify it on the command line.

BAJ