Richard,

Great amount of work on this library.
I have to hand it to you, a lot of coding you worked out there.

For my own edification, I have a question for you.

In "TFT_SPI.PBPMOD" you have your setxy 8-element byte array for y0, y1, x0 & x1 declared.
This I understand.
You do this to support Word variables for x0 & x1 and space for y0 and y1 to be used as Word variables in the future,
but used as byte variables today. This I assume as the TFT display's y axis in less than 255.

One thing I notice though is that you have the following ASM address mapping for the individual x&y elements.
Code:
ASM       
y0 = _setxy +1   
y1 = _setxy +3
x0 = _setxy +4
x1 = _setxy +6
ENDASM
Then you have the following PBP variable declarations.
Code:
x0 var WORD EXT 
x1 var WORD EXT
y0 var byte EXT 
y1 var byte EXT
Understood at this point.
x vars are Words and y vars are Bytes.

But here is my question, I thought I noticed you use a lot of manual (CHK?RP/movlw/movwf) manipulation within the USERCOMMANDS for
the y0 & y1 variables instead of using PBP standard macros for MOVE?xx.

Could you not change the ASM address mapping for the y0 & y1 elements to use Little Endian style, instead of Big Endian, and then use the
standard PBP macros (MOVE?BB, MOVE?CB, MOVE?WB)?
Wouldn't that simplify the ASM in the USERCOMMAND macros?
Doesn't the PBP standard MOVE?xx macros take care of the BankSel testing/switching and movement of the High and Low bytes for you?

Code:
ASM       
y0 = _setxy +0   
y1 = _setxy +2
x0 = _setxy +4
x1 = _setxy +6
ENDASM
I may be off base, but was just curious.
I didn't read through the entire "TFT_SPI.PBPMOD", to see if there was another reason you have y0 & y1 defined in ASM as Big Endian.