[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