This may just be a typo in your post, but the line where you enable the Timer Compare interrupt says:
TIMSK0 != (1 << OCIE0A);
... when it should say ...
TIMSK0 |= (1 << OCIE0A);
It's subtle, but if that's what your code actually was, then you were comparing TIMSK0 to a constant rather than assigning to it (and therefore never actually enabling the interrupt).
On a sidenote, you can more concisely write:
TIMSK0 |= _BV(OCIE0A);
... instead of ..
TIMSK0 |= (1 << OCIE0A);
in avr-libc, if you're into that sort of thing :-).
First, using abbreviations, especially ones that can have multiple expansions and on a international list is not a good idea. At first I thought "RC" meant resistor capacitor, but maybe you mean remote control instead? Do it right and spell it out, or at least define unusual or ambiguous abbreviations before using them.
Second, you need to read the PIC datasheet. After doing that you will see that this PIC has a number of external interrupts. The CCP module in capture mode can be one source of external interrupt, but there are others. These include the INT pin, the interrupt on change pins, and even the two comparators.
If you plan to use the CCP module as a PWM generator, then you can't use it in capture mode to generate a external interrupt. However, there may be other ways to achieve what you want other using a CCP module. Explain exactly what this "PPM" (another ambiguous abbreviation) signal looks like, what data is encoded by it, and how it is encoded. With that information perhaps we can get clever about interpreting it using some other hardware.
All that said, I see little point is deciding to use such a old PIC, especially if it doesn't really have the hardware you want. There are many many PICs to choose from. Step back and give the real specs of what comes in and what needs to go out of this block, and we can probably help pick a PIC and advise how to use it effectively. For example, some of the 24 bit core parts have a relatively large number of modules that can do CCP-like things. On those, there are separate modules for capture and PWM so they are not called CCP modules.
Added
You now say this block needs to interpret two usual "hobby servo" 1-2 ms pulse signals and produce two bi-directional PWM motor drive outputs accordingly.
The PIC 16F628A is the wrong PIC for this job. Since this is apparently a one-off, there is no point trying to save a $ or two at considerable cost in firmware complexity. Get the right PIC with the right mix of peripherals and have those peripherals do most of the work.
The dsPIC33FJ128MC802 looks like a good candidate after a couple of minutes with Microchip's MAPS parts selector tool. It comes in a 28 pin package, and has both input capture modules and PWM modules. It also has up to 8 motor control PWM outputs, which could allow you to use relatively simple H bridge hardware with the PIC driving each corner of the H bridge from a separate pin.
Best Answer
Say that you have enabled the TMR0 and TMR1 interrupts by setting TMR0IE and TMR1IE. When either of the interrupt events happen, their interrupt flags (TMR0IF or TMR1IF) get set. This doesn't cause the code to actually vector to the interrupt routine unless the GIE (global interrupt enable) bit is also set.
So, say that GIE has been set, and you get a TMR0 overflow. This sets TMR0IF, vectors to the interrupt location, and clears the GIE bit. Now that GIE is cleared, future interrupt triggers won't cause any code vectoring. However, the interrupt flags still get set.
Now, say that you are in your interrupt routine. The TMR1 interrupt gets triggered. This sets the TMR1IF bit, but doesn't do anything else. The bit simply stays set.
When your interrupt routine is finished, you use a
RETFIE
statement (in assembly) or areturn();
(in c). This vectors back to your mainline code, and sets the GIE bit.Now that both the GIE and TMR1IF bits are set, it causes an immediate vector back into your interrupt code.
So, you don't really lose interrupt data; it just gets delayed.
An common way to structure an ISR is like this:
But, if you expect to have concurrent interrupts, you might want to allow them both to be processed in just one pass through the ISR:
There's one last issue to be aware of. Say that both interrupt flags get set at the same time (or very close to the same time). By the time the code vectors to the interrupt routine both flags will already be set. The ISR doesn't know which one got set first; it simply runs through your code. So in my earlier examples the TMR0 interrupt will get serviced first, even if the TMR1 flag was slightly earlier.
I hope this helps :)