Benchmarking the CoCo keyboard – part 5

See also: part 1, part 2, part 3, part 4, part 5, part 6, part 7 and more (coming “soon”).

By now, many of you have realized that I have no idea what I am doing. It’s through great comments that this series is evolving into something hopefully useful. For example, MC-10 programmer extraordinaire Jim Gerrie left this comment:


I think the POKES are not needed for Coco3 or anything below BASIC 1.2 on the Coco 2.

Jim Gerrie

This reminded me of a cryptic code sample he posted earlier this year on Facebook:

7 POKE341,255:POKE342,255:POKE343,255:POKE344,255:IFNOT((PEEK(341)ANDPEEK(342)ANDPEEK(343)ANDPEEK(344))=255)THENK=PEEK(135):X=X+(K=8ANDX>.)-(K=9ANDX<255):Y=Y+(K=94ANDY>.)-(K=10ANDY<191)

You can see the keyboard KEYBUF memory locations (341-344) being used, as well as the “last key pressed” location (135). Typing in the above code snippet produces a black PMODE 4 graphics screen with a dot you can move around using the arrow keys.

My head spins just trying to figure out the logic of the use of NOT, AND and logical comparisons (a > b). The end result is an all-in-one routine that adds or subtracts values to X and Y coordinates. Clever.

Since this code is basically reading a key that is being held down, it only gets back one value (such as Up, Down, Left or Right). It does not support diagonal movement.

Here’s my much longer version that will support diagonals:

0 REM ahkeybd.bas
30 IF PEEK(&H155)=&HF7 THEN IF Y>. THEN Y=Y-1
50 IF PEEK(&H157)=&HF7 THEN IF X>. THEN X=X-1
90 GOTO 20

Also, SPACE can be used to erase. But it is still really slow.

Make go faster

Let’s benchmark my version, which is already sped up by using hex constants. I’ll take out the part that deals with the SPACE bar, and remove unneeded spaces.

0 REM arrowbench.bas
10 TIMER=0:FOR A=1 TO 1000

This produces 2139.

I should be able to speed it up further by replacing the PEEK values with variables:

0 REM arrowbench2.bas
5 V=&HF7:U=&H155:D=&H156:L=&H157:R=&H158
10 TIMER=0:FOR A=1 TO 1000

This actually slows down to 2864. I did not expect that. Okay, no variables for my version, then.

Now let’s benchmark Jim’s much smaller (and far more clever) routine:

0 REM arrowbench3.bas
10 TIMER=0:FOR A=1 TO 1000
20 POKE341,255:POKE342,255:POKE343,255:POKE344,255:IFNOT((PEEK(341)ANDPEEK(342)ANDPEEK(343)ANDPEEK(344))=255)THENK=PEEK(135):X=X+(K=8ANDX>.)-(K=9ANDX<255):Y=Y+(K=94ANDY>.)-(K=10ANDY<191)

This prints 3609. So far, it looks like mine is faster. But let’s do the same optimizations to Jim’s code.

Let’s convert the decimal constants into hex:

0 REM arrowbench4.bas
10 TIMER=0:FOR A=1 TO 1000

This lowers it to 2120! That’s slightly faster than my version. I did not expect that.

Even though using variables was slower in my version, let’s see what happens with Jim’s:

0 REM arrowbench5.bas
5 V=&HFF:U=&H155:D=&H156:L=&H157:R=&H158:P=&H87
10 TIMER=0:FOR A=1 TO 1000

To my surprise, this drops it even further to 1715. It is now twice as fast as the original version that used decimal constants!

But why did mine get slower when I swapped out the same variables? I *speculate* that the processing of things like AND and NOT and comparisons may be alot faster on variables than whatever it has to do when encountering constants, but that’s a benchmark digression for another time.

To test that theory, let me change the POKEs back to hex and see if that slows down or speeds up. We’ll just use the variables in the AND/NOT stuff.

0 REM arrowbench6.bas
5 V=&HFF:U=&H155:D=&H156:L=&H157:R=&H158:P=&H87
10 TIMER=0:FOR A=1 TO 1000

Nope. This slows down to 1947. For whatever reason, the variables sped up Jim’s, but slowed down mine.

I suppose we could try changing the remaining hex constants to variables and see what that did, but for now, I’ll just say:

Nicely done, Jim!

Can we find a way to do this but also support diagonals?

To be continued…

One thought on “Benchmarking the CoCo keyboard – part 5

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.