Pic16f84a delay 250 second
Wow, I remember the ol' 84a... That was my first ever microcontroller.

Making any long-term timing on a microcontroller is not an easy task.  If you have interrupts firing they can cause calibrated delay loops to be themselves delayed, and over long periods like 250 seconds small errors soon mount up into big errors.

So there's basically 2 ways to tackle delays without adding extra hardware - calibrated delay loops and timer interrupts.

A calibrated delay loop is a function that you can call and will delay for a known pre-defined period. Typically it involves counting the number of clock cycles required to both call an execute the delay function, and a loop with a number of NOP instructions used to make the delay the right length.  Getting the balance between the number of NOP instructions inside the loop and the number of iterations of the loop is important for accuracy - the number of NOP instructions basically sets the granularity of the delay.  Also as mentioned before, if an interrupt occurs the delay will itself be delayed and things will start to slip.  So it's a reasonable solution for rough delays for things like blinking an LED, but for long term timing it's not going to be accurate.

The second option is to use a timer interrupt.  Now, a timer runs much too fast to be able to time 250s.  So you need to time a much shorter period and "add them up".  For instance, I often set a timer to trigger once every millisecond, then in the interrupt routine I add 1 to a millisecond counter.  Then in a delay routine you just look at the start of it to see what the current millisecond count is, and then wait in a tight loop checking the new current millisecond count and comparing it to the old. When a certain time has elapsed then it's time to finish the delay.  For your situation it may be better to have the interrupt trigger once a second so you're just counting seconds rather than milliseconds (which means you're working with much smaller numbers - 250 instead of 250000).  However, this method does have down sides of its own: chiefly that you have a pre-defined granularity and your delay will be ± that granularity - that is you will start the delay "at some point during a second" and finish it "on a second", so there's some leeway around where you start the timing from.  The smaller your measured period the finer your granularity, and the more accurate your delay.

A third option, not grouped with those two above, is to use an external Real Time Clock (RTC) chip to do the timing for you.  That is by far the most accurate method over long periods of time, and most RTC chips have an alarm function that can trigger an external interrupt at a pre-specified time.