Hey Brooke, I recently had to deal with PCLATH and interrupts..
Well anyway, the silicone does deal with it as you said, but some
precautions you must take are shown in my interrupt start code.
You only need to save the value of PCLATH if you use any
GOTOs or CALLs in your interrupt. Oh, I had to do this when I sent
from the 2K part to the 4K part.  if you are not having to do that
then disregard this, but someone might find this useful.
I use the FSR and INDF in my interrupt, and outside of it, so I must
save that also, and restore it.
BANK0 is a one line macro....

        org     004h            ; (4) Interrupt vector
;INTERRUPT
        movwf   W_TEMP          ; SAVE w
        swapf   STATUS,w        ; Swap STATUS to be saved into W
        BANK0                   ; switch to bank 0
        movwf   STATUS_TEMP     ; save STATUS
        movf    PCLATH,W        ; load PCLATH & save before any goto is used.
        movwf   save_pclath     ; Save PCLATH
        bcf     PCLATH,3        ; Set to page 0 for program counter.
        movf    FSR,W           ; Load FSR register
        movwf   FSR_TEMP        ; Save FSR during interrupt
; test to see what caused the interrupt.
        btfss   INTCON,T0IF     ; Timer 0 caused interrupt ?
        goto    TEST_OTHER_INTS ; Not Timer0, go check others
INT_T0                          ; Yes, It was Timer0,
        bcf     INTCON,T0IF     ; clear Timer 0 interrupt flag


Well, you can put all your interrupt code in this area......
for timer 0 interrupt only that is.. you must write the test for other
types of
interrupts
.
.
.

INT_END
        movf    FSR_TEMP,W      ; Load original FSR register
        movwf   FSR             ; restore FSR register
        movf    save_pclath,W   ; Load the saved PCLATH
        movwf   PCLATH          ; restore it.
        swapf   STATUS_TEMP,W   ; swap STATUS register into W

                                ; ( this will restore original BANK #)
        movwf   STATUS          ; move W into STATUS register
        swapf   W_TEMP,F        ; swap W_TEMP
        swapf   W_TEMP,W        ; swap W_TEMP into W
        retfie                  ; return from interrupt

Well that's my interrupt code for dealing with PCLATH  in case someone
wants it
I will show my other interrupt code also.

TEST_OTHER_INTS
        btfsc   INTCON,INTF     ; RB0 caused interrupt?
        goto    INT_B0          ; goto B0 section
        btfsc   INTCON,RBIF     ; RB4,5,6 or 7 caused interrupt?
        goto    INT_B4567       ; goto portb change section
        goto    INT_END         ; SOMETHING ELSE???


   Giles L. Honeycutt
   gilesami@ix.netcom.com
.....................


Brooke wrote:
>
> Hi:
>
> I was having all kinds of problems getting table reads to work.
> It turns out that AN526 has some errors as well as the data
> sheet (DS30430A) for the PIC15F8X family as wel as the 16C8X
> family.
>
> Both data sheets in para. "4.3 Program Counter: PCL and PCLATH":
> ..."The contents of PCLATH are transferred to the upper byte of
> the program counter when the PC is loaded with a new value.
> This occurs during a CALL, GOTO or a write to PCL."
> This does NOT apply to the 16(F/C)8X parts since they have only
> 1K of memory and therefore do not use the PCLATH bits.
>
> I incorrectly thought that PCLATH would take on a value to match
> the current PC value after a CALL or GOTO.  This is NOT what the
> above sentences mean!
>
> What the data sheets do not say is that PCLATH is only controled by
> the programmer and not by the any of the commands.  Said another way
> PCLATH will only take on values that are programmed into it.  The
> ADDWF  PCL,F instruction only changes the PCL (8 bits) so unless
> your table is in program memory page 0 you will need to set PCLATH
> for proper addressing of the computed table address.
>
> erata for AN526:
>
> "SECTION 1, Computed Goto Instruction":
> change "Program 3" to "Example 3"
> change "Example 3" to "Example 4"
>
> Note that Example 4 fixes the callingroutine in seperate page from
> table problem and introduces the split table problem.
>
> "Interrupts": This entire paragraph is WRONG.  The silicon properly
> handles interrupts.
>
> "Section 2 Implementation for the PIC 16C5X Family":
>
> change "Table has to be in the top half of a 512 byte page"
>     to "Table has to be in the bottom half of a 512 byte page."
>
> Have Fun,
> Brooke