Spectral Piano

This program implements a piano simulator called “Spectral Piano” that draws a visual keyboard on screen and plays notes using the BEEP command. It defines eight User Defined Graphics (UDGs, characters 144–151) loaded via DATA statements to render the piano key shapes, using block graphics for white and black key visuals. The keyboard spans one octave of white keys mapped to A–J and black keys mapped to W, E, T, Y, U, with octave selection via I/O/P keys and note duration controlled by keys 1–9 in tenths of a second. An introductory subroutine at line 590 displays a multi-screen tutorial with instructions before entering the main play loop. The BEEP arguments use semitone offsets (0–11) combined with an octave offset variable, covering three octaves of the chromatic scale.

---

Program Analysis

Program Structure

The program is organized into three logical phases. Lines 10–130 initialize the eight UDG characters used to render piano key graphics. Lines 140–580 contain the main keyboard display and play loop. Lines 590–770 form the introductory tutorial subroutine, which is called first via GO SUB 590 at line 10 and returns to the main loop after the user completes the walkthrough. Lines 780–820 are unreachable dead code following the GO TO 310 loop.

1. UDG initialization (lines 10–130)
2. Tutorial subroutine (lines 590–770)
3. Keyboard rendering (lines 140–300)
4. Main play loop (lines 310–580)
5. Unreachable cleanup/save code (lines 780–820)

UDG Definitions

Eight UDGs (characters 144–151, accessed as \a through \h) are loaded from DATA at lines 60–130. They are designed in pairs to represent the tops and bottoms of piano keys. The inner loop at lines 30–50 POKEs each 8-byte bitmap into USR CHR$ c+n. The UDGs represent:

UDG	Char code	Role
\a	144	Black key top-left
\b	145	Black key top-right
\c	146	Black key bottom-left
\d	147	Black key bottom-right
\e	148	White key pressed top-left
\f	149	White key pressed top-right
\g	150	White key unpressed top-left
\h	151	White key unpressed top-right

Keyboard Layout and Note Mapping

The visual keyboard is drawn using PLOT/DRAW for the outline (lines 240–250) and PRINT for the key fill characters (lines 260–300). White keys are mapped to letters A–J (7 keys) covering the chromatic white notes C through B, and black keys are mapped to W, E, T, Y, U — a layout matching the physical arrangement of sharps and flats. BEEP arguments for semitone pitch use offsets 0–11 from middle C, combined with the octave offset variable o which is set to −12, 0, or +12 by the I, O, and P keys.

Key Press Visualization

When a white key is pressed, the program substitutes the “pressed” UDG pair (\e\f) at the correct screen position via PRINT AT, calls BEEP, then restores the “unpressed” UDG pair (\g\h). Black keys similarly swap between \a\b and \c\d. This gives a simple but effective visual key-press animation. Because INKEY$ is polled without any wait loop, the main loop at lines 310–580 runs continuously and checks each key sequentially on every pass.

Notable Techniques

• UDGs are addressed via USR CHR$ c+n inside a nested FOR loop, efficiently loading all 64 bytes in sequence from DATA.
• The OVER 1 attribute is used on the title screen (line 590) to underline the program title by XORing underscores over the text.
• Note duration is stored as a decimal fraction in variable len (0.1–0.9), set directly by keys 1–9, avoiding any arithmetic conversion.
• The octave variable o shifts all BEEP pitch values uniformly by ±12 semitones, keeping note mapping code identical across octaves.
• The tutorial subroutine uses multiple INPUT statements (lines 690, 710, 730, 740, 760) to page through instructions, with a loop back to GO SUB 590 if the user answers “n” to the comprehension check.

Bugs and Anomalies

• Line 270 contains IF n=13 THEN NEXT n, which attempts to skip column 13 during black key rendering to leave the gap between E and F. However, the loop steps by 2 from 9, producing values 9, 11, 13, 15, 17, 19 — so n=13 is indeed reached, and this workaround is correct in intent, though unusual in style.
• The word “Lenght” (should be “Length”) is misspelled in both the tutorial text (line 670) and the on-screen display (line 440), appearing consistently throughout.
• Lines 780–800 (PAUSE 0, PAPER 7/INK 0/BORDER 7/FLASH 0/CLS, STOP) are unreachable because the main loop at line 580 performs an unconditional GO TO 310. These lines appear to be cleanup code that was never wired in.
• The variable name len shadows the built-in LEN function. While BASIC is case-insensitive for keywords, using len as a numeric variable works here only because it is never used in a context that would conflict with the string-length function.
• Line 750 contains a trailing REM 32 comment, likely a note to the programmer about the number of characters being cleared, not functional code.