> I hear you but not even on my worst day would I concieve of such a
> design.I have barely started on my project so I carefully current
> limited all I/O pins.My experience (limited) programming PC's told
> me to expect the unexpected from my software for a while.Now my task
> is to find a programming software package that will properly set the
> config bits and I'm on my way. bye

Well, what happened was that when I first designed the thing, I had been
planning to have it keep the inserted chips in program or reset state, and
never let them execute code.  Further, since chips can't run without a
clock, I figured the likelihood of any errant code actually running was
essentially nil.

Despite this, I still would have 'liked' resistors on the all the pins, but
pins 1 and 18 are the ground/power pins for the 12C508.  Having the program-
mer do double-duty required either having these lines switched, or else just
figuring that they'd be okay.  Given that the latter was much easier, and
that I was operating under the former assumptions, this was not a hard choice.

The problem came when I added a header to let the programmer program and run
16C84's on a remote system.  Without fully realizing the consequences, I made
it so that when the unit finished programming, it would output highs through
the (resistively-coupled) clock and data signals and set the reset line to +5.
Even here I would have been okay had the 16C620's I'd been using not been set
for RC mode (in my project I was too lazy too hook up a crystal and in fact
wanted to be able to toy with the speed to see how slow it could run accept-
ably).  Since the programming clock wire for the 12C508 is the same as the
input clock wire on the 16Cxx, the resistor I had between that pin and the
PC printer port (to protect the port) worked very nicely as an RC clock resis-
tor and ran code out of the part.  Grrrr...