[Coco] Clock "Timing".

William Astle lost at l-w.ca
Tue Apr 4 18:21:39 EDT 2017


On 2017-04-04 03:39 PM, Arthur Flexser wrote:
> 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.)

If you look again at what I wrote, you'll note that my indication of CB 
1.0 was for the "doesn't have the fast key check" case, not for the 
"introduced in" case.

Also, Disk Basic 1.1 *adds* the fast break check, not removes it. (See 
code at C8B2 in the Disk Basic 1.1 command interpretation loop replacement.)

The Coco3 startup actually patches out the Disk Basic 1.1 "fast break 
check" bit. The actual in ROM in the Coco3 has the fast key scan bit at 
A1C1 removed without needing a startup patch. Presumably both of those 
changes were left behind after they changed their minds about keyboard 
handling. (They probably couldn't figure out how to make the keyboard 
interrupt work usefully.)

I'd do the experiment if I had my real Cocos available. Maybe we can 
arrange one at the fest. A stock Coco3 should be sufficient to test for 
TIMER drift since it runs without the keyboard scan optimization. Then 
the break check could be disabled and the test run again. With Disk 
Basic 1.1 in ROM mode, you can even test the "fast break check" version 
for drift on a Coco3.



More information about the Coco mailing list