Category Archives: Color BASIC

Exploring Atari VCS/2600 Adventure – part 4

Objectively speaking

Welcome back to the world of Atari Adventure! After spending some time figuring out how the rooms were drawn, it’s time to look at how the game objects are drawn.

Adventure contains many objects that can be displayed:

Bat
Bridge
Castle gate (or Portcullis – “a strong, heavy grating sliding up and down in vertical grooves, lowered to block a gateway to a fortress or town.”)
Chalice
Created by Warren Robinett (author’s name)
Dot (for getting in to the easter egg room)
Dragon (red, green and yellow)
Key
Magnet
Number “1” (for game select screen)
Number “2”
Number “3”
Sword

Some objects have multiple frames. For instance, the bat has two: wings up, and wings down. The dragon has three: open mouth, closed mouth, dead. The dragons can also be drawn facing left, or facing right.

I also found an entry for something called “Surround,” which appears to be the the square around the player in the invisible mazes.

In the ROM disassembly, it looks like these objects are just stored as bytes that represent them:

GfxChallise:
  .byte $81 ;X      X                                                                  
  .byte $81 ;X      X                                                                  
  .byte $C3 ;XX    XX                                                                  
  .byte $7E ; XXXXXX                                                                   
  .byte $7E ; XXXXXX
  .byte $3C ;  XXXX
  .byte $18 ;   XX
  .byte $18 ;   XX
  .byte $7E ; XXXXXX
  .byte $00

Above, the game-winning chalice appears to be 8×9.

The dragon is much larger:

GfxDrag0:
  .byte $06 ;     XX 
  .byte $0F ;    XXXX 
  .byte $F3 ;XXXX  XX 
  .byte $FE ;XXXXXXX 
  .byte $0E ;    XXX 
  .byte $04 ;     X
  .byte $04 ;     X
  .byte $1E ;   XXXX
  .byte $3F ;  XXXXXX
  .byte $7F ; XXXXXXX
  .byte $E3 ;XXX   XX
  .byte $C3 ;XX    XX
  .byte $C3 ;XX    XX
  .byte $C7 ;XX   XXX
  .byte $FF ;XXXXXXXX
  .byte $3C ;  XXXX
  .byte $08 ;    X
  .byte $8F ;X   XXXX
  .byte $E1 ;XXX    X
  .byte $3F ;  XXXXXX
  .byte $00

But it is still represented as 8 pixels wide. The code to display it must magnify it to make it larger on screen.

Even the bridge, the widest object displayed in the game, is represented as 8-bits wide. This is the first thing we will need to dig in to… What controls how large these small object representations are drawn?

Also, it appears every object is terminated with a $00 rather than having the length at the start. For example, instead of this:

10 READ N:FOR I=1 TO N:READ A$:PRINT A$:NEXT:END
20 DATA 10,a,b,c,d,e,f,g,h,i,j

…it works like this:

10 READ A$:IF A$="0" THEN END ELSE PRINT A$:GOTO 10:END
20 DATA a,b,c,d,e,f,g,h,i,0

Since both would have taken the same amount of data storage space in the ROM, I am betting the code to parse that data may have been smaller to loop and check for 0 versus loading a size and counting down.

Also, this presents a restriction for the graphics — none can contain an “empty” row in the graphic ($00). Because of this, each line (byte) must have at least one pixel set. This explains the dots in the easter egg signature!

;Object #4 : State FF : Graphic
GfxAuthor:
 .byte $F0    ;XXXX
 .byte $80    ;X
 .byte $80    ;X
 .byte $80    ;X
 .byte $F4    ;XXXX X
 .byte $04    ;     X
 .byte $87    ;X    XXX
 .byte $E5    ;XXX  X X
 .byte $87    ;X    XXX
 .byte $80    ;X
 .byte $05    ;     X X
 .byte $E5    ;XXX  X X
 .byte $A7    ;X X  XXX
 .byte $E1    ;XXX    X
 .byte $87    ;X    XXX
 .byte $E0    ;XXX
 .byte $01    ;       X
 .byte $E0    ;XXX
 .byte $A0    ;X X
 .byte $F0    ;XXXX
 .byte $01    ;       X
 .byte $40    ; X
 .byte $E0    ;XXX
 .byte $40    ; X
 .byte $40    ; X
 .byte $40    ; X
 .byte $01    ;       X
 .byte $E0    ;XXX
 .byte $A0    ;X X
 .byte $E0    ;XXX
 .byte $80    ;X
 .byte $E0    ;XXX
 .byte $01    ;       X
 .byte $20    ;  X
 .byte $20    ;  X
 .byte $E0    ;XXX
 .byte $A0    ;X X
 .byte $E0    ;XXX
 .byte $01    ;       X
 .byte $01    ;       X
 .byte $01    ;       X
 .byte $88    ;   X   X
 .byte $A8    ;X X X
 .byte $A8    ;X X X
 .byte $A8    ;X X X
 .byte $F8    ;XXXXX
 .byte $01    ;       X
 .byte $E0    ;XXX
 .byte $A0    ;X X
 .byte $F0    ;XXXX
 .byte $01    ;       X
 .byte $80    ;X
 .byte $E0    ;XXX
 .byte $8F    ;X   XXXX
 .byte $89    ;X   X  X
 .byte $0F    ;    XXXX
 .byte $8A    ;X   X X
 .byte $E9    ;XXX X  X
 .byte $80    ;X
 .byte $8E    ;X   XXX
 .byte $0A    ;    X X
 .byte $EE    ;XXX XXX
 .byte $A0    ;X X
 .byte $E8    ;XXX X
 .byte $88    ;X   X
 .byte $EE    ;XXX XXX
 .byte $0A    ;    X X
 .byte $8E    ;X   XXX
 .byte $E0    ;XXX
 .byte $A4    ;X X  X
 .byte $A4    ;X X  X
 .byte $04    ;     X
 .byte $80    ;X
 .byte $08    ;    X
 .byte $0E    ;    XXX
 .byte $0A    ;    X X
 .byte $0A    ;    X X
 .byte $80    ;X
 .byte $0E    ;    XXX
 .byte $0A    ;    X X
 .byte $0E    ;    XXX
 .byte $08    ;    X
 .byte $0E    ;    XXX
 .byte $80    ;X
 .byte $04    ;     X
 .byte $0E    ;    XXX
 .byte $04    ;     X
 .byte $04    ;     X
 .byte $04    ;     X
 .byte $80    ;X
 .byte $04    ;     X
 .byte $0E    ;    XXX
 .byte $04    ;     X
 .byte $04    ;     X
 .byte $04    ;     X
 .byte $00

Those rows would have been empty, but having a $00 there would have prevented there rest from being drawn. Interesting!

Draw something

For today’s installment, I’ll be using Color BASIC on a CoCo emulator to write a simple program to plot these objects on the screen. I copied all of the assembly definitions into an editor then did a search and replace to turn those .byte instructions into incredibly inefficient one-number-per-line DATA statements like this:

2830 ' Object #10 : State FF : Graphic  
2840 ' GfxChallise:
2850 DATA &H81 ' X      X   
2860 DATA &H81 ' X      X   
2870 DATA &HC3 ' XX    XX   
2880 DATA &H7E '  XXXXXX    
2890 DATA &H7E '  XXXXXX   
2900 DATA &H3C '   XXXX     
2910 DATA &H18 '    XX      
2920 DATA &H18 '    XX      
2930 DATA &H7E '  XXXXXX    
2940 DATA &H00

Unfortunately, READ/DATA in Color BASIC does not allow that. It will READ the first value, then give an ?SN ERROR when it tries to read the next because the parser doesn’t handle the apostrophe “REM” marker!

So I changed it to this:

2830 ' Object #10 : State FF : Graphic  
2840 ' GfxChallise:
2850 DATA &H81:REM X      X   
2860 DATA &H81:REM X      X   
2870 DATA &HC3:REM XX    XX   
2880 DATA &H7E:REM  XXXXXX    
2890 DATA &H7E:REM  XXXXXX   
2900 DATA &H3C:REM   XXXX     
2910 DATA &H18:REM    XX      
2920 DATA &H18:REM    XX      
2930 DATA &H7E:REM  XXXXXX    
2940 DATA &H00

This also fails — and is a problem I only recently discovered when writing my Base-64 articles.

I guess I can’t have this code be as bulky and inefficient as I wanted. I removed them so it was just the DATA statements:

2830 ' Object #10 : State FF : Graphic  
2840 ' GfxChallise:
2850 DATA &H81
2860 DATA &H81
2870 DATA &HC3
2880 DATA &H7E
2890 DATA &H7E
2900 DATA &H3C
2910 DATA &H18
2920 DATA &H18
2930 DATA &H7E
2940 DATA &H00

Oh well. Who needs comments anyway — especially in BASIC where they just bloat the code and slow it down.

A quick-and-dirty routine allowed me to see it was working:

Atari Adventure graphics rendered on a CoCo :)

…but there was no way I was going to be able to fit the “Created by Warren Robinett” graphic on a low-res 64×32 screen. To solve this, I hacked together a version that used a “high resolution” screen:

Atari Adventure graphics rendered in “high resolution” on a CoCo :)

It looks like the data is pretty straight forward. The dragons would have to be drawn reversed to make them face right, and the bridge looks like it needs an X scaling factor added to make it as wide as it is in the game. But, not bad for a first attempt.

Just for fun, here is the brute-force hacky nasty Color BASIC code I quickly put together to do this:

10 REM AdvObjs.bas
20 POKE 65395,0
30 FOR A=0 TO 7:BT(A)=2^A:NEXT
40 CLS0:XS=1:YS=1:Y=1
50 PMODE 1,1:PCLS:SCREEN 1,0
60 READ V:IF V=-1 THEN 120 ELSE IF V=0 THEN 90
70 X=XS:FOR A=7 TO 0 STEP-1:IF V AND BT(A) THEN PSET(X*2,Y*2,C)
80 X=X+1:NEXT:Y=Y+1:GOTO 60
90 XS=XS+9:IF XS>120 THEN XS=1:YS=YS+32
100 C=C+1:IF C=1 THEN C=2 ELSE IF C>3 THEN C=0
110 Y=YS:GOTO 60
120 GOTO 120
130 ' Object #0A : State FF : Graphic  
140 ' GfxBridge:
150 DATA &HC3
160 DATA &HC3
170 DATA &HC3
180 DATA &HC3
190 DATA &H42
200 DATA &H42
210 DATA &H42
220 DATA &H42
230 DATA &H42
240 DATA &H42
250 DATA &H42
260 DATA &H42
270 DATA &H42
280 DATA &H42
290 DATA &H42
300 DATA &H42
310 DATA &H42
320 DATA &H42
330 DATA &H42
340 DATA &H42
350 DATA &HC3
360 DATA &HC3
370 DATA &HC3
380 DATA &HC3
390 DATA &H00
400 ' Object #5 State #1 Graphic :'1'  
410 ' GfxNum1:
420 DATA &H04
430 DATA &H0C
440 DATA &H04
450 DATA &H04
460 DATA &H04
470 DATA &H04
480 DATA &H0E
490 DATA &H00
500 ' Object #0B : State FF : Graphic  
510 ' GfxKey:
520 DATA &H07
530 DATA &HFD
540 DATA &HA7
550 DATA &H00
560 ' Object #5 State #2 Grphic :
570 ' GfxNum2:
580 DATA &H0E
590 DATA &H11
600 DATA &H01
610 DATA &H02
620 DATA &H04
630 DATA &H08
640 DATA &H1F
650 DATA &H00
660 ' Object #5 State #3 Graphic :'3'  
670 ' GfxNum3:
680 DATA &H0E
690 DATA &H11
700 DATA &H01
710 DATA &H06
720 DATA &H01
730 DATA &H11
740 DATA &H0E
750 DATA &H00
760 ' Object #0E : State 03 : Graphic  
770 ' GfxBat1:
780 DATA &H81
790 DATA &H81
800 DATA &HC3
810 DATA &HC3
820 DATA &HFF
830 DATA &H5A
840 DATA &H66
850 DATA &H00
860 ' Object #0E : State FF : Graphic  
870 ' GfxBat2:
880 DATA &H01
890 DATA &H80
900 DATA &H01
910 DATA &H80
920 DATA &H3C
930 DATA &H5A
940 DATA &H66
950 DATA &HC3
960 DATA &H81
970 DATA &H81
980 DATA &H81
990 DATA &H00
1000 ' Object #6 : State #00 : Graphic  
1010 ' GfxDrag0:
1020 DATA &H06
1030 DATA &H0F
1040 DATA &HF3
1050 DATA &HFE
1060 DATA &H0E
1070 DATA &H04
1080 DATA &H04
1090 DATA &H1E
1100 DATA &H3F
1110 DATA &H7F
1120 DATA &HE3
1130 DATA &HC3
1140 DATA &HC3
1150 DATA &HC7
1160 DATA &HFF
1170 DATA &H3C
1180 DATA &H08
1190 DATA &H8F
1200 DATA &HE1
1210 DATA &H3F
1220 DATA &H00
1230 ' Object 6 : State FF : Graphic    
1240 ' GfxDrag1:
1250 DATA &H80
1260 DATA &H40
1270 DATA &H26
1280 DATA &H1F
1290 DATA &H0B
1300 DATA &H0E
1310 DATA &H1E
1320 DATA &H24
1330 DATA &H44
1340 DATA &H8E
1350 DATA &H1E
1360 DATA &H3F
1370 DATA &H7F
1380 DATA &H7F
1390 DATA &H7F
1400 DATA &H7F
1410 DATA &H3E
1420 DATA &H1C
1430 DATA &H08
1440 DATA &HF8
1450 DATA &H80
1460 DATA &HE0
1470 DATA &H00
1480 ' Object 6 : State 02 : Graphic    
1490 ' GfxDrag2:
1500 DATA &H0C
1510 DATA &H0C
1520 DATA &H0C
1530 DATA &H0E
1540 DATA &H1B
1550 DATA &H7F
1560 DATA &HCE
1570 DATA &H80
1580 DATA &HFC
1590 DATA &HFE
1600 DATA &HFE
1610 DATA &H7E
1620 DATA &H78
1630 DATA &H20
1640 DATA &H6E
1650 DATA &H42
1660 DATA &H7E
1670 DATA &H00
1680 ' Object #9 : State FF : Graphics  
1690 ' GfxSword:
1700 DATA &H20
1710 DATA &H40
1720 DATA &HFF
1730 DATA &H40
1740 DATA &H20
1750 DATA &H00
1760 ' Object #0F : State FF : Graphic  
1770 ' GfxDot:
1780 DATA &H80
1790 DATA &H00
1800 ' Object #4 : State FF : Graphic   
1810 ' GfxAuthor:
1820 DATA &HF0
1830 DATA &H80
1840 DATA &H80
1850 DATA &H80
1860 DATA &HF4
1870 DATA &H04
1880 DATA &H87
1890 DATA &HE5
1900 DATA &H87
1910 DATA &H80
1920 DATA &H05
1930 DATA &HE5
1940 DATA &HA7
1950 DATA &HE1
1960 DATA &H87
1970 DATA &HE0
1980 DATA &H01
1990 DATA &HE0
2000 DATA &HA0
2010 DATA &HF0
2020 DATA &H01
2030 DATA &H40
2040 DATA &HE0
2050 DATA &H40
2060 DATA &H40
2070 DATA &H40
2080 DATA &H01
2090 DATA &HE0
2100 DATA &HA0
2110 DATA &HE0
2120 DATA &H80
2130 DATA &HE0
2140 DATA &H01
2150 DATA &H20
2160 DATA &H20
2170 DATA &HE0
2180 DATA &HA0
2190 DATA &HE0
2200 DATA &H01
2210 DATA &H01
2220 DATA &H01
2230 DATA &H88
2240 DATA &HA8
2250 DATA &HA8
2260 DATA &HA8
2270 DATA &HF8
2280 DATA &H01
2290 DATA &HE0
2300 DATA &HA0
2310 DATA &HF0
2320 DATA &H01
2330 DATA &H80
2340 DATA &HE0
2350 DATA &H8F
2360 DATA &H89
2370 DATA &H0F
2380 DATA &H8A
2390 DATA &HE9
2400 DATA &H80
2410 DATA &H8E
2420 DATA &H0A
2430 DATA &HEE
2440 DATA &HA0
2450 DATA &HE8
2460 DATA &H88
2470 DATA &HEE
2480 DATA &H0A
2490 DATA &H8E
2500 DATA &HE0
2510 DATA &HA4
2520 DATA &HA4
2530 DATA &H04
2540 DATA &H80
2550 DATA &H08
2560 DATA &H0E
2570 DATA &H0A
2580 DATA &H0A
2590 DATA &H80
2600 DATA &H0E
2610 DATA &H0A
2620 DATA &H0E
2630 DATA &H08
2640 DATA &H0E
2650 DATA &H80
2660 DATA &H04
2670 DATA &H0E
2680 DATA &H04
2690 DATA &H04
2700 DATA &H04
2710 DATA &H80
2720 DATA &H04
2730 DATA &H0E
2740 DATA &H04
2750 DATA &H04
2760 DATA &H04
2770 DATA &H00
2780 ' Object #10 : State FF : Graphic  
2790 ' GfxChallise:
2800 DATA &H81
2810 DATA &H81
2820 DATA &HC3
2830 DATA &H7E
2840 DATA &H7E
2850 DATA &H3C
2860 DATA &H18
2870 DATA &H18
2880 DATA &H7E
2890 DATA &H00
2900 ' Object #11 : State FF : Graphic  
2910 ' GfxMagnet:
2920 DATA &H3C
2930 DATA &H7E
2940 DATA &HE7
2950 DATA &HC3
2960 DATA &HC3
2970 DATA &HC3
2980 DATA &HC3
2990 DATA &HC3
3000 DATA &H00
3010 ' Object #1 States 940FF (Graphic)
3020 ' GfxPort01:
3030 DATA &HFE
3040 DATA &HAA
3050 'GfxPort02:
3060 DATA &HFE
3070 DATA &HAA
3080 'GfxPort03:
3090 DATA &HFE
3100 DATA &HAA
3110 'GfxPort04:
3120 DATA &HFE
3130 DATA &HAA
3140 'GfxPort05:
3150 DATA &HFE
3160 DATA &HAA
3170 'GfxPort06:
3180 DATA &HFE
3190 DATA &HAA
3200 'GfxPort07:
3210 DATA &HFE
3220 DATA &HAA
3230 'GfxPort08:
3240 DATA &HFE
3250 DATA &HAA
3260 'GfxPort09:
3270 DATA &H00
3280 DATA -1

It ain’t pretty, but it’s mine!

I suppose next I should get back to looking at how the rooms are connected. And there’s some interesting stuff in here, including rooms that “change” as the game is played.

Stay tuned…

Benchmarking the CoCo keyboard – part 6

6 Replies

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

Let’s jump right in with a mystery… This code:

0 REM arrowbench.bas
10 TIMER=0:FOR A=1 TO 1000
20 POKE&H155,&HFF:POKE&H156,&HFF:POKE&H157,&HFF:POKE&H158,&HFF
30 IF PEEK(&H155)=&HF7 THEN IF Y>. THEN Y=Y-1
40 IF PEEK(&H156)=&HF7 THEN IF Y<&HDF THEN Y=Y+1
50 IF PEEK(&H157)=&HF7 THEN IF X>. THEN X=X-1
60 IF PEEK(&H158)=&HF7 THEN IF X<&HFE THEN X=X+1
90 NEXT:PRINT TIMER

…reports 2139.

This code, using variables instead of five constants…

0 REM arrowbench2.bas
5 V=&HF7:U=&H155:D=&H156:L=&H157:R=&H158
10 TIMER=0:FOR A=1 TO 1000
20 POKEU,V:POKED,V:POKEL,V:POKER,V
30 IF PEEK(U)=V THEN IF Y>.THEN Y=Y-1
40 IF PEEK(D)=V THEN IF Y<&HDF THEN Y=Y+1
50 IF PEEK(L)=V THEN IF X>.THEN X=X-1
60 IF PEEK(R)=V THEN IF X<&HFE THEN X=X+1
90 NEXT:PRINT TIMER

…reports 2890 – slower.

My previous BASIC benchmarks have shown that looking up variables should be faster than parsing HEX values, at least when there are a small amount of variables to parse through.

But in this case, it is slower.

And this code, which just adds some GOTOs to skip additional checking when a key is matched (it will not support diagonals):

0 REM arrowbench8.bas
10 TIMER=0:FOR A=1 TO 1000
20 POKE&H155,&HFF:POKE&H156,&HFF:POKE&H157,&HFF:POKE&H158,&HFF
30 IF PEEK(&H155)=&HF7 THEN IF Y>.THEN Y=Y-1:GOTO90
40 IF PEEK(&H156)=&HF7 THEN IF Y<&HDF THEN Y=Y+1:GOTO90
50 IF PEEK(&H157)=&HF7 THEN IF X>.THEN X=X-1:GOTO90
60 IF PEEK(&H158)=&HF7 THEN IF X<&HFE THEN X=X+1
90 NEXT:PRINT TIMER

…prints 2186 (a bit slower than the first, since it always has to skip the extra characters at the end of each line).

Yet this:

0 REM arrowbench9.bas
5 V=&HF7:U=&H155:D=&H156:L=&H157:R=&H158
10 TIMER=0:FOR A=1 TO 1000
20 POKEU,V:POKED,V:POKEL,V:POKER,V
30 IF PEEK(U)=V THEN IF Y>.THEN Y=Y-1:GOTO90
40 IF PEEK(D)=V THEN IF Y<&HDF THEN Y=Y+1:GOTO90
50 IF PEEK(L)=V THEN IF X>.THEN X=X-1:GOTO90
60 IF PEEK(R)=V THEN IF X<&HFE THEN X=X+1:GOTO90
90 NEXT:PRINT TIMER

…reports 1431 – faster.

A quick test using the TRON command shows that the second version using variables does not always run lines 50 and 60. It is sometimes getting a value back that triggers that extra code, hitting the GOTO and skipping the other lines.

But why does this happen when using variables, but not when using hard-coded constant values? This test program seems to show they display the same values:

5 V=&HF7:U=&H155:D=&H156:L=&H157:R=&H158
10 POKE&H155,&HFF:POKE&H156,&HFF:POKE&H157,&HFF:POKE&H158,&HFF
20 PRINT HEX$(PEEK(U))" "HEX$(PEEK(D))" "HEX$(PEEK(L))" "HEX$(PEEK(R)),HEX$(PEEK(&H155))" "HEX$(PEEK(&H156))" "HEX$(PEEK(&H157))" "HEX$(PEEK(&H158))
30 GOTO 10

What am I not seeing? Where is my typo?

Please help.

UPDATE: I found my typo. And it’s a stupid one. Do you see what I did wrong?

To be continued…

CoCo MC6847 VDG chip “draw black” challenge responses.

7 Replies

Recently, I was annoyed to find that there did not seem to be any way to set a black pixel on the CoCo’s normal green background. I have since been schooled in the simplest way to make this work, which I will share after a long digressing ramble.

Never the Same Color Twice

The CoCo’s MC6847 VDG chip provides nine colors. Commenter Jason wrote:

“It always bothered me that the CoCo had nine colors in semi-graphics modes. The number nine should raise a red flag for anyone who is familiar with computers and the tendencies for things to be powers of two.“
…
“It’s interesting that seven of the eight colors are from the NTSC test pattern (https://en.wikipedia.org/wiki/SMPTE_color_bars) which leads me to believe they’re all a particular frequency distance from each other. This would make the circuitry simpler.”
– Jason

I suppose it’s actually eight foregrounds colors with a black background, which matches the black border of the screen. There was even a test pattern program included in one of Radio Shack’s quick reference guide that I still have:

Color Adjustment Test Display

5 FOR X = 0 TO 63
10 FOR Y = 0 TO 31
15 C = INT(X/8+1)
20 SET(X,Y,C)
25 NEXT Y,X
30 GOTO 30

That produces the following output, showing the eight possible colors (plus the black background):

Color Adjustment Test Display, Radio Shack TRS-80 Color Computer Quick Reference Guide, page 55.

And here is the NTSC test pattern Jason referenced:

By Denelson83 – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1067498

This made me want to alter the program to make it render something with the matching colors in the correct order (and with the Xroar emulator set to not emulate a crappy 1980s RF modulated TV signal):

The 7 NTSC color bar colors that the CoCo produces.

The extra color that is not shown is orange. I wonder why those eight colors (plus black) were chosen? And what makes the colors used by the two PMODE high res graphics screens? I’ll have to revisit that in the future.

But I digress…

You can’t, even if you SET your mind to it

My original article was written because I noticed you couldn’t SET a black pixel on a normal CoCo text screen. Even though the manual listed nine colors, with zero being black, attempting to do SET(X,Y,0) would result in that pixel being set to the green background color instead of black — the same as SET(X,Y,1). While other colors acted as you expected…

SET seemed to be treating color 0 (black) as 1 (green). Because reasons.

In order to SET a black pixel on the normal text screen, extra code would be needed.

Ciaran Anscomb

Xroar emulator author Ciaran Anscomb was the first to respond with his GOSUB routine to achieve the desired effects:

I mean I think you’re making it harder by asking for it to work with
plain CLS and not CLS1, but in that case:
100 IFPEEK(1024+INT(Y/2)*32+INT(X/2))<128THENPOKE1024+INT(Y/2)*32+INT(X/2),143
110 RESET(X,Y):RETURN
– Ciaran Anscomb

His method would PEEK the character value at the 2×2 block that was being SET and, if that value was less than 128, it would change it to 143 and then use RESET… And it works:

10 CLS
20 FOR A=0 TO 31
30 X=A:Y=A:GOSUB 100
40 NEXT
50 GOTO 50
99 ' Ciaran Anscomb
100 IFPEEK(1024+INT(Y/2)*32+INT(X/2))<128THENPOKE1024+INT(Y/2)*32+INT(X/2),143
110 RESET(X,Y):RETURN

Jim Gerrie

BASIC programmer extroidinaire Jim Gerrie provided his take on this routine:

100 SET(X,Y,1):SET(X-(X/2-INT(X/2)=.),Y,1):SET(X-(X/2-INT(X/2)=.),Y-(Y/2-INT(Y/2)=.),1):SET(X,Y-(Y/2-INT(Y/2)=.),1)
101 RESET(X,Y):RETURN
– Jim Gerrie

His version sets some pixels to color 1, and some to color 0 (using the “.” shortcut), based on some math with X and Y and divisions and integer conversions and … well, stuff I don’t grasp.

His also works! But as it draws, you can see it blipping surrounding pixels in the 2×2 block on then off. And while it passes the test case which drew a diagonal line, it doesn’t allow for setting arbitrary pixels near each other. They turn into full blocks.

However, he also added a second attempt:

I know that my first suggestion above is a bit of a cheat. Here’s a more robust suggestion:
10 CLS
20 FOR A=0 TO 31
30 X=A:Y=A:GOSUB 100
40 NEXT
50 GOTO 50
100 IFPOINT(X,Y)<.THENXX=(X/2-INT(X/2)=.)-(X/2-INT(X/2)>.):YY=(Y/2-INT(Y/2)=.)-(Y/2-INT(Y/2)>.):SET(X,Y,1):SET(X-XX,Y,1):SET(X-XX,Y-YY,1):SET(X,Y-YY,1)
101 RESET(X,Y):RETURN
– Jim Gerrie

This version passes the test as well, and looks like it better handles setting pixels at any position without impacting pixels around it.

What’s the POINT?

Ciaran made use of PEEK to detect what was on the screen before adding something new, and Jim figured out what pixels to set back to the background color. Neither did it the way I was expecting — using POINT:

POINT (X,Y) Tests whether specified graphics cell is on or off, x (horizontal) = 0-63; y (vertical) = 0-31. The value returned is -1 if the cell is in a text character mode; 0 if it is off, or the color code If it is on, See CLS for color codes.

IF POINT(10,10) THEN PRINT "ON" ELSE PRINT "OFF"

I expected I’d see folks use this to see if a pixel was set, and handle accordingly. Somehow. But as I read this description (from the Quick Reference Guide), I see that note that says “The value returned is -1 if the cell is in a text character mode.”

Text character mode? It’s just the background, isn’t it?

All green backgrounds are not the same

And that takes me back to Ciaran’s code:

IF PEEK(1024+INT(Y/2)*32+INT(X/2))<128 . . .

Less than 128 is a text character. The graphics blocks (2×2) start as 128. If the square is a text character then set it to 143. So what is that? That is a 2×2 graphics block that has all pixels set to the green color. And that green color is the same color as the background screen. Which isn’t 143 when you use CLS. Try this:

CLS:PRINT PEEK(1024)

If you clear the screen then PEEK to see what value is at the top left character (1024), it returns 96. 96 is the space character (yeah, ASCII is 32, but values in screen memory aren’t ASCII).

Ciaran’s code sees if it’s anything (including that green space), set it to 143, which is a green block that looks the same. Try this:

CLS 1:PRINT PEEK(1024)

That will print 143. Yet, visually, CLS and CLS 1 look the same. But, CLS is filling the screen with the space text character (96) and CLS 1 fills it with the green graphics character (143)! CLS 0-8 fill the screen with solid graphics characters, and CLS with no parameter is the space.

Now, I knew about character 143 looking like the normal space but not being one, because we used to use this as a cheap “copy protection” method. On DISK, you could save out a file like this:

SAVE "HELLO.BAS"

…and you’d get a file on BASIC called HELLO.BAS. But, if you did this:

SAVE "HELLO"+CHR$(143)+".BAS"

…Disk BASIC would write out a file called HELLO(char 143).BAS. When you did a DIR they would look the same, but you couldn’t do a LOAD”HELLO.BAS” to get the one with the CHR$(143) in it. Unless you exempted the disk directory bytes you would not know there was an “invisible” character at the end of the “HELLO” filename.

Sneaky. And I did this with some of my own programs.

But years later, when the CoCo 3 came out, it’s 40 and 80 column screen did NOT support the 2×2 graphics block characters, and this trick was no longer as sneaky since you would see “HELLO(some funky character).BAS” in the directory listing and know something weird had been done.

But I digress, again…

Why do it the hard way, anyway?

It turns out, even though I knew about the “add CHR$(143)” trick, I had forgotten (or never knew/realized) that CLS and CLS 1 filled the screen with different characters. And, if the screen has a graphics character at the position, RESET will then work to change that pixel back to black.

Ciaran got me exploring this because in his e-mail he added:

If you allow CLS1, the problem solves itself :)
– Ciaran Anscomb

I had to follow up and ask what he meant by this. And, well, nevermrind, then. All I needed to do was start the program with CLS 1 instead of CLS 0, and then I could use RESET() to set individual black pixels on the screen.

I could have a subroutine that expect X, Y and C (for color) and if the color was 0 (black), do a RESET, else do a SET:

0 REM RESET
10 CLS 1
20 FOR A=0 TO 31
30 X=A:Y=A:C=0:GOSUB 100
40 NEXT
50 GOTO 50
100 IF C=0 THEN RESET(X,Y) ELSE SET(X,Y,C)
110 RETURN

And that works fine on any CLS 0-8 screen. Remember, SET(X,Y,0) never gives you a black pixel. 0 seems to mean “background color” instead, while RESET(X,Y) seems to mean “set to black”.

To me, this is a bit counterintuitive, since today I would expect “reset” to mean “set to background color” but this isn’t a graphics mode — it’s just graphics characters on a screen, so the only way BASIC could have done this is if it remembered what the CLS # value was, and made RESET set to that color. Which would be extra ROM space for a simple enhancement that most could work around with RESET instead.

And that, my friends, is how a rabbit hole works.

Until next time…

Benchmarking the CoCo keyboard – part 5

1 Reply

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:

20 CLS:FORZ=.TO1STEP.IF(PEEK(344)ANDPEEK(343)ANDPEEK(342)ANDPEEK(341))<>255THENK=PEEK(135):PRINT@32*Y+X,” “;:X=X+(X>.ANDK=8)-(X<31ANDK=9):Y=Y+(Y>.ANDK=94)-(Y<14ANDK=10):NEXT ELSENEXT:END
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:

1 PCLEAR4:SCREEN1,1:PCLS
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)
8 PSET(X,Y):GOTO7

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
10 PCLEAR4:SCREEN1,1:PCLS:X=0:Y=0
20 POKE&H155,&HFF:POKE&H156,&HFF:POKE&H157,&HFF:POKE&H158,&HFF
30 IF PEEK(&H155)=&HF7 THEN IF Y>. THEN Y=Y-1
40 IF PEEK(&H156)=&HF7 THEN IF Y<&HDF THEN Y=Y+1
50 IF PEEK(&H157)=&HF7 THEN IF X>. THEN X=X-1
60 IF PEEK(&H158)=&HF7 THEN IF X<&HFE THEN X=X+1
80 IF PEEK(&H159)=&HF7 THEN PRESET(X,Y) ELSE PSET(X,Y)
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
20 POKE&H155,&HFF:POKE&H156,&HFF:POKE&H157,&HFF:POKE&H158,&HFF
30 IFPEEK(&H155)=&HF7 THENIFY>.THENY=Y-1
40 IFPEEK(&H156)=&HF7 THENIFY<&HDF THENY=Y+1
50 IFPEEK(&H157)=&HF7 THENIFX>.THENX=X-1
60 IFPEEK(&H158)=&HF7 THENIFX<&HFE THENX=X+1
90 NEXT:PRINT TIMER

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
20 POKEU,V:POKED,V:POKEL,V:POKER,V
30 IFPEEK(U)=V THENIFY>.THENY=Y-1
40 IFPEEK(D)=V THENIFY<&HDF THENY=Y+1
50 IFPEEK(L)=V THENIFX>.THENX=X-1
60 IFPEEK(R)=V THENIFX<&HFE THENX=X+1
90 NEXT:PRINT TIMER

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)
90 NEXT:PRINT TIMER

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
20 POKE&H155,&HFF:POKE&H156,&HFF:POKE&H157,&HFF:POKE&H158,&HFF:IFNOT((PEEK(&H155)ANDPEEK(&H156)ANDPEEK(&H157)ANDPEEK(&H158))=&HFF)THENK=PEEK(&H87):X=X+(K=&H8 ANDX>.)-(K=&H9 ANDX<&HFF):Y=Y+(K=&H5E ANDY>.)-(K=&HA ANDY<&HBF)
90 NEXT:PRINT TIMER

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
20 POKEU,V:POKED,V:POKEL,V:POKER,V:IFNOT((PEEK(U)ANDPEEK(D)ANDPEEK(L)ANDPEEK(R))=V)THENK=PEEK(P):X=X+(K=&H8 ANDX>.)-(K=&H9 ANDX<&HFF):Y=Y+(K=&H5E ANDY>.)-(K=&HA ANDY<&HBF)
90 NEXT:PRINT TIMER

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
20 POKE&H155,&HFF:POKE&H156,&HFF:POKE&H157,&HFF:POKE&H158,&HFF:IFNOT((PEEK(U)ANDPEEK(D)ANDPEEK(L)ANDPEEK(R))=V)THENK=PEEK(P):X=X+(K=&H8 ANDX>.)-(K=&H9 ANDX<&HFF):Y=Y+(K=&H5E ANDY>.)-(K=&HA ANDY<&HBF)
90 NEXT:PRINT TIMER

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…

CoCo MC6847 VDG chip “draw black” challenge

14 Replies

The 1980 Radio Shack Color Computer (and the Color Computer 2 revisions) used a Motorola MC6847 Video Display Generator chip. This video chip was used in a variety of other systems, and one can easily recognize it by its 32×16 text mode characters with the square letter “O”. I recently spotted it in a YouTube video by Atari Archives discussing the Atari VCS Hangman cartridge (see 5:04 if this direct link doesn’t work):

I was unfamiliar with the AFP Imagination Machine mentioned in the video, but CoCo Crew co-host John Linville confirmed it indeed used the same CoCo VDG chip. The “nuclear green” background color and blocky low-resolution “semigraphics” do stand out.

I also stumbled upon it in a list of unreleased Atari products. A company named Unitronics was planning an Atari VCS Expander System that would allow loading games from a built-in tape deck. In a screen shot for the device (which looked like a cassette player that plugged into the top of the Atari), the nuclear green CoCo screen can be clearly seen:

http://www.ataricompendium.com/game_library/unreleased/unreleased.html#unitronics

The screenshot in the first picture appears similar to that of Radio Shacks’ Color Computer – same color scheme and maximum of 32 characters per line.
http://www.ataricompendium.com/game_library/unreleased/unreleased.html

And, there was even going to be a conversion of the 1980 CoCo ROM-Pak Space Assault and a screen shot was used of the CoCo version

http://www.ataricompendium.com/game_library/unreleased/unreleased.html#spaceassault

The screenshot shown in a brochure for the Expander System (picture #1) is actually the Radio Shack Color Computer game Space Assault (picture #2). The game was licensed to Tandy by Image Producers Inc. in 1981. Perhaps Unitronics was going to license the game for the Expander. If the game shown in the brochure is actually running on the Expander, that would mean the Expander used the same graphics chip as the CoCo – the MC6847 VDG chip.
http://www.ataricompendium.com/game_library/unreleased/unreleased.html

Until recently, I had no idea anything but the Radio Shack CoCo and MC-10s, as well as the UK’s Dragon computers (and, I guess, the French MC-10 clone, Alice) used the VDG chip.

64x32x8 … technically.

Ignoring using solid color character blocks in the 32×16 text mode, the lowest resolution graphics mode in the VDG was a 64×32 mode that could use 8 colors plus black. It did this by dividing each text block of the 32×16 text screen into a 2×2 graphics character. They weren’t true pixels, but instead where just characters made with all possible 2×2 variations in eight different colors. You could PRINT them using CHR$:

This reminds me of how the Commodore VIC-20 worked with its extended PETSCII character set, but instead of all the weird lines and shapes and card suit symbols, it was 2×2 graphics blocks with different colors. Much like the standard VIC-20 text mode, each text position could only contain one color plus black. Thus, while you could have eight colors on the screen, you could never have more than one color (plus black) in a character’s 2×2 block.

Rendering graphics in this mode was tricky, since you could not have more than a single color (plus black) in any 2×2 block.

In BASIC, you could set the top left pixel to yellow using:

SET(0,0,2)

…but you would see it would change all the other pixels in the 2×2 block to black:

And if you tried to set two pixels side-by-side to different colors:

SET(0,0,2):SET(1,0,5)

…it would turn any other set pixel in that 2×2 block to the new color:

CoCo SET command. All pixels in a 2×2 block must be the same color. So there.

I am sure I learned this limitation when I first started playing with a CoCo in Radio Shack back in 1982.

Because of this “all pixels must be the same color” effect of the SET command, doing a random pixel plotting program…

0 REM 64x32.bas
10 POKE 65495,0:CLS 0
20 SET(RND(64)-1,RND(32)-1,RND(8)-1)
30 GOTO 20

…starts out as you might expect…

…but after awhile, every pixel has been set so new sets will change everything in that 2×2 block to the same color:

I know I wrote this program at that Radio Shack ;-)

Black is not a color

The early “Getting Started With Color BASIC” manual that came with the CoCo described the SET() command as being able to use the following colors:

0 – black
1 – green
2 – yellow
3 – blue
4 – red
5 – buff
6 – cyan
7 – magenta
8 – orange

But that manual was a bit incorrect. While you can try to SET(x,y,0), you won’t get black. The SET() command treats 0 and 1 as the same green color.

In fact, from what I can see, there is no way to set just a black pixel on the green text screen other than setting all the other pixels in that 2×2 block to the background screen green (color 1).

0 REM setblack.bas
10 CLS
20 SET(1,0,1):SET(0,1,1):SET(1,1,1)
30 GOTO 30

I guess the SET() command was really designed to work on a black screen (CLS 0). In fact, when viewing the Color BASIC disassembly in the “Color BASIC Unravelled” book, I even see it checks for this specifically:

CHANGE COLOR NUMBERS FROM 0-8 TO (-1 TO 7)
BRANCH IF SET(X,Y,0)

It looks like they could have allowed it to support this, based on how the code checks what’s in the character initially. Maybe it was an oversight, or maybe it was just a lack of ROM space.

Regardless of the reason … I recently wanted to draw a black pixel on the green screen, and found doing so quite challenging.

The “draw black” challenge

Given a clear txt screen (CLS without any color), create a BASIC subroutine starting at line 100 that will plot a single black pixel using variable X and Y. Basically, make it act as if SET(X,Y,0) would actually set a black pixel like the BASIC manual implied.

It will be called like this:

10 CLS
20 FOR A=0 TO 31
30 X=A:Y=A:GOSUB 100
40 NEXT
50 GOTO 50

That above code would draw a diagonal black line from the top left of the screen down to the middle bottom of the screen.

To erase a pixel, we’d just use SET(X,Y,1) to place a green pixel there.

Is there a clever way to do this? Leave your efforts in the comments, or send them to me via e-mail.

Have fun!

Benchmarking the CoCo keyboard – part 4

4 Replies

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

NOTE: I have a really great comment to share with you from a recent installment, but it deserves an article of it’s very own. Thank you, Jim, for the assembly sample. I’ll be getting to that soon…

Meanwhile, William Astle once again comments with some explanations to move this topic forward:

The KEYBUF thing is actually a lot more straight forward than it looks. It basically holds the result of reading FF00 for each keyboard column as of the last time KEYIN ran. More specifically, the last time it got to actually reading that column since it stops as soon as it finds a new key press and, so, it won’t necessarily update all eight entries in KEYBUF every time. It will when no new keys are pressed, though.
Basically, what it does is this:
Read the data from FF00
EOR it with the relevant byte in KEYBUF; this sets any bit where the value has changed since the last read; that is, a key was pressed or released. Exclusive OR yields a 1 if its two inputs are different and a 0 if the two inputs are the same.
AND the result of (2) with the KEYBUF value. This will keep only bits where the previous result was a “1” (not pressed). That ignores any keys that were released or are held down (previous state being a “0” in both of those cases).
Store the value read from FF00 into the KEYBUF byte using a copy of the original read from FF00.
If The result of (3) is nonzero, it stops reading the PIA and decodes the new keypress, does the debounce thing, etc.
KEYIN also masks off the joystick comparator input so you won’t see that in KEYBUF. Further, when reading the column with SHIFT in it, it masks that as well. So you can’t test for shift by looking in KEYBUF.
Basically, what the POKEs do is trick KEYIN into thinking that no keys in those particular columns were previously pressed by setting the bits to “1”.
As a side note, you can detect keys that are currently pressed by PEEKing KEYBUF. As long as Basic is doing its BREAK check, KEYIN is getting called at least once before every statement so KEYBUF gets updated.
William Astle

I’m glad there’s someone around here who understands this stuff. But it was his last paragraph that caught my attention. If we can just PEEK those values, INKEY$ isn’t even necessary (offering a slight speedup, perhaps).

Let’s look at what’s inside those eight KEYBUF locations. To make them fit on a 32 column screen, I will print them out as HEX values:

0 REM keyboard.bas
10 FOR A=338 TO 345:POKE A,&HFF
20 PRINT HEX$(PEEK(A))" ";
30 NEXT:PRINT:GOTO 10

Run this and you will see eight columns of hex values that represent the KEYBUF status of most of the keys. And by POKEing each value to 255 (&HFF for speed) before they are read, it allows detecting the key as long as it is being held down. You can now see the status of the arrow keys, including if you pressed two at the same time (Up+Left).

Let’s display this in bits so we can visualize which bits we care about:

0 REM keyboard2.bas
5 POKE 65495,0:CLS:FOR BT=0 TO 7:BT(BT)=INT(2^BT):NEXT
10 PRINT@0,;:FOR A=338 TO 345:POKE A,&HFF:PRINT A;:V=PEEK(A)
20 FOR BT=7 TO 0 STEP-1:IF V AND BT(BT) THEN PRINT "1"; ELSE PRINT "0";
30 NEXT:PRINT:NEXT:GOTO 10

Running this will display eight lines representing the bits in each of those memory locations. Here is what it looks like when all four arrow keys are held down at the same time:

CoCo Keyboard Matrix with all four arrow keys held down.

I see that SPACE is also in its own column, likely by design for this very purpose – games. One would want to be able to detect ARROWS and SPACE independently which would not be possible if any of them used the same column.

With this in mind, we can try to just read those keys (Up, Down, Left, Right and Space) as fast as possible.

Read those keys as fast as possible

To be nice and flexible, we should take the PEEK of one of those values and AND off the bit(s) we care about and act upon that. This allows detecting just the key we want even if something else in that column is also being held down. Since we are going for speed, we’ll just say the user isn’t allowed to do that. Press Up and that’s okay. Press Up and S (another key in the same column) and the player won’t move. Maybe we can improve that later.

Using the first keyboard.bas listing as reference, it looks like it will be easy to detect these five keys by checking the PEEK value against &HF7. As long as only the Up, Down, Left, Right or Space is held down in that column, the value will be &HF7. This gives us something like this:

0 REM arrows.bas
10 CLS:L=16+32*8
20 POKE&H155,&HFF:POKE&H156,&HFF:POKE&H157,&HFF:POKE&H158,&HFF:D=.
30 IF PEEK(&H155)=&HF7 THEN D=-&H20
40 IF PEEK(&H156)=&HF7 THEN D=&H20
50 IF PEEK(&H157)=&HF7 THEN D=D-&H1
60 IF PEEK(&H158)=&HF7 THEN D=D+&H1
70 IF L+D<&H1FF THEN IF L+D>=. THEN L=L+D
80 IF PEEK(&H159)=&HF7 THEN PRINT@L,"O"; ELSE PRINT@L,"X";
90 GOTO 20

For speed, decimal values have been replaced with hex, and zeros have been replaced with “.” (yeah, it’s weird, but it’s faster). We could further optimize by removing spaces and combining some of the lines (and cheating by replacing the GOTO loop with a FOR/NEXT/STEP 0 hack), but for now, we’ll start with this.

When you run this program, it prints an “X” in the center of the screen. Using the arrow keys you can move the X around, leaving a trail. Hold down space, and you leave a trail of Os. There is limited checking to make sure you don’t try to print off the top or bottom of the screen.

We are now directly PEEKing the KEYBUF keyboard rollover table looking for those specific keys. We have key repeat, and the ability to detect multiple keys at the same time (such as UP+LEFT+SPACE).

Here’s what the code is doing:

Line 10 clears the screen and sets the PRINT@ location variable to the center of the screen.
Line 20 resets the four KEYBUF column values of the arrow keys. We don’t do this with the SPACE since it doesn’t seem to be needed (why not???). The movement delta value is set to 0 (this will be added to the PRINT@ location later).
Line 30-40 checks for UP and DOWN, and set the delta (movement) value to either -32 (moving up) or +32 (moving down).
Line 50-60 checks for LEFT and RIGHT, and ADD them to any existing delta value. This means UP could have set it to -32 and RIGHT could have added +1 to that, resulting in a delta of -31 (up and to the right).
Line 70 checks to see if the result of current location plus new delta is within the screen by being less than PRINT@511 or greater or equal to PRINT@0. If valid, it adds the delta to the location variable. Note we are using the “IF THEN IF” optimization trick that I learned about in this video from Robin @ 8-bit Show and Tell.
Line 80 checks for SPACE and then PRINTs an “X” or an “O” depending on if space is pressed or not.
Line 90 goes back and does it all again.

Here we have a very simple routine for moving something around the screen using PRINT@ coordinates (0-511). For a game, we would probably want to change this to using POKE screen locations (1024-1535) so we could PEEK to detect walls or enemies and such.

Since the title of this article series has the word “benchmark” in it, I suppose the next thing we should do it look at different ways to do this and find the ones that are faster.

To be continued…

Exploring Atari VCS/2600 Adventure – part 1

6 Replies

See also: part 1, part 2, part 3, part 4 … and more to come…

I have been on an Atari Adventure kick lately, which started after I played the game on a friend’s ATGames Legends Ultimate Arcade awhile back. Ignoring the weirdness of playing an Atari VCS game on something that resembles a 1980s arcade machine, it was like stepping back in time to when I lived in Mesquite, Texas (around 1980) and got to play it on a friend’s Atari.

Side note 1: I’ll be sharing the tale of growing up during the video game revolution of the 70s and 80s in a upcoming lengthy article series.

Side note 2: I also have an upcoming series about trying to code the Adventure game logic in Color BASIC on the CoCo.

Since that first exposure to Adventure on an actual Atari, I’d seen the game a few other times.

Indenture for the PC

There was the Indenture clone for PCs in the early 1990s. You can play it in a browser here:

https://archive.org/details/IndentureV1.71996CraigPellAdventure

It was a nice flashback after not seeing the game in over a decade. The author, Craig Pell, even added new levels with many more rooms. The original had 29 screens (well, 30 counting a hidden one) but Indenture has a level with 300.

Since it was a recreation, it does not accurately recreate the gameplay of the original. But, it’s still great fun.

Stella Atari emulator

Next was an encounter with an early DOS version of the Atari emulator Stella. This allowed a modern computer to play the game pretty much exactly as it was on an original Atari. (Though, without using an Atari joystick, it never felt quite real.)

https://stella-emu.github.io/

Atari Flashback 2

When I learned about the Atari Flashback 2 machine coming out, I was intrigued enough with this mini recreation of the Atari to actually buy one. Unlike the original Flashback unit, which was a Nintendo NES chipset with reprogrammed Atari games, the Flashback 2 was an actual re-engineered Atari machine. It could even be hacked to add a cartridge connector and play real Atari cartridges! And, it game with Adventure. Though I really only powered it on a handful of times before donating it to the Glenside Color Computer Club to be auctioned off at a CoCoFEST!

Atari’s Greatest Hits

In the years that followed, various software packages were released containing officially licensed Atari games running in some form of emulator. Atari’s Greatest Hits was sold for many consoles and computers. I had the edition that came out for iPhone and iPads:

It was great fun to play Adventure again, but a pain to do so using virtual touch controls on a tablet screen. Fortunately, the iOS version supported the iCade controllers and I even hacked up an interface to use a “real” Atari joystick on it (the joystick from my Atari Flashback 2). Here is is on my original first generation iPad:

Teensy 2.0 as an Atari 2600 joystick interface for iOS

That, and the Flashback 2, were the closest I’ve come to the real Adventure experience, due to accurate emulation and a real (replica) controller.

Warren Robinett speaks

My recent re-interest in Adventure was enhanced after watching this 2015 presentation by the game’s original author, Warren Robinett. He details the history of how the game was designed, and some insights in to how the code worked:

Warren Robinett’s postmortem presentation on how he wrote Atari Adventure

It was this video that got me interested in howthe game worked, rather than just how to play it.

Adventure Revisited port

I was unable to find any dedicated “Everything You Want To Know About How Atari Adventure Worked” website, but I did find a 2006 version (winventure.zip) by Peter Hirschberg. In contained a disassembly of the original Atari Adventure assembly code. He also translated that assembly into C++ and wrote new code to emulate machine-specific things like collision detection and the display. I don’t know where I found the original zip file, but here is the current version:

https://sourceforge.net/projects/adventurerevisited/

Because this version was based on the actual ROM assembly code, it should play much more accurately than the Indenture rewrite from 1991. I haven’t tested this myself since I’ve been busy playing it in an Atari emulator.

Side note: I just realized this is the guy who did the Adventure game for the iPhone back in 2008!

Dissecting Adventure

Thanks to the disassembly of the original source, and the rewritten version in C++, I was able to start looking at how the game worked. The first thing I did was look at how all the game levels we represented. Each screen was represented by 21 bytes of ROM code!

;Castle Definition                                                                                                 
 CastleDef:
  .byte $F0,$FE,$15  ;XXXXXXXXXXX X X X      R R R RRRRRRRRRRR
  .byte $30,$03,$1F  ;XX        XXXXXXX      RRRRRRR        RR
  .byte $30,$03,$FF  ;XX        XXXXXXXXXXRRRRRRRRRR        RR
  .byte $30,$00,$FF  ;XX          XXXXXXXXRRRRRRRR          RR
  .byte $30,$00,$3F  ;XX          XXXXXX    RRRRRR          RR
  .byte $30,$00,$00  ;XX                                    RR
  .byte $F0,$FF,$0F  ;XXXXXXXXXXXXXX            RRRRRRRRRRRRRR

Above is the data that is used to draw the castles in the game (yellow, white and black). There was another table that defined which set of graphics data to use, as well as what attributes such as “how” to draw it (more on that in a moment), what color to draw it, and what screens were connected to it on each side (up, right, down and left).

The screen was represented by 20 bits stored as three 8-bit bytes with four unused bits. Those bits represent the left side of the screen, then they are either reversed to create the other half of a symmetrical screen, or they are mirrored (draw the left side on the right) which was used in some of the mazes). It is amazing that the entire screen was defined by only 21 bytes! (And, since there were four unused bits for each three bytes, it could have been compressed further down to 17 bytes, though the extra code needed to handle this might not have fit in to the 2K of ROM space the game used.)

Decoding the data in C

For fun, I thought I’d try to convert those data bytes in to a C program and see if I could decode and display them. Here is the castle:

Atari Adventure screen graphics decoded in C.

My first attempt at the decoder wasn’t perfect (note that it’s missing the floor of the castle room), but it showed I was on the right track.

Decoding the data in Color BASIC

I next converted the bytes into Color BASIC DATA statements, then wrote a similar program to decode them:

Atari Adventure screen graphics decoded in Color BASIC.

The CoCo 1’s 32-column screen isn’t wide enough to display 40 ASCII characters, so I was only drawing half the image as a proof-of-concept.

I next converted the PRINT text to SET(x,y,c) plotting commands. This would let me draw on the low-resolution 64×32 8-color screen.

Atari Adventure screen graphics plotted in Color BASIC.

I made a simple program that let me enter a room number and then it would plot the data on the screen. Above is a screen shot from an Atari emulator on the left, and the CoCo screen on the right. Though the aspect ration doesn’t match, at least it shows the graphics are accurate.

This 64×32 “graphics” mode is actually made up of special text characters that represent a 2×2 graphics block. Those blocks can contain one color plus a black background. Because of this limitation, a screen block can either be the green/orange background color with or without a text character on it, or a black block with 1-4 of it’s 2×2 pixels set to a single color. Because of this limitation, graphics need to be specifically designed.

Since each Adventure screen used only one color for the graphics, I thought this might work out well. But, if I wanted to change the background color, that might present a problem since unless the graphics took up a full character block, they would always have the unused pixels set to black. I did a quick test and it looked like this:

Above you can see that certain blocks of the castle do not use up a full 2×2 block, so the unused pixels are set to black. I think this gives it a rather interesting 3-D effect, though that was not the intent. Here’s one of the mazes:

I think it looks pretty cool, though not accurate to the original.

The ROM code also contains the data that makes up the objects in the game, such as the dragons. Here’s a dragon with its mouth open:

;Object 6 : State FF : Graphic
 GfxDrag1:
  .byte $80                  ;X
  .byte $40                  ; X
  .byte $26                  ;  X  XX
  .byte $1F                  ;   XXXXX
  .byte $0B                  ;    X XX
  .byte $0E                  ;    XXX
  .byte $1E                  ;   XXXX
  .byte $24                  ;  X  X
  .byte $44                  ; X   X
  .byte $8E                  ;X   XXX
  .byte $1E                  ;   XXXX
  .byte $3F                  ;  XXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $3E                  ;  XXXXX
  .byte $1C                  ;   XXX
  .byte $08                  ;    X
  .byte $F8                  ;XXXXX
  .byte $80                  ;X
  .byte $E0                  ;XXX
  .byte $00

When I get some time, my next goal is to render all of those game characters, similarly to how I displayed my old VIC-20 game’s customer character set.

To be continued…

Benchmarking the CoCo keyboard – part 3

7 Replies

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

Before I get started today, I wanted to share a comment about part 2 left by Paul Fiscarelli on the Sub-Etha Software Facebook page:

Allen – one minor optimization in your assembly routine. You can remove line 130 CMPA #0. The zero flag will be set if your call to POLCAT [$A000] returns a no-keypress in the A-register, so the CMPA is redundant.
Paul Fiscarelli

Awesome! Thanks, Paul! It can be like this:

      ORG  $3F00
START LDX  #1024
LOOP  JSR  [$A002]
      CMPA #0      *REDUNDANT
      BEQ  LOOP
      STA  ,X+
      CMPX #1536
      BNE  LOOP
      BRA  START

And now back to the article…

After a few digressions, today I will finally get back to the original purpose of this article: seeing what is the fastest way to read they keyboard in Color BASIC. Specifically, reading things like arrow keys that repeat when you hold them down. This is useful for game programs where you probably want the most speed.

We start with some code from Jim McClellan that enables INKEY$ to keep reporting an arrow key as long as it is held down. Normally, INKEY$ reports one key then won’t give another until a new key is pressed (or the same key is released then re-pressed).

0 REM keyread.bas
10 CLS
20 POKE 341,255:POKE 342,255:POKE 343,255:POKE 344,255
30 I$=INKEY$:IF I$="" THEN GOTO 20
40 PRINT ASC(I$)
50 GOTO 20

The POKEs in line 20 do something that allows INKEY$ to keep reading the four arrow keys. Parsing four POKE statements every time through a loop is time consuming, so I will present a few alternatives.

It’s benchmark time!

First, a quick-and-dirty benchmark. This will reset the BASIC timer, then do those four pokes 1000 times and print the value of TIMER:

0 REM keybench.bas
10 TIMER=0
20 FORA=1TO1000
30 POKE341,255:POKE342,255:POKE343,255:POKE344,255
40 NEXT
50 PRINTTIMER

I removed unneeded spaces in line 30, and when I run this in Xroar using Color BASIC 1.1, it prints 1812.

The first optimization I did was change decimal values to HEX values:

10 TIMER=0
20 FORA=1TO1000
30 POKE&H155,&HFF:POKE&H156,&HFF:POKE&H157,&HFF:POKE&H158,&HFF
40 NEXT
50 PRINTTIMER

By changing the decimal values (341, 342, 343, 345 and 255) into HEX values, the result prints 862. This is over twice as fast! Nice.

I was curious if parsing four values was faster or slower than doing all four inside a FOR/NEXT loop, so I tried that:

10 TIMER=0
20 FORA=1TO1000
30 FORZ=&H155 TO&H158:POKEZ,&HFF:NEXT
40 NEXT
50 PRINTTIMER

And the space in the FOR command is required when typing it in by hand because the tokenizer doesn’t know when the HEX value ends and the next keyword, TO, begins. This method uses more memory since it needs an extra variable and some overhead for the FOR loop.

It also turns out to be slower. This one shows me 1148. Okay, so it’s faster to brute force through four POKEs than put them in a loop, but I expect at some point the loop is faster. (i.e., maybe it’s faster to FOR/NEXT 100 POKEs than do 100 separate POKEs… Or maybe not. Maybe some day I’ll try. But I digress…)

In my benchmarking BASIC series, I shared how using a variable can be faster than constant values. It can be much quicker to look up a variable value than parse characters and turn that into a value. I tried this:

1 V=341:W=342:X=343:Y=344:Z=255
10 TIMER=0
20 FORA=1TO1000
30 POKEV,Z:POKEW,Z:POKEX,Z:POKEY,Z
40 NEXT
50 PRINTTIMER

This uses even more memory than the FOR loop since it now takes five extra variables, but the payoff may be worth it. It prints 653! That is a third the time the original decimal version took.

However, the more variables a program uses, the longer it takes to look up variables further at the end of the variable table. You could always do this with V, W, X, Y, Z being the first variables in the list, assuming you’d look them up every time through the main program loop, but if you have other variables that need to be looked up more often, you might want those first, slowing down these… Does that make sense?

Thus, “your mileage may vary.” You can declare variables in the order they should be on the variable stack, with the ones you look up the most at the front of the list, and the ones you rarely use at the end:

DIM V,W,X,Y,Z,A

Looking at the previous example, I notice that Z (the value 255) is used four times on that line. I wonder what happens if I declare it first? I’ll just define it manually at the start of line 1:

1 Z=255:V=341:W=342:X=343:Y=344
10 TIMER=0
20 FORA=1TO1000
30 POKEV,Z:POKEW,Z:POKEX,Z:POKEY,Z
40 NEXT
50 PRINTTIMER

With this, the four lookups for Z should be faster. Indeed, this prints 632! Yep, changing the position of that one Z variable sped it up ever so slightly.

Does that matter? In a game, every few moments you can save in the main loop speeds the game up. Maybe it might.

My vote would be to start with the HEX version, and once the game is written, start playing with variable order and see if moving the POKE values into variables will help.

But is this the fastest was to read repeating keys in Color BASIC? Is there another way to do it that will work with all variations of Color BASIC?

Comment if you know a faster way I should look at.

Until next time…

Benchmarking the CoCo keyboard – part 2

8 Replies

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

Previously, a code snippet shared by Jim McClellan on Facebook motivated me to benchmark various methods of reading the CoCo keyboard in BASIC:

10 KBD=PEEK(135) AND PEEK(65282)
20 PRINT KBD
30 GOTO 10

Unfortunately, as I started my stream of consciousness article, I discovered that this sample code did not work on the Xroar emulator I was using. I recalled there had been some differences to Color BASIC’s keyboard scanning code in later versions, and thought this might be why.

Indeed, the knowledgeable Lost Wizard William Astle chimed in via comments:

I think it would only work on Color Basic 1.2 or 1.3. The reason for that is Color Basic 1.2 introduced an optimization where it only does the full matrix scan if no keys (or joystick buttons!) are pressed. It does this by writing a 0 to FF02 to “strobe” all columns. That means there will be at least one 0 bit in FF00 representing a key pressed if anything is down at all. If it detects nothing, it just exits, leaving the column strobe set to 0.
Prior to Color Basic 1.2, the matrix scan was always run. In that case, if no keys are down, it will have strobed all columns in sequence (by writing a zero bit to successive bits of FF02). This zero bit is shifted over by a ROL instruction so it eventually shifts off into carry and the final result in FF02 is FF. Eventually, most versions will eventually strobe no columns by writing FF to FF02 which is used to detect joystick buttons. The debounce check also puts a nonzero, non FF value in FF02 corresponding with the column where a key was detected. Depending on the Color Basic version, the final results of KEYIN and FF02 are (assuming I read the code correctly):
1.0: FF if no key jor joystick button, non-FF if key down (or debounce fails)
1.1: FF if no key or joystick button, non-FF if key down (or debounce fails)
1.2: 0 if no key or joystick button, FF if key or joystick button, not 0 or FF if debounce fails
1.3: same as 1.2; no modifications to KEYIN
Coco3: always FF (the check for a key optimization is removed) except when debounce fails
Basically, this trick only works on Color Basic 1.2 and 1.3. And even then, it isn’t actually reliable since you won’t get FF if debounce fails. Instead, you’ll potentially get a value with a single zero bit which will corrupt your key code. The odds of the timing being just right for that to happen are really small. However, it is possible.
So my considered opinion based on the variances between ROM versions is that this trick must not be used.
As a side note: aside from the system initialization code, KEYIN has the most significant changes between Color Basic versions.
William Astle

With this note, I now have to change my original plan for this article. I was going to see how much faster this code would be with normal tricks (HEX versus decimal constants, variables instead of constants, etc.) to see which approach would make any game using this code faster.

But since this sample only works with specific versions of Color BASIC, I now need to come up with a more portable non-portable way to do this. This sent me back to some other Facebook posts from Ben Jimenez and Jim Gerrie back in April 2020:

10 CLS
20 POKE 341,255:POKE 342,255:POKE 343,255:POKE 344,255
30 I$=INKEY$:IF I$="" THEN GOTO 20
40 PRINT ASC(I$)
50 GOTO 20

When I run this under Xroar using Color BASIC 1.1, I see that it will print a repeating series of numbers as I hold down each arrow key. I also notice that it repeats for some other keyboard presses, but not all.

But why? A new mystery!

I suspect this is because those POKEs must have something to do with the row or column the four arrow keys are in the keyboard matrix:

      1     2     3     4     5     6     7     8
      |     |     |     |     |     |     |     |
1 --- @ --- A --- B --- C --- D --- E --- F --- G 
      |     |     |     |     |     |     |     | 
2 --- H --- I --- J --- K --- L --- M --- N --- O 
      |     |     |     |     |     |     |     | 
3 --- P --- Q --- R --- S --- T --- U --- V --- W 
      |     |     |     |     |     |     |     | 
4 --- X --- Y --- Z -- UP -- DWN - LFT - RGT - SPACE 
      |     |     |     |     |     |     |     | 
5 --- 0 -- 1! -- 2" -- 3# -- 4$ -- 5% -- 6& -- 7' 
      |     |     |     |     |     |     |     | 
6 -- 8( -- 9) -- :* -- ;+ -- ,< -- -= -- .> -- /? 
      |     |     |     |     |     |     |     | 
7 -- ENT - CLR - BRK - ALT - CTL - F1 -- F2 - SHIFT

All four arrow keys are in row 4, and they repeat. I am betting that the other keys that repeat are the ones in the same columns UP, DOWN, LEFT and RIGHT are in (col 4-7). A quick test shows that @, A and B to not repeat (they use columns 1, 2 and 3), but C, D E and F do (columns 4-7) and G does not (column 8).

Mystery solved.

Whatever those POKEs are doing, they are resetting something involving columns 4, 5, 6 and 7. This sends me back into the Color BASIC Unraveled disassembly to see what memory locations 341 (&H155) to 344 (&H158) are:

0152  KEYBUF  RMB  8  KEYBOARD MEMORY BUFFER

Eight bytes, and we are setting four of them to 255 (all bits set to 1). No help so far. I start making notes:

KEYBUF - Keyboard memory buffer:

338 &H152
339 &H153
340 &H154
341 &H155 - POKEd to 255 (&HFF)
342 &H156 - POKEd to 255 (&HFF)
343 &H157 - POKEd to 255 (&HFF)
344 &H158 - POKEd to 255 (&HFF)
345 &H159

Next, I search the code to see where this KEYBUF is being used, and then things get confusing. The disassembly has multiple code listings that reference this — different code for different versions of the ROM. Great.

KEYIN konfusion

As William Astle referenced, this buffer is used by the KEYIN routine and there are multiple implementations. The code is described as:

KEYIN
SCAN THE KEYBOARD FOR A KEY DEPRESSION - Return zero
flag = 1 if no new key down. Return the ASCII value
of the key in ACCA if a new key is depressed.

Ah, this looks familiar. As soon as I read this, I remembered something from learning CoCo 6809 programming using the EDTASM cartridge.

POLCAT ROM routine digression

Microsoft, thinking ahead to potential changes in the ROM code, set aside a few “documented ROM calls” that assembly language programmers could use. If you wrote an assembly program for Color BASIC 1.0 and wanted to use the KEYIN routine in ROM by jumping directly to its address in the ROM, that program would not work in later Color BASIC 1.2 versions that had KEYIN at a different address.

Instead, Microsoft placed a few hooks in ROM starting at location &HA000. Each entry was the address of a routine elsewhere in the ROM. By using a “jump by reference” assembly instruction, you could end up at wherever those addresses point. POLCAT was the entry for getting a keystroke, and it points to KEYIN:

0002 A000 A1 CB  POLCAT  FDB  KEYIN   GET A KEYSTROKE
0003 A002 A2 82  CHROUT  FDB  PUTCHR  OUTPUT A CHARACTER
0004 A004 A7 7C  CSRDON  FDB  CASON   TURN ON CASSETTE MOTOR, START READING
0005 A006 A7 0B  BLKIN   FDB  GETBLK  READ A BLOCK FROM CASSETTE
0006 A008 A7 F4  BLKOUT  FDB  SNDBLK  WRITE A BLOCK TO CASSETTE
0007 A00A A9 DE  JOYIN   FDB  GETJOY  READ JOYSTICKS
0008 A00C A7 D8  WRTLDR  FDB  WRLDR   TURN ON MOTOR AND WRITE $55’S TO CASSETTE

That was the official documented way to see if a key was pressed. The implementation of what POLCAT points to changes between ROM versions, so while this compatible call would return a key, the way that it obtained that key changed.

Here’s a short assembly program using POLCAT (KEYIN).

Using the Color BASIC POLCAT ROM routine.

When I assemble that in EDTASM (“A/IM/WE/AO”) and execute from ZBUG (“Z”, “G START”), I can start pressing keys and see them POKEd to the top left corner of the screen, and moving forward as I press different keys. Holding down a key does not repeat. Thus, the KEYIN routine does not support keyboard repeat.

But I digress.

When Jim’s original code PEEKs two values from memory location 135 (last key pressed) and 65282 (&HFF02, the PIA chip that reads the eight keyboard columns of the keyboard matrix), it apparently relying on code in the Color BASIC ROM that is resetting things so it always updates. In the 1.1 ROM I am using, the ROM code is different so that method does not work.

However, the second bit of code (from either Jim or Ben) using the four POKEs and INKEY$ does appear to work on 1.1 as well as 1.2.

Dam this stream of consciousness!

Sorry to disappoint, but I’ll let someone else write an article explaining the differences in KEYIN. I can already see this is over my head without spending substantial time diffing through the various ROM versions…

At this point, I see WHAT works, but cannot explain WHY. In the next installment, I’ll move beyond the WHY and get back to the original goal of trying to make the WHAT work as fast as possible.

To be continued…

Benchmarking the CoCo keyboard – part 1

9 Replies

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

Updates:

2020-12-13 – Fixed a typo in the last BASIC example. Thanks, Johann K.
2020-12-14 – Fixed a typo in a PEEK command. My bad.

Over in the Facebook CoCo group, Jim McClellan posted a tidbit about reading the CoCo keyboard in BASIC:

I self answered a question I had and figured maybe this might be helpful info for other BASIC peeps. The location for whether a key is beng pressed is 65282. It’s either 255 (yes) or 0 (no) By peeking location 135 (135 retains the ASCII value of the key pressed even after releasing the key) and ANDing 65282, you can get a smooth, repeating key.

10 KBD=PEEK(135) AND PEEK(65282)
20 PRINT KBD
30 GOTO 10
Jim McClellan

Using standard BASIC commands, we have INKEY$ available to detect a keypress:

10 A$=INKEY$:IF A$="" THEN 10
20 PRINT "YOU PRESSED ";A$

This works great, and I have mentioned it in earlier articles on this site including one showing a way to use it without the variable by using it as a parameter of INSTR inside an ON GOTO.

But I digress.

INKEY$ only gets you the first press. It will not detect if the key is being held down. This limits its usefulness to one-key selections (without needing to press ENTER) and perhaps turn-by-turn games where you have to press a directional arrow over and over to move from position to position.

Most games want to move as long as you are holding down the arrow key, and Jim was sharing a way to do that easily by using PEEK.

What the PEEK is going on?

I wanted to understand what these PEEKs are doing, so I consulted the Color BASIC Unravelled book:

0146   0087   IKEYIM   RMB   1   *TV INKEY$ RAM IMAGE

Memory location 135 (&H87 hex) contains the last key handled by INKEY$. Except, that must not be technically correct because it works without calling INKEY$. Looking further into the disassembly, I see that it is actually where the BREAK CHECK stores the key it found:

It checks for BREAK and also the PAUSE key (SHIFT+@ on the CoCo keyboard, which now I see returns as &H13 from the “GET A KEYSTROKE ENTRY” routine). Thus, while INKEY$ uses this location…

…it is not involved with setting that location. (Note to self: Explore what KEYIN does.)

Doing a PEEK(135) will return whatever the last pressed key was, as detected by the looping BREAK check code. By itself, you could use this for a game where the player never stops moving, or only stops when you press a “stop moving” key.

GAME: Never Stop Moving using PEEK

0 REM nsm.bas
10 CLS0
20 PRINT STRING$(32,153);
30 FOR A=0 TO 12
40 PRINT CHR$(153);STRING$(30,32);CHR$(153);
50 SOUND 200-A*2,1:NEXT
60 PRINT STRING$(32,153);
70 L=1024+8*32+16:SC=0
80 POKE L,255:SOUND1,1
90 K=PEEK(135)
100 IF K=94 THEN M=-32
110 IF K=10 THEN M=32
120 IF K=8 THEN M=-1
130 IF K=9 THEN M=1
140 POKE L,96:IF PEEK(L+M)=96 THEN L=L+M ELSE 200
150 PRINT @480,SC;:IF K<>0 THEN SC=SC+1
160 GOTO 80
200 SOUND 1,5
210 PRINT @32*7+11,"GAME OVER!";
999 GOTO 999

In this pointless game (though I’ve seen worse for smartphones), you begin moving a red block around the screen using the arrow keys. Once you start moving, it will never stop unless you crash into a wall, ending the game. How high of a score can you make?

GAME: Never Stop Moving using INKEY$

It would have been easier (and more portable) to do this without PEEK and use INKEY$. All we would have needed was a check for no key being pressed, and then continue using the last direction used. Something like this would work:

0 REM nsm2.bas
10 CLS0
20 PRINT STRING$(32,153);
30 FOR A=0 TO 12
40 PRINT CHR$(153);STRING$(30,32);CHR$(153);
50 SOUND 200-A*2,1:NEXT
60 PRINT STRING$(32,153);
70 L=1024+8*32+16:SC=0
80 POKE L,255:SOUND1,1
90 K$=INKEY$:IF K$<>"" THEN K=ASC(K$)
100 IF K=94 THEN M=-32
110 IF K=10 THEN M=32
120 IF K=8 THEN M=-1
130 IF K=9 THEN M=1
140 POKE L,96:IF PEEK(L+M)=96 THEN L=L+M ELSE 200
150 PRINT @480,SC;:IF K<>0 THEN SC=SC+1
160 GOTO 80
200 SOUND 1,5
210 PRINT @32*7+11,"GAME OVER!";
999 GOTO 999

By avoiding CoCo-specific PEEKs, this version may run on an MC-10 or Dragon.

But, using PEEK may be faster since it has less BASIC to churn through than an INKEY$, IF and ASC() conversion. (Note to self: Benchmark PEEK versus INKEY$, assuming I haven’t already done that in an earlier article.)

But what if you wanted the player to move ONLY when the key is being pressed down? INKEY$ cannot do that, and neither can PEEK(135). That’s where the second memory location come in to play:

Decoding the (keyboard) Matrix

The Unraveled book shows that memory location 65282 (&HFF02) is part of a PIA that is hooked to the keyboard column matrix. BASIC uses this to determine which key is being held down:

Two bytes earlier is a similar value for the keyboard rows:

These bits are set or clear based on what key in the keyboard matrix is being held down.

                Color Computer Keyboard Array 
    Pin 1 --- @ --- A --- B --- C --- D --- E --- F --- G 
              |     |     |     |     |     |     |     | 
    Pin 2 --- H --- I --- J --- K --- L --- M --- N --- O 
              |     |     |     |     |     |     |     | 
    Pin 3 nc  |     |     |     |     |     |     |     | 
              |     |     |     |     |     |     |     | 
    Pin 4 --- P --- Q --- R --- S --- T --- U --- V --- W 
              |     |     |     |     |     |     |     | 
    Pin 5 --- X --- Y --- Z -- UP -- DWN - LFT - RGT - SPACE 
              |     |     |     |     |     |     |     | 
    Pin 6 --- 0 -- 1! -- 2" -- 3# -- 4$ -- 5% -- 6& -- 7' 
              |     |     |     |     |     |     |     | 
    Pin 7 -- 8( -- 9) -- :* -- ;+ -- ,< -- -= -- .> -- /? 
              |     |     |     |     |     |     |     | 
    Pin 8 -- ENT - CLR - BRK - ALT - CTL - F1 -- F2 - SHIFT 
              |     |     |     |     |     |     |     | 
    Pin 9 -----     |     |     |     |     |     |     | 
                    |     |     |     |     |     |     | 
    Pin 10 ----------     |     |     |     |     |     | 
                          |     |     |     |     |     | 
    Pin 11 ----------------     |     |     |     |     | 
                                |     |     |     |     | 
    Pin 12 ----------------------     |     |     |     | 
                                      |     |     |     | 
    Pin 13 ----------------------------     |     |     | 
                                            |     |     | 
    Pin 14 ----------------------------------     |     | 
                                                  |     | 
    Pin 15 ----------------------------------------     | 
                                                        | 
    Pin 16 ----------------------------------------------

But, from my testing, just PEEKing these I/O values does not work, at least not on Color BASIC 1.1. (Keyboard scanning changed a bit in later version of the Color BASIC ROMs.) I am unfamiliar with using the PIA so there may be some other things that have to be done to set it up before you can read it. Still, just PEEKing doesn’t do it for me.

10 PRINT PEEK(65282):GOTO 10

I get 255s over and over, though sometimes it looks like it might be blipping to a different value. To catch the changes, I tried this:

10 P=PEEK(65282)
20 IF P<>LP THEN PRINT P:LP=P
30 GOTO 10

Jim says it is 0 if nothing is pressed, or 255 if any key is being held down. From looking at the matrix, even if this did work, it seems like it would only be 0 if nothing was held down in any column, and 255 if a key was held down in each column. Can this be correct?

So I ask the audience: Why does this work for Jim, but not in the Xroar emulator I am using?

Comments are apprecaited!

To be continued…