Why not do something useful with the data received instead of wasting time in the doodle routine or writing everything received into another array?

Once you receive the terminating character, write your data to EEPROM, then wait for the next packet.

Also, you don't need all this;

ASM
LIST
INCLUDE 'M16F87X.INC' ; PM header
DEVICE PIC16F877, HS_OSC, WDT_OFF, PWRT_ON, BOD_ON, LVP_OFF, CPD_OFF, WRT_OFF, DEBUG_OFF, PROTECT_OFF
XALL
NOLIST
ENDASM

Just drop in your fuse definitions like below, and leave the rest to PBP. It does all this for you.

@ DEVICE PIC16F877, HS_OSC, WDT_OFF, PWRT_ON, BOD_ON, LVP_OFF, CPD_OFF, WRT_OFF, DEBUG_OFF, PROTECT_OFF

This routine;

WHILE RCIF
BytesBK[ByteBKN]=RCREG
ByteBKN=ByteBKN+1
WEND

Just clears whatever characters may have arrived after the terminating character was received. You want to be sure RCREG is empty & RCIF is clear before your next data packet shows up.

At some point, you're going to need some kind of synchronization with your PC program sending your data. You can't just keep slamming data into the USART without doing something with it to clear the array, and you're going to need some time to write your data to EEPROM (without interrupts enabled).

You do not want interrupts enabled when writing data to the EEPROM, so you will definitely want to implement something to let the PC know you're busy.

Example scenario:

PIC requests data from PC.
PC sends packet with terminating character.
PIC receives & stashes data in array until terminating character is received.
PIC processes data.
PC waits for signal from PIC to send next packet.
PIC says OK, let's have it.
PC sends next data packet.

Two way communications is the key.

Strip all the useless stuff out of my example. You don't need to send everything back to the PC terminal program or waste time in the doodle sub-routine. That was just an example showing how to receive streaming data, and key on the terminating character to find the end-of-packet.

The time you spend in re-writing everything into another array, pauses, etc,, could be used for processing your inbound data, and let you setup & wait for the next packet.

Note: Watch for stuff like this;

On Interrupt Goto Main
Doodle:
FOR X = 0 TO 250 : PAUSEUS 20 : NEXT X
FOR X = 0 TO 250 : PAUSEUS 20 : NEXT X
RETURN
INTCON=$80

Program flow will never reach INTCON=$80 because it RETURNs before landing on it.