Tony Nixon wrote:

> I can't offer PicNPoke as shareware because the limited amount of
> funds it is generating is paying for things like being able to offer a
> CD version instead of the growing amount of disks.  It is already
> registerable on line and now that there is hardware as well, should
> make it easier for me to distribute.  People seem to like CD's more so
> than disks these days.

  OK, not necessarily defined as shareware, but as I gather, a demo
version and a version which must be registered.  You don't (the user
doesn't) pay so much for the disk as the registration.

  Users like CDs because they can't be trashed by a rogue drive (either
by spurious writing or by grinding the surface off.  The latter is
perhaps vaguely possible on a CD but unlikely by comparison.

  Equally importantly, CDs have stamped out virtually all the shonky
"copy protection" schemes which resulted in *un-usable* programs, either
deliberately or by the former mechanism.

> I was only hoping to use up space on the CD. If nothing ends up on it,
> then there's no harm done.

  That would still be a waste.  Many games (e.g., Pitfall) have
relatively little code, perhaps 10M, but the rest of the disk isn't
empty but actually contains soundtrack.  Or you could put an
instructional MPEG on it.  No need to waste...

> I was told ages ago by a rep from Microchip that PicNPoke may appear
> on their CD ROM and on thier web site, but nothing has surfaced yet.

  I'm not surprised.

> Just as an aside, ...
> What if the TRIS state somehow changes to an input?  Floating inputs
> can cause a bit of havoc as well.

  Do they really?  They increase current consumption which is
antithetical to micropower devices, and they could cause random
interrupts which tricks programmers if they have "wild" interrupt
functions, but I'm not sure there is serious suggestion they would cause
any other malfunction, because this would be a *major design blunder*.

  Interreaction with analogue function should be limited to excess
current drain in the wrong mode or digital input not reading ('cause
it's been *disabled*), but no more.  Certainly not meltdown.

  And your "wake" code should re-establish TRIS first thing, so even the
micropower matter should be self-correcting.

>  Maybe they should be set as outputs with a high value pullup/
> pulldown on them as well just to be on the safe side.

  Well, you can go "belt and braces" if you like.  But I'd imagine that
making a point of setting TRIS regularly, and using a shadow or simply
defining the whole state explicitly, using the TRIS instruction rather
than the register access (because the instruction is *far* cleaner),
would keep you well out of trouble.
--
  Cheers,
        Paul B.