These are the notes I made while reading through your program. I haven't identified the bug, but I strongly suggest you follow this advice. When you do, the cause of the problem will _probably_ (based on my previous experience) become obvious to you. Even if it doesn't, improving the quality of documentation in your code will be hugely beneficial when you come back to it in six months to add a feature, when the details of how it works are not fresh in your mind.
Your program should start with a comment block that contains the following information:
Program name
Location and name of this source file (handy if you print it out; when you find an old printout later, you will have a better chance of locating the file that the printout was made from);
Your name and email address;
Purpose of the program and a brief description of what it does.
Then you should record the changes made to the file. Each time you make a change you should record the when, who, what and why. In other words, the date, your name or initials, what was changed, and if it's not obvious, why the change was made. Also when you make a change, consider how to make the comment useful to your future self. So don't just say "changed npulses to 5", write "change npulses from 4 to 5 because ..." and for bug fixes, mention the known or possible symptoms of the bug that you fixed.
This may sound like a lot of work, but it's an investment that will, on average, save you a lot more work later.
I often find that adding documentation "magically" solves some problems.
It seems odd to me that the jumps to start and inter, at 0x0000 and 0x0004, are coded as calls instead of jumps (gotos). Maybe it's something strange about the PIC. (I'm not familiar with PICs.)
You should clearly comment the purposes of your time delay functions. The most basic information - that is, how long each function delays for - is missing!
It is normal to place a comment block at the start of each function, that documents its purpose and also states which registers and variables it uses for parameter input (if applicable) and output (if applicable), and which registers and variables it modifies. This can help you avoid problems caused by calling a function that destroys a register or a variable that is being used by the calling function for a different purpose.
On the same subject, I would use meaningful names for your temporary counter variables used by the functions. Names like ted, ned and edd are meaningless; as soon as you use a variable for a specific purpose, you should give it a meaningful name. This will also help you avoid problems caused by different parts of the program using the same variables and effectively scrambling the values that are being relied on by other parts of the program.
All your "button detect" functions need proper comment blocks. The purpose of this is three-fold. First, it clarifies the purpose of the function in your mind. Second, it allows you to quickly see whether the logic of the function matches the description. Thirdly, when you call the function, you can check its description to make sure that it's the function you intended to call.
Also your functions should be named with something more than a number to distinguish them. For example, a function that delays for one millisecond should be called delay_1ms instead of delay2.
I don't understand the meaning of the lines that say "movlw 500 ; decimal number 100 ..." Have you updated the number in the instruction but not updated the comment?
Your main function has a section with 360 calls in a row. This is ridiculous and unmanageable. You need to restructure your code to avoid this, using loops with control variables. Once you have documented what your functions do, and reposted the code, someone here will be able to suggest how to do that.
That should be enough for you to go on with. Please take my suggestions seriously; they are based on 25 years of hobby and professional embedded systems programming experience and they are intended to make your job easier.
