The only thing that you will find in the undocumented codes are modes
     that allow us to load instructions in parallel over the A,B ports of
     the device.  This is our primary test methodology.  We load 12 bits of
     the 14 bit instruction and 2 of the bits are defaulted.  There is a
     provision to vector to a start address and to revert to internal
     execution that allows port functionality again. We can then run the
     device from an external instruction stream to test.

     Rgds, Brian.


______________________________ Reply Separator _________________________________
Subject: Re: PICMaster Ideas - Cracking a 'thin' 16C84 ICE PIC
Author:  Scott Stephens <stephnss@KIWI.PYROTECHNICS.COM> at Internet_Exchange
Date:    10/2/95 9:09 AM


I recently read about the Pentium's secret performance evaluation registers
being hacked and posted at a web site. These registers were described in a
confidential data book volume made available to Intel's prefered developers.

This reminded me a posting a while back, in which someone suggested
unpublished codes may exist that would allow data to be read out of a PIC's
registers, for debugging. It is obvious from the data book, Programming
Specification (pg 3-26, table 1.2.1.1) that many other codes exist, and may
have benificial undocumented effects.

If the special function and data registers can be read, the device put in an
out of programming mode in-circuit, and the number of clock pulses
controlled with a gated oscillator controlled by software to manage
break-points (a concurrent simulation, maybe?) it would go half way to
hardware emulation even if the programm would halt when the long-time serial
data read out occured. And a long way in inexpensive, simple, in-ciruit
debugging.

I was thinking of issuing commands to the PIC in programming mode, and
analyzing the state (high/low/high-Z) as clock pulses are applied. Running
code on the pic to initialize registers, and testing the registers by
running the PIC again after test commands are issued. Maybe someone has some
C-source code for programming 16C84 or other PIC's, they could modify and
share with others for a concerted, systematic assault on the
programming-mode command code space. MPSIM's archaic interface's learning
curve and the horror of multi-tasking have kept me busy and frustrated
lately, so I havn't gotten around to it.

I suppose its an ethical issue; a manufacturer's right to enable/disable
features they see fit, and price accordingly. Like Intel's zapping FPU's on
some 486 to sell them for less, and withhold information from all but
they're favorite developers, to give them a performance edge

And a customers desire to fully explore and exploit a product they have
purchased. I don't think searching out undocumented features is the same as
removing copy protection from or password cracking features on software, but
rather like modifying a car or computer to increase its performance.

Now, if I had the new & improved MP-LAB simulator, I would no doubt have
better things to do ;->