At 01:02 PM 5/21/97 -0700, you wrote:
>                         The Discovery
>
>Well, I'm amazed!  I think I resurrected a windowed 17C44 (-JW) from the
>dead, after it had assumed the lowly role of code-protected paperweight for
>most of a year.
>
>[In our last episode, the ambitious developer begged and cajoled his
>faithful Microchip FAE, Tonto, for a couple early engineering-sample
>17C44-JW parts.  Before Tonto could say, ``But Kimosabe...'' our hero
>raced off and programmed them with his favorite 17C42 code.  But little did
>he know, the 17C42 source contained an ingredient which was POISON to the
>new 17C4X die family: PMC_MODE!

Peter and others,

Don't get too excited. Microchip change the code protect configuration bits
changed with the release the 16C43/44/42a. Code for the 17C42 should not
have in fact activated the code protect mode on the 17C44. The code protect
bit has moved! The  17C42 code protect mode is in fact a disallowed state
on the 17C44.

Please compare the PMC_MODE config bits in the P17C42.inc file to any of
the other 17Cxx .INC files to see what I mean.

PMC_MODE 17C42 0xFFAF
PMC_MODE 17C44 0x7FAF

And you guest it, bit-15 is the code protect bit on the 17C44!

Perhaps the disallowed state you programmed into the 17C44 may explain the
other strange phenomena you described. Maybe it even caused something that
may have resembled code protection to you or even your programmer to occur.

A correctly code protected 17C44 JW? I seriously doubt that is what you had
and would urge caution in what you believe. I would also strongly suggest
you don't really code protect your 16C44 to try to prove anything (unless
you missed it as a paperweight.) :~)


Jim Robertson
NEWFOUND ELECTRONICS