[Coco] Clock "Timing".

[Arthur Flexser]

As I recall, POKE&HADEB,&H39 will knock out the break key check between
Basic program statements (assuming this is a CoCo 3 or a CoCo 1/2 where the
ROMs have first been copied to RAM), so you or anyone is welcome to
investigate how much effect his has on TIMER's accuracy while running a
Basic program.  I recall that it did improve accuracy significantly, though
that's of course a subjective judgment.  As you point out, the "fast" break
key check version would make this less of a factor.  (This was introduced
in Color Basic 1.1 or 1.2, I think, not 1.0.  Couldn't have been 1.0, since
it messed up some preexisting programs when the fast version appeared.
Disk Basic 1.1 patched things to undo the fast break key check.)

Art


On Tue, Apr 4, 2017 at 4:12 PM, William Astle <lost at l-w.ca> wrote:

> 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.
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>