Thanks to all for recent contributions on the subject of RB change
interrupts, I thought I had bypassed that by using the spare pins as
outputs, little suspecting a simple write would be preceded by a read!
Kalle's suggestion of using TRIS is great.

However, not wishing to be awkward, but I am still uncertain as to
whether there is a problem here at all - I was told by UK Microchip
people this was "fixed" on all 'A' suffix parts in the 16C6x series, and
that the 16C63 never suffered at all.

If you look at the data book you will see 2 versions of the port B
circuitry, the original being an asynchronous design, where you can see
how the problem would arise, and the Mark II which uses 2 latches,
clocked on different internal states. It seems to me this avoids the
problem since these is now no vulnerable period where the port pin can
change without setting RBIF. Maybe I should set up a rig to settle this
once and for all?

Slightly related, various other "features" of the PIC have been
discussed here recently, which I had been told by Microchip UK techies
had been "fixed". I am now nervous about whether this is indeed true.
Could the gurus comment on the status of these PIC gems:

1) The need to disable interrupts during table reads.

AN556 suggests that if an interrupt occurs during a table read (using
addwf ... retlw) then the retlw after the one you wanted may be accessed
in error. I was told this is fixed, and no need to disable interrupts.

2) The need, when globally disabling interrupts, to check that they have
indeed been disabled.

AN576 (and the recent discussion) suggests this is necessary, again
Microchip have told me this does not apply to 'A' suffix parts in the
16C6x series, or to the 16C63. Only the 16C61 suffers, and will not go
to 'A' revision, use the 16C620/621 instead.

(1) and (2) together would be a real pain if you have a lot of lookups
(guess what I've got a lot of?).

Anybody got any solid knowledge on this?

--
Alan Hall, Ipswich, UK
(01473) 652301