I2C Effects on other PortA pins

Hi,
I'm using a 16F628A and Picbasic compiler (not Pro), which uses the default pins PortA.0,1 for I2C comms.
When the I2C function is active, should it affect the other PortA pin states?
The program I am working on uses PortA.7 as an output, which needs to be locked when in the "on" state, because it controls power on/off of external equipment
However, I notice that it is interrupted every second ( the I2C is a RTC read function) for a short time, giving it about a 90% duty cycle over one second.
I know that the routine for I2C is in the PBL.inc file - does it read/write to PortA as the full Register or only the two I2C bits?
If the former, is it possible to customise/modify the routine to include an "Or"ing of the necessary locked PortA.7 state?
All other pins are used in both Ports, so I can't reallocate the I2C pins.
Currently I have overcome the problem by trapping the short changes in the external equipment, but in other instances this may not be possible, so it should be cured at the source, if possible.
??

kenmac

I2C action is limited to the SCL and SDA pins you have defined (you haven't said what version of compiler you've got - just in case it's some ancient issue from years ago). The 16F628 has analog comparators which in certain modes can cross-connect some pins (see schematics in Comparator Section in Datasheet), but if you have disabled Comparators and the Voltage Reference Module this won't happen and it certainly won't happen with PortA.7 whose only commonality is with the Oscillator circuitry. You may have some bum code, or more likely a short between pins on your PCB or Breadboard since RA7 (your problem pin) and RA0 (your I2C pin) are adjacent.

Thanks Melanie,
The Compiler is V1.45 and Programmer is WinPicProg V1.95.
Fuses set for Watch Dog, Power Up, Brown Out, Int Osc.

I am aware of the 16F628A pins setup.
This is not a hardware problem.
Also, it appears to affect all portA pins being used as output.
I didn't notice that before because the other pins are normally held at low (0) when I2C is called.
It's definitely an effect of the I2C actions - the interruption of the output is exactly in synch with the 1 second polling of the RTC!
I have also tested the circuit on a protoboard - it does the same.
Unfortunately I don't know much about Assembly coding, so I can't interpret the I2C routines in the PBL.inc file.
As you know, when writing to the portA register we mask out any other pins to retain their state.
Is this also the case with the I2C routines - do they write as a complete byte or are they capable of writing to single pins alone?
The effect is similar to a non-masked write.
After the interruption, the affected pin restores to it's correct state due to the program loop.
Viewed on a LED, you see a mainly "On" state, with a visible short interruption at a "one second" rate.

kenmac