I believe the 56us delay you are mentioning is the off-time of the output until it goes high again = the time it is open for the spark to burn.
What I'm referring to is the time between the trigger of the hall sensor until the output goes low. This is the delay that regulates the ignition angle.
However, even if the ignition angle is set to maximum (all variables in the lookup table are 0) there is still a processing delay of 60us.

I have now done another test, and put all the numbers in the lookup table to the value 2. This made the delay time to approx 260us. By this I conclude that the resolution of the ignition timing is 100us, what I mean is if you change the value in the lookup table by 1, there is 100us more delay between the input and output.
So, it seems it's not possible to compensate for 60us in the lookup table, since subtracting 1would then be over compensating by 40us, so the ignition would actually be advancing slightly with RPM. (providing the trigger has the margin)
The only way to make it exact is to change the code to either increase the resolution or add another 40us delay and then compensate by -1 in the lookup table.. Maybe adding a 40us timer would not be so hard.. maybe I will try that..

I'm comparing the signal on pin 6 and 7 which only gives the delay in the processor, everything else is excluded. The internal delay in the processor seems to be abt 60us even if it is set to 0 in the lookup table, so this is the minimum delay in the processor. Have you tried to measure it in this way?

This is normal with a processor as far as I know, you will always have some delay, since it has to do a number of loops before the signal is processed and output is activated. In this case the processing time seems to be approx 60us.
This means a 7,2deg delay of the spark @ 20k rpm. The other 3deg I'm seeing could be from the hall sensor etc. Or it could also be that the delay in the processor is actually a little bit more than 60us since my oscilloscope is old, and not calibrated in any way..

Actually, maybe over-compensating by subtracting 1 from the values in the lookup table would give a nice result anyway, to compensate for small delays in the hall sensor too.

More experiments later..