[Coco] Clock "Timing".

[William Astle]

On 2017-04-04 01:39 PM, Arthur Flexser wrote:
> Actually, the TIMER function's main source of inaccuracy is that reading
> the keyboard, which occurs between Basic statements in checking for the
> break key, causes an occasional interrupt to be skipped.  (That's due to
> the presence of a couple of LDA $FF02 instructions within the keyboard
> polling routine that cause the IRQ flag to be cleared.)  If you knock out
> the break key check, TIMER's accuracy improves considerably.

Huh. You learn something every day. It's obvious now that it's been 
pointed out. Looking at the keyboard scanning code, I can see you get 
roughly 17 reads of FF02 if the keyboard is idle (9 times ROL and 8 
times TST) which is the worst case. Of course, that's assuming the ROM 
version in question doesn't do the quick "is a key down" check (Color 
Basic 1.0 or the Coco3) which has a "CLR $FF02" instruction (which, 
oddly, does count as a read on the 6809 if I recall correctly) which 
would substantially reduce the odds of getting hit by that.

Still, I wouldn't have thought that timing would hit often enough to 
make a noticeable difference overall since the 6809 will respond to the 
IRQ request within an instruction or two of the interrupt signal being 
raised (roughly - the signal has to be there for some number of cycles 
and it has to wait for the current instruction to finish before it can 
service the interrupt when it chooses to). It would require some fairly 
unlucky timing.

I can see that during program execution, the keyboard could be scanned a 
lot more often than waiting at the prompt (since there is a "debounce 
delay" busy wait between keyboard polls). That would increase the odds 
of missing an interrupt as a result.

I never noticed any particular systematic bias on the count when I was 
running an onscreen clock driven by the IRQ. Well, except during disk 
sector I/O or tape I/O, both of which disable the IRQ. Tape having a 
much larger overall impact. Of course, the Mark I Eyeball is not the 
best tool for measuring such things.