The algorithm was meant for a Processor with about 33 I/O lines and the need for a fair amount of servos.  On the PICFlyer I have dedicated an entire PIC to control servos.  The PWM/External circuitry method does work, but requires external parts.  I want to keep size/weight to a minimum.  The only external circuitry that may help is a schmitt trigger to clean the signal, but not even that is required.  If someone needs more than, say, 20 servos on board an airplane, there must be enough power availiable on board for another PIC.  the remaning 13 I/O lines are for the parallel communication/Expansion bus.
 
My solution for the "screwed up timing" problem was a simple sacrifice, the interrupts on thededicated servo controllers are off-limits.  I have simply decided to use a 13 wire parallel communications scheme instead of serial.
The "controller processor" places an 8-bit data packet on the data bus, the address of the "desired servo controller" on the 4-bit address bus, and waits.
When the servo controller is not processing a pulse, the entire 8bit package can be taken at once, then an ACK signal (the 13th data bus line) is brought high by the servo controller to signal it has the data, and is ready for more.
 
This and other communications methods can be used to eliminate timing issues, allowing the interrupt code to live in peace.  Bottom Line: No Jitter.  I have been playing with this code all day, it is great.  I am using a 4MHz 16C84 and I could easily do more but I am out of I/O lines.
 
Note that this algorithm wasn't designed for 128 servos to be controlled by one processor.  (Geez that is way more than I ever hope to own)  External circuitry may require more brainpower than I am willing to expend.  What if the processor fails? 128 control points, gone.  To me, generating an interrupt once per mS is excessive.  It simply depends upon your application.  I want a great way to control servos, in software, and have a chunk of free time.  That is what this code does.
 
I decided that even a realtime-controlled, model airplane does not need a servo update of 50 times/sec.  Thats means that every single pulse the servo receives would be different!  I can do exponental/differential rates myself in software.  Simple calculus/physics is all that takes. Resolution, however, is more important.  The Serial-Parallel servo controller combined with a parallel communications bus is more than enough to maintain a very fast thoroughput, well above 50x/s. Maybe this evening I will draw up a servocontrol library.....
 
Anthony, KC5LHH