Timer 0 interrupt not getting triggered

http://www.keil.com/appnotes/docs/apnt_105.asp

The example i used

"the isr doent seem to be getting executed."

How do you know that?
What debugging have you done?
Have you tried it in the simulator?

"In the isr i m calling a function to display on 7-segment displays"

There's nothing about 7-segment displays in the application note - so this must be the first thing to check:

Does the interrupt work without your extra code?
Does your display code actually work?
Is something in your other code disabling the interrupt?

"Otherwise the normal program flow is based on Receiving and Sending data on UART0"

Again, there's none of that in the example.

Go back to the example, and make sure that it works as-is;
then add functionality a small step at a time, verifying that it still al works at each step...

There's nothing about 7-segment displays in the application note - so this must be the first thing to check
This is an addition from my side
And yes the display code works because i have been using the same code only that it wasnt interrupt driven before
It was like: while(RI!=1){display();}
BUt now i want to call this display funtion in an ISR

I tried a few things since my first post:
I commented out PT=0 line from timer 0 initialisation
And also commented out serial comm. part.
So i was left only with Timer 0 functionality.
I filled the display_variables with some values.
Then i could see a faint display of these values...

how can i configure the time for interrupt occurence??
in the example they have used 10ms.
if i reduce the time it will increase the brightness of display but it will interfere with serial interrupts, isnt it?
of course serial interrupts have a higher priority. It seems my display which is flickering is because of this reason only.

"if i reduce the time it will increase the brightness of display but it will interfere with serial interrupts, isnt it?"

It probably also interferes with the timer interrupt.

Calling functions from interrupts is generally a bad idea; you generally want the ISR to do just the bare minimum to recognise the event, then leave any handling of the event (including displaying stuff) to the "main" code...

how else can i call the display function?
previously i used it like following:
. while(RI!=0)
{display();}
. .
while(TI!=0)
{display();}
.

You talk about a faint display.

Is it LED or LCD?

If LED, you really should drive the display between the interrupts. You can't (or most definitely shouldn't) be in the interrupt long enough to give enough light.

If LCD, the update frequency affects the "strength" of the display.

Please read the instructions on how to post source code:
www.danlhenry.com/.../keil_code.png

What are you actually trying to display?

i receive numeric Ascii values in UART0 in response to a command.These received values i take into an array.
The values received can be characters 1 through 9, decimal or '-' sign.

while(RI!=1)
{display();}
switch(SBUF)
{
case 1:
a++;
arr1[a]=0x0F9;  etc, etc.....
}

Then i display these values on eight 7-segment display.

void display()
{
for(x=a;x>0;x--)
{
P0=disp[x];
P2=scan[x];  //3:8 decoding
}
}

So why do you feel the need to do the displaying in an ISR?

Alright let me correct my stand...there might not be a need to call display() in an ISR...or rather it is not recommended...
BUt the method being used as of now(the code i posted) isnt the best way to do it, isnt it?
Maybe i should try the following:
An ISR for serial interrupt which will be responsible for interpreting the data received and putting it into the display_array, instead of doing "while(RI!=1){display();}"
And apart from the ISR the program will do:

while(1)
{
display();
}

Please let me know what you think of it

"there might not be a need to call display() in an ISR...or rather it is not recommended..."

I suspect that it is both not recommended and not needed!

"the method being used as of now(the code i posted) isnt the best way to do it, isnt it?"

Clearly not - as it doesn't work!

"An ISR for serial interrupt which will be responsible for interpreting the data received and putting it into the display_array"

No - you've missed the point!

In general, an ISR should not interpret the data at all!
Simply receive and buffer it.
All interpretation and handling for display should generally be outside the ISR

Take a look at the interrupt-driven serial IO examples in the Downloads area...

Found this in MSC1210 User's Guide

Make interrupt routines small: Interrupt routines should be designed to do as little as possible, as quickly as possible, and leave longer processing to the
main program. For example, a receive serial interrupt should read a byte from SBUF and copy it to a temporary buffer defined by the user and exit as quickly as possible. The main program must then handle the process of interpreting the data that was stored in the temporary buffer. By minimizing the amount of
time spent in an interrupt, the MSC1210 spends more time in the main program, which means additional interrupts can be handled faster when they occur.

OK, you've got the 'pre' and '/pre' tags now, but don't you beleive in indentation for your code?
eg,

void display()
{
   for( x=a; x>0; x-- )
   {
      P0 = disp[x];
      P2 = scan[x];  //3:8 decoding
   }
}

And a little whitespace can work wonders for legibility!

Remember: don't use TABs to lay-out your code; use only spaces.
(TABs are entirely unreliable)

The 'pre' and '/pre' tags are for source code; don't use them for quoting other text - look what it's done to the width of the message!

:-0

"Make interrupt routines small: Interrupt routines should be designed to do as little as possible, as quickly as possible, and leave longer processing to the
main program. For example, a receive serial interrupt should read a byte from SBUF and copy it to a temporary buffer defined by the user and exit as quickly as possible. The main program must then handle the process of interpreting the data that was stored in the temporary buffer. By minimizing the amount of
time spent in an interrupt, the MSC1210 spends more time in the main program, which means additional interrupts can be handled faster when they occur."

Exactly - just what has been said already!