> Here is an opportunity for all the folks writing programmer software.
>  Make us a version that will never intentionally set the code protect
> bits.  I would gladly pay the cost of a few JW packages just to be sure
> that I did not choose the wrong option.  I know that programming errors
> can occasionally inadvertantly code protect a part.  However,  if we can
> eliminate operator error, I think we can save quite a lot of chips!

At work we use a BP Microsystems programmer.  While I'm sure BP has probably
come up with an improved version, and while I like the BP for programming other
parts [e.g. 87Cxx, 68HCxx, etc.] on the 16C622 it gives the best of all ima-
ginable worlds...

[1] If you define blank memory as $FF-filled, the programmer will complain
    that it can't program any PIC's, because the two high bits on the PIC
    will always read zero.  While it is nice that the programmer does not
    blithely ignore the two MSB's [in case you have byte swap problems] it
    would be nice if it could ignore them for the specific case of $FFFF.

[2] Because of [1], it is generally necessary to use $00 as the fill pattern.
    Guess what this translates to on the option fuses?

[3] Also because of [1], overburning parts [even if the option fuses were set
    properly in the hex file] is difficult.  If you have a programmer which
    can NOP-out programmed bytes, it's often possible to burn each chip a
    number of times without erasing (if you're writing 16C62x code that's less
    than 512 bytes, for example, it's often a simple matter to use each chip
    four times).  Note that when developing small programs on, e.g., the
    12C508 this ability may largely obviate the need for window parts on some
    projects [I once tested about 30 software versions on three 12C508's]
    Unfortunately, by filling unused areas with zero, the BP prevents these
    areas from being used for something useful.

[4] If the BP programs a 16C622 with the code protect bit set, it will fail
    the verify step.  As a result, if you wish to program production parts
    and have them code-protected, you must program them, then edit the fuse
    map, then "program" them again while hitting "I" to ignore the fact that
    the devices aren't blank the second time 'round.

[5] While the BP has an option to "just" set the code-protect bit on a 16C622,
    this option is in fact broken and will also zero out the rest of the con-
    fig word.  As a result, it will 99% of the time effectively destroy any
    16C622 which you try to protect unless you want LP mode, etc.

As a consequence of the above, I built my own programmer, which has been used
to program over 2,000 parts; it includes a low-voltage blank-check and verify
(adjustable via pot) and programs parts at about 5.2 volts.  I have had a few
slight problems; to wit:

[1] On four of 12C508's out of a batch of 2,000 the programmer was unable to
    program certain addresses.  The failures were always with locations that
    were multiples of 16 words apart, and on any chip all failures would be
    on the same bit [e.g. bit 4 of addresses $4E, $5E, $7E, and $9E might
    fail].  Note that I suspect that it may be that bit 4 of every $xE add-
    ress would have failed, except that many of them were supposed to have
    been left high.

    The odd thing about the failure mode on all four parts is that they would
    verify correctly at 5.2 volts but these bad bits would appear blank at
    4.4 volts.  This is the opposite of what I'd expect, since usually a low
    supply voltage will cause marginal bits to appear programmed even when
    they're almost blank.

[2] On my window 16C622's, it seems to take MUCH longer to erase the parts to
    the point that they'll blank check at 4.4 volts than to where they'll
    blank check at 5.2; erasing to pass 5.2 takes about 5 minutes, while I've
    had chips bake for an hour and still not pass at 4.4 [they show up with
    an image of the old code].  Is this normal?  I'd expect some difference,
    but that is rather a lot.