At 10:26 AM 6/15/96 -0400, Byron A Jeff wrote:

>> A 2nd, "user" serial port would allow general communications. All
>> the remaining i/o ports would be brought out to pin headers and
>> possibly a prototyping area.
>
>The only problem is that a second serial port would have to be implemented
>somehow....
>Would the other UART (or the host one for that matter) be done in software?

The host port would be a software UART, making the the SCI available for
the user's pgm. With a bit of extra hardware only a single serial line
would be needed, as the host and target could interact in a master/slave
mode. The use of the host serial i/o pin(s) could be recovered if it(they)
were toggled over to the user's hardware at run time.


>> ...the processor could change DATA_0, etc. on the fly.
>>
>
>Unnecessary. The 17C42 has table read/write instructions which modify
>off chip (and on chip for that matter) RAM/EPROM.

True, except that table write is a 16-bit operation and I wanted to
modify only the data byte of the instruction word, not the opcode byte.
A kind of "DMA" would even be possible (and with dual processors?).
Admittedly all this is a little far-fetched, and probably not worth
the design effort required.

Another fanciful idea is to download the object code to the target via
the PC's parallel port(s). Faster than serial, but again needs more
glue logic and time saved would be marginal. However the same kind
of circuitry could be used to monitor the external bus activity and halt
the PIC at a breakpoint. Only a tiny fraction of a full emulator of course,
but even the most minimal development facility is a vast improvement over
none at all.

Regards, D.M.