Patience

This program implements the card game “11-Up Patience,” a solitaire variant where the player covers pairs of non-picture cards totaling eleven (Ace = 1) or a Jack-Queen-King run. Nine cards are laid out in a 3×3 grid, with a ninth central card slot for dealing when no moves are available. The deck is represented as a string variable p$ where each card occupies a 5-character record encoding face value, suit symbol, and ink color, and shuffling is accomplished by 60 iterations of string slicing and concatenation rather than any array-based Fisher-Yates algorithm. Card rendering at lines 1260–1390 draws pip layouts for each face value using block graphics and UDG characters, including distinct multi-row patterns for Jack, Queen, and King. The program uses DEF FN functions to map card positions (1–9) to screen coordinates, streamlining the PRINT AT placement arithmetic throughout.

---

Program Structure

The program is organized as a set of subroutines branching from a central game loop. The main sections are:

• Lines 1020–1030: DEF FN definitions and initialization preamble.
• Lines 1040–1090: Game setup — shuffling, dealing, and the main input loop.
• Lines 1090–1220: Input validation and game-move processing.
• Lines 1250–1390: Card-printing subroutine with pip layout logic.
• Lines 1400–1490: Pack preparation and shuffling routine.
• Lines 1510–1590: End-game handling (win/loss/replay).
• Lines 1600–1680: Title screen and instructions.
• Lines 1690–1750: Animated instruction text display and variable initialization.
• Lines 1760–1850: UDG graphics loader (tape-stop prompt, DATA, POKE USR).
• Line 9990: SAVE with autostart at the graphics loader.

Data Representation

The entire 52-card deck is stored as the string variable p$, where each card occupies exactly 5 characters:

Position	Content
1	Face letter/digit (A, 2–9, \a=10, J, Q, K)
2–3	Numeric value as two-digit string (e.g., “01” for Ace, “11” for Jack)
4	Suit symbol character from b$
5	INK color digit (0 for red suits, 2 for black suits — note: COL=0 for P=1,3 gives red, COL=2 gives black, which maps to INK 0=black and INK 2=red on Spectrum; the logic appears inverted but the coloring is set at line 1430)

The source template d$ at line 1410 encodes all 13 face values in 3-character groups. Cards are assembled into a$ by iterating over suits via b$, then p$ is assigned from a$.

The nine on-screen card positions each have their current face value tracked in the 2D string array r$(9,5), which stores just the numeric value portion (characters 2–3) of each card’s 5-character record.

Coordinate Mapping via DEF FN

Two DEF FN functions centralize the screen coordinate logic for the 3×3 grid plus central position:

• FN c(x) — returns the column (x-coordinate) for card position x, encoding the three columns at offsets 6, 12, 18, and 24.
• FN d(x) — returns the row (y-coordinate), stepping by 6 rows per tier, with a special case for positions above 4 and between 4 and 9.

These are called repeatedly throughout the dealing (line 1060–1070) and move-processing (line 1220) routines to avoid duplicated arithmetic.

Shuffling Algorithm

Shuffling (lines 1470–1480) performs 60 iterations. On each pass, a random 5-card block position A is selected. On even iterations the block is moved to the front; on odd iterations it is moved to the end. This is a cut-based string shuffle rather than a statistically uniform permutation, but provides adequate randomization for gameplay. A BEEP is sounded on each iteration to provide audiovisual feedback during the shuffle animation.

Input Validation

The input loop (lines 1090–1200) is thorough:

1. Length check — rejects inputs longer than 3 characters.
2. Character check — rejects any non-digit character via CODE comparison against 48–57.
3. Duplicate position check — rejects entries where two or more card positions are the same (using sum-of-equality-booleans idiom at lines 1130–1140).
4. Single-card input validation — only position “9” (the center deal card) is legal as a lone entry.
5. Sum validation — two-card entries must total 11; three-card entries must total 36 (i.e., J+Q+K = 11+12+13).

Error handling routes through the subroutine at line 1230 via the variable H (set to 1230 at line 1730), and the main game loop is retried via GO TO G where G=1100. This is a standard BASIC variable-as-line-number idiom used to make the target address modifiable at runtime.

Card Rendering

The subroutine at lines 1260–1390 draws each card using PRINT AT statements. The approach:

• A white (PAPER 7) rectangle is printed first to clear the card area, with height adjusted dynamically based on the row position (y).
• The face letter f$ and suit symbol e$ are placed in the top-left and bottom-right corners.
• Pip positions for numeric cards (Ace through 10) are rendered using a series of IF guards checking f$, each printing the suit symbol at the appropriate sub-cell offsets.
• Court cards (J, Q, K) use multi-character block graphic strings to draw representational figures.
• The UDG character \a (loaded at lines 1780–1840) represents the 10 card face, since a two-character “10” would not fit in a single character field.

UDG Graphics

Five UDGs (\a through \e) are defined in the loader section (lines 1760–1840). The DATA statements provide 8-byte bitmap patterns for each. These are POKEd into memory via USR CHR$ (97+N). The suit symbols for spades, clubs, diamonds, and hearts are stored in b$ using these UDGs. The graphics loader is placed first in the execution order (via the SAVE autostart at line 9990), so UDGs are ready before the main game runs.

End-Game Logic

The variable RES flags a resignation (line 1150 sets RES=1 when input is “0”). The end-game routine at line 1510 checks RES to branch between a loss message with a descending tone sequence and a win message with a rising arpeggio. The replay option (lines 1570–1590) re-runs initialization and the shuffle subroutine before jumping back to line 1050, allowing multiple games without reloading.

Notable Techniques and Idioms

• GO TO G and GO SUB H — variables used as line numbers for flexible jump targets (lines 1730).
• Boolean arithmetic in DEF FN — FN c(x) and FN d(x) use Spectrum boolean (0/1) expressions multiplied by offsets to compute positions without IF branches.
• Sum-of-booleans for duplicate detection — e.g., (Z(1)=Z(2))+(Z(1)=Z(3))+(Z(2)=Z(3)) at line 1140 returns non-zero if any pair matches.
• Animated instruction display (lines 1690–1700) — each character of each instruction line is printed one position at a time with a brief PAUSE and BEEP, creating a typewriter effect.
• PAUSE 0 / INKEY$ pattern — used at lines 1560–1590 for efficient keypress detection after end-game.

Bugs and Anomalies

• Line 1120 uses VAL Z$(N) after checking digit codes, but the outer loop variable conflicts: the outer FOR loop at line 1110 uses N, and line 1120 continues that loop — this is valid BASIC but the inline NEXT N at line 1120 completes the loop started at 1110, which is correct.
• Line 1230 contains an INPUT statement used as the error handler, but the branch from it via GO TO H (where H=1230) creates a recursive error-prompt loop — intentional design for repeated bad input.
• The FA variable (a flag for single-card plays) is checked at line 1160 but only set once at line 1170, and is never reset between individual input attempts within a session — this could cause spurious rejection of a legitimate single-card play after a prior single-card move, though the initialization at line 1720 resets it to 0 at game start.
• Line 1570 calls GO SUB 1710 twice (initializing variables redundantly) before calling GO SUB 1460 (the shuffle loop start, skipping pack assembly at 1400) — this means a replay reuses whatever pack was built initially but reshuffles it, which is functionally acceptable.