I've gotten some interest in USENET about my proposed PIC
evaluation board; here are some responses from different readers
with my replies:

> Couldn't one just feed the PIC 4 clock pulses (or 8 for a
> conditional) to do a single-step?...  The only little flaw is that
> the regs can't be examined, but there way be a workaround.

Exactly the problem that ruled out this approach for me, since
the whole point is to be able evaluate the performance of the PIC
in several ways including examine registers. However, you did give
me the idea that clock cycles could be run through a binary counter
to get an instruction count between events.

> I agree with you there's something missing, but I think what it is
> [and I've been tempted to fix this myself] would be a
> PC-compatible board which would emulate a PIC's I/O (port pins,
> RTCC, and clock input) and allow the 8x88 to access it
> conveniently.

Something like this has been suggested to Microchip already and I
don't think they're overly thrilled with the idea. The thing is,
it seems like a big programming effort to get an IBM-PC to emulate
a PIC, compared to the real thing running in a test environment.
For instance, could you duplicate *exactly* the interrupt latency
of a real PIC? (And therein could lurk a tricky bug).

>       Why not make up a 16c84 based board.  Have the '84 hooked up to
>the parallel port in 'In System Programming mode', provide a cheap $0.84
>4Mhz ceramic resinator.  Sure you could only reprogram the chip 1000 or
>so times (100 minimum, 1000 typical), but for about $10, whoe cares?  The
>entire device (minus power-supply) could be built for about $20 or less.

I have all the hardware to do this, but it's not quite enough.
Sure I can program an '84 and run it in a PICDEM or proto
board, but the problem is, how do I verify its performance -- even
if all the LED's and bells and whistles seem to work correctly?
With that setup I can't, say, run just one subroutine (in real
time, in a real target environment) and make sure it's working
correctly.

I'm always amazed at the sheer variety of disguises that bugs come
in; some deceptively simple while others are fiendishly subtle.
And the same goes for their discovery. Sometimes it takes days of
testing with sophisticated instruments while other times you just
stumble over a nasty one while reviewing the code for some other
reason. On one recent project I noticed a small (but unusual) time
lag between pulses on a scope, but was busy with something else at
the time and didn't pay much attention (uh-oh!). I only found out
what was going on some time later when a senior associate asked,
"Why are you missing a break in this switch statement?" (The
source code had gotten scrambled while being sent as e-mail.)

So what I'd like to see are facilities for several levels of
testing. For instance the PIC-Eval could have a few extra features
such as scope trigger points that don't take up any of the user's
i/o pins. This could be done at almost no cost (with some
diagnostic code in the user's pgm) or with a bit more hardware to
monitor the instruction bus.

My last posting left out a method of resetting the output
handshake bit (to host). Here's an idea - run the latched versions
of A15 and A14 into both sides of an LS139 dual 2-4 decoder. OE-
enables one side and WR- the other. Y0 and Y1 aren't used on
either side (corresponds to A15 low). Y2 with WR- sets the output
data latch as well as the 1-bit handshake latch. Y3 with WR-
clears the handshake bit. (A hex inverter will be needed to get
the right polarity on some of these signals).

Y2 with OE- reads the input latch and handshake. Y3 with OE- is
spare, and could be used as a scope trigger point for the user.

If more trigger points or other functions are wanted then A15
through A13 could be used with a pair of 3-to-8 deocders.

A few developers have suggested a serial interface, rather than
parallel which I suppose is too much like a hardware hack.
However, if I build a proto it's probably going to be parallel as
it's faster and requires less debugging of the loader PIC since
the host communicates with the target more directly. The
difference in speed starts to get significant with functions such
as multi single step with instruction trace.

Regards, D.M.