the calling GOSUB (in this case, Line 70) to the specified
line number (Line 1000), then from the RETURN (Line
1095) back to the line following the GOSUB (Line 80).
• Lines 80 - 200 comprise the main loop of the
program, which converts keystrokes into program
commands or characters on the screen. Lines 110 - 140
check for Function Keys 1 (ASCII 208) through 6 (ASCII
213). If these are not found, program execution continues
at Line 150. If F1 through F6 is presented, Line 130 sends
program flow to the appropriate subroutine. Then, Line
140 jumps to the top of the loop for another keystroke.
Note the use of the expression (k-207)*1000 in Line 130
to select the proper subroutine. In Color BASIC, both
GOTO and GOSUB can use expressions like this, as well
as explicit line numbers.
• Lines 150 - 160 provide the program with an
important capability: the ability to backspace to correct
errors. If the keystroke is a <Backspace> (ASCII 200), Line
160 displays an ASCII 8 (move the cursor back one
space), an ASCII 32 (print a space over the current
character), and an ASCII 8 (move the cursor back one
space again). This is a bit confusing at first, but it makes
sense after you think about it. After eliminating the
offending character, program flow jumps back to get
• Lines 170 - 190 print the character glyph of any
remaining keystroke value, then goes back for another
keystroke. This process continues until the program is
ended by the F6 command.
• Now, let’s take a look at the subroutines. Lines
1000 - 1095 print the commands screen, which lists the
active function keys and the function each performs. Note
the use of GOSUBs in Lines 1005 and 1055 to avoid
duplicating code. (Subroutines can “nest” one inside
another five deep in Color BASIC.) The strange numbering
on Line 1095 and the other RETURN statements are there
because I first put a program “stub” in for each subroutine
when developing my code — just the REM statement label
and the ending RETURN statement. This lets me set up
and check my program framework first, and then build
(and improve) the functional modules after program flow
has been validated.
• Lines 2000 - 2095 clear the screen in the screen
color c, then set the text colors back to f and b.
• Lines 3000 - 3095 display a change-text-colors
indicator (a rectangle containing a dot) in the current
colors, then allow the user to change colors with the
arrow keys, pressing <Enter> to return to typing mode. The
left and right arrows (ASCII 192 and193) decrement or
increment f; up and down (ASCII 194 and 195) increment
or decrement b. After setting the text colors to the new
value and backspacing over the change-color indicator,
program flow loops to the top of the routine unless the
<Enter> key (ASCII 13) has been pressed. This design has
less user prompting than I like, but doesn’t require us to
separately track the cursor in our code.
• Lines 4000 - 4095 erase the current screen, present
the color value set in the assigned colors, and prompt the
user to select a new color. Note that in the call to the
clear-the-screen subroutine in Line 4040, all variables are
shared among subroutines in Color BASIC. So, the value
of c set in Line 4035 is available to Line 2005 without any
explicit passing of variables.
• Lines 5000 - 5095 simply print a smiley at the
current cursor location, in the current foreground and
background text colors.
• Lines 6000 - 6095 end the program, first getting
user confirmation, then resetting the redefined characters
and screen color, then clearing the screen and printing a
READY prompt. The RETURN in Line 6095 is never
executed, but left in there for consistency.
You should find it fairly straightforward to add features
to this code that you and your protégé come up with —
more emoticon function keys is a good place to start. If
you haven’t done so yet, check out the REDEFINE.BAS
program that ships with the Amigo kit (available through
the Nuts & Volts webstore). It should help with developing
REDEFINE statements for any new glyphs you implement.
May 2016 47