Hiya Roy, Embrace indirect addressing with open arms -- you'll love it -- it's a perfect fit especially when dealing with buffers: It's late for me here in Massachusetts USA, so I'll give you some help tonight and I'll try my best to answer your specific questions tomorrow. A lot of your questions can be answered by simulating things in MPSIM under MPLAB -- it's fun to do -- setup some watch variables, single-step and view the SFRs and GPRs, etc. Let me try to get you some immediate help with your buffer situation: For example, to copy a 256-byte buffer in some bank to a 256-byte buffer in another bank: ; Get ready to copy 256 bytes CLRF WREG ; Point to beginning of transmit buffer ; (& operator -- address-of operator) LFSR FSR0, TxBuffer ; Point to beginning of receive buffer ; (& operator -- address-of operator) LFSR FSR1, RxBuffer CopyBuffer ; Copy current byte from receive buffer to transmit buffer ; (Perform indirection or dereference the pointer with post increment) MOVFF POSTINC1, POSTINC0 ; Keep copying from one buffer to the other until finished DECFSZ WREG BRA CopyBuffer Notice the power of this simple indirect addressing code -- no explicit RAM bank manipulation is necessary. One could certainly say that this is true because I used the MOVFF instruction (which ignores the BSR register) and they'd be right -- so let me give you another example without MOVFF: ; Get ready to copy 256 bytes CLRF LoopCount ; Point to beginning of transmit buffer ; (& operator -- address-of operator) LFSR FSR0, TxBuffer ; Point to beginning of receive buffer ; (& operator -- address-of operator) LFSR FSR1, RxBuffer CopyBuffer ; Copy current byte from receive buffer to transmit buffer ; (Perform indirection or dereference the pointers with post increment) MOVF POSTINC1, W MOVWF POSTINC0 ; Keep copying from one buffer to the other until finished DECFSZ LoopCount BRA CopyBuffer Regarding your comment about assigning 12-bit addresses to variables: This is necessary to allow MPASM to *automatically* resolve the RAM access bit in assembly instructions that use the access bit. This just gives MPASM the "smarts" to know (via the address of the variable you supplied) whether to set or clear the RAM access bit. This is very important because the RAM access bit determines if the access bank will be used or if the BSR (Bank Select Register) will be used. The 4-bit BSR register (actually its is an 8-bit register, but only the lower nybble is used) contains the current bank and can be changed with the MOVLB instruction. From what I found so far, when writing relocatable code, your variable addresses declared with the RES directive wind up being 24-bits, and that's ok -- as long as the addresses are at least 12-bits, MPASM will automatically resolve the RAM access bit for you. This would be only one of many reasons not to write absolute code since the user could inadvertently define variable addresses (using CBLOCK or EQU) that are fewer than 12-bits. As many people have so eloquently said many times here in the past, writing 'absolute code' assembly language (versus relocatable code) gives you plenty of rope to hang yourself with. I made a New Year's resolution to switch to writing relocatable code and I'm having a blast -- it really did not take that long to pick up the basics. I previously never invested the time because I thought I completely switched to writing PIC code in C, but the PIC18F architecture made assembly language fun again. But now I'm venturing off the topic of your post... Got to get some sleep -- hope this helps Roy. Please post again if this does not make sense -- my brain is fuzzy right now. Best regards, Ken Pergola -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body