Bob,
Wow! What a great explanation! I think I actually understand now.
However, I do have a few questions about the sample you gave for a 256
element lookup table. I'm not quite sure about your manipulation of
PCLATH. Just so you know, I'm using the 16f628, so I do have a PCLATH to
worry about.

> What I'll do however, is show you one way of handling a table of exactly 256
> entries, as you request for your application. For this example I'll assume
> you have a PIC with a PCLATH register, but the same principles apply if you
> don't.
>
> First, the call to do the lookup:
>
> At this point we assume that PCLATH is pointing to the page containing your
> main code:
>     ...
>     call    table_lookup             ; look up value in table
>     movwf       lookup_result    ; store the resulting value

Ok, here we call the table lookup subroutine, which is still in the same
page as my main code. It executes, then when it returns, the next line
executed is the movwf which gets the lookup result from the w register.

>
> now the answer is in W, but PCLATH is no longer pointing to our main code
> page, so we might want to put it back with something like this:
>
>     movlw    high(main_code_page)        ; Get 8 msbits of main code page
>     movwf    PCLATH

I don't really understand where this fits in. By modifying the PCLATH
here, aren't we going to effect the next instruction to be executed?

>
> And later in the same page as your main code:
>
> table_lookup:
>     movlw        high(lookup_values)        ; Get 8 msbits of address of
> lookup table values
>     movwf        PCLATH                       ; Get ready to jump into the
> lookup table values
>     movf    index_value,W    ; get table index
>     movwf        PCL                                ; Jump to the lookup
> table values

I basically understand this part, except that by modifying the PCLATH
higher up, doesn't program execution change to another page immediately?
How is it that it doesn't change until after the PCL modification?

>
> Someplace else in your code you place the 256 entry table, which has to
> start on a page (256-byte) boundary. For example:
>
>     org    0x200
> lookup_values:            ; start of table

Ok, so we set ourselves up right on a boundry. The lookup_values: is
just a label, so it doesn't take a memory location, and we're still on
the page boundary.

>     retlw       value_0    ;value to return for index of 0
>     retlw        value_1  ; value to return for index of 1
>     ...
>     retlw        value_255 ; value to return for index of 255

When we execute a retlw, we return back from the original call, back in
the first section (the call table_lookup). But, we haven't reset out PCL
and PCLATH. I'm assuming this is where that little piece of code I don't
understand actually fits in. I feel like I'm missing something basic,
and when I find out everything will fit. I think it had to do with the
fact that I don't understand how modifying the PCLATH register doesn't
result in an immediate jump, and I don't understand how the PCLATH
register is modified on the retlw. Anyway, if you could help me out, I'd
really appreciate it. You've done an excellent job so far, and believe
me, I really do appreciate it!

Thanks again!

Josh

--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        -Douglas Adams

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.