[FONT=Verdana][SIZE=2][COLOR=#000000]msec250: ; a subroutine to delay 250 msec
movlw D'250' ; W is changed but no separate register needed
nmsec: ; could call it here with # msec in W
nop ; each nop is 0.122 milliseconds
nop
nop ; each total loop is 8 X 0.122 = 0.976 msec
nop
addlw H'FF' ; same as subtracting 1 from W
btfss STATUS, Z ; skip if result is zero
goto nmsec ; this is 2 X 0.122 msec
return ; back to calling point[/COLOR][/SIZE][/FONT]
Well it depends on the crystal/clock of course. But based on the comments, you should have a (250*0.976)ms delay. +3 more cycles for the call and return.
Based on the timing in the comments, it is meant for a 32.768KHz crystal.
I used to enjoy figuring out the delay counters and think it is good for experience to do. But now, I just go to: and use its program. The times are pretty close and easily adjusted, if needed.
My apologies if you already know this, but...NOP = 1 instruction cycle = 0.000122 seconds (from the comments).
Then, 0.000122 / 4 (4 clock ticks per instruction) = 0.0000305 seconds per tick. Take the inverse and you get 32768Hz (or close enough).
That is exactly what I would suggest. Use a debugger, set a breakpoint above where you want to start measuring and one after, and use the stopwatch feature. It will tell you how many instruction cycles it took, as well as the actual time delay.
Der Strom