BBS Chess

This program implements a chess board manager designed for use with bulletin board systems (BBS), allowing two players to conduct a correspondence chess game by saving board states to memory and uploading screen content to a message buffer. The board is rendered using a combination of text characters and user-defined graphics (UDGs) stored via POKE statements into memory starting at addresses such as 64272 and 64344, covering six piece types (bishop, king, knight, pawn, queen, rook) in two sets for black and white. Piece positions are tracked in an 8×8 string array `f$`, with column coordinates translated from algebraic notation (a–h) via a linear search through the string “abcdefgh” in the subroutine at line 8500. The screen capture routine at line 4000 copies the display using `SCREEN$` into a 533-byte buffer at address 50000, ready for upload through terminal software (Mterm II), with specific POKEs (23627, 107 and 23628, 106) and a `RANDOMIZE USR 54016` call to interface with external code loaded at address 26710. The `OVER 1` mode is used at lines 1036–1111 to overlay the dark-square checkerboard pattern onto the board display without erasing the existing text.

---

Program Analysis

Program Structure

The program is divided into several functional blocks:

1. Lines 10–40: Title screen flash and UDG/sprite data loading via POKE.
2. Lines 50–70: Main menu and introductory text display; branch to continue or start new game.
3. Lines 100–133: Board variable initialization — column pattern string, move record, separator string, and the 8×8 piece array f$ seeded with starting positions.
4. Line 200–201: Player color selection (black = uppercase letters, white = lowercase).
5. Lines 1000–1140: Board redraw routine: prints the text grid, overlays the checkerboard pattern using OVER 1, then prints piece legend and move history.
6. Lines 3000–3030: Piece rendering dispatch and move input loop.
7. Line 4000–4030: Screen capture to buffer at 50000, save routines, and terminal handoff instructions.
8. Lines 8000–8010: Subroutine to print one row of pieces onto the board.
9. Lines 8500–8580: Algebraic notation parser — converts move string (e.g., “a2 to a4”) into array indices.

UDG / Sprite Loading

Lines 20–32 define DATA blocks for six chess piece sprites in two sets (one per player), plus a board square pattern. Each DATA line begins with a destination address followed by 8 bytes of bitmap data. Line 40 loops over DATA lines 20–32, RESTOREing each line in turn, reading the target address into loc, then POKEing 8 bytes sequentially. This technique avoids needing a separate machine code loader — pure BASIC handles the transfer.

Line	Address	Piece	Set
20	64272	Bishop	1
21	64344	King	1
22	64368	Knight	1
23	64384	Pawn	1
24	64392	Queen	1
25	64400	Rook	1
26–31	64528–64656	All six	2
32	64024	Square pattern	—

Board Representation

The board state is held in f$(8,8), an 8×8 string array where each cell contains a single character: uppercase letters for black pieces (R, N, B, Q, K, P) and lowercase for white (r, n, b, q, k, p), with a space representing an empty square. Initial positions are set directly by assigning string slices at lines 130–133. Only the back ranks and pawn ranks are populated; the middle four rows default to spaces from DIM.

Checkerboard Overlay with OVER 1

Lines 1036–1111 use OVER 1 (XOR plotting mode) to print the dark-square pattern string c$ (” # # # #”) at alternating rows and column offsets across the board area. Because OVER 1 XORs characters onto whatever is already on screen, the piece letters printed later in the rendering pass coexist with the pattern without being erased. OVER 0 is restored at line 1111.

UDG Font Switching via POKE 23607

The system variable at address 23607 (UDG pointer high byte) is manipulated at lines 1035, 1115, 3000, and 3005. POKEing 249 shifts the UDG table to point to the loaded sprite data (in the 64000s range), causing the piece characters to render as graphical sprites. POKEing 60 restores the default UDG base, switching back to normal characters for text output. This allows the same character codes to display either as letters or as chess piece bitmaps depending on context.

Algebraic Notation Parser (Lines 8500–8580)

The subroutine at line 8500 parses a move string of the form “a2 to a4” stored in i$. It performs four sequential linear searches through strings “abcdefgh” and “12345678” to convert characters at positions 1, 2, 7, and 8 of i$ into integer indices a, b, c, d. Each search uses a FOR/IF/GO TO pattern with a fall-through NEXT on a separate line — a common BASIC idiom for early-exit loops. The resulting indices directly address f$() to move a piece.

Screen Capture and BBS Buffer

Line 4000 iterates over rows 1–17 and columns 0–30 of the display using SCREEN$, POKEing each character’s CODE into a buffer starting at address 50000, with CHR$ 13 (carriage return) appended after each row. This produces a 533-byte plain-text representation of the board suitable for uploading to a BBS message. The program then saves this buffer as "chess"CODE 50000,533 and saves itself as "chessgame" LINE 1. Instructions in lines 4012–4020 describe loading the code at address 26710 in Mterm II, followed by specific POKEs to 23627/23628 and a RANDOMIZE USR 54016 call to trigger a terminal upload routine.

Bugs and Anomalies

• Lines 8000–8010 control flow: The subroutine at line 8000 contains an IF ... THEN ... NEXT l: RETURN construct that only advances vert and loops when the condition is true. Line 8005 handles the false branch (piece present but not lowercase), and line 8010 provides the shared NEXT l: RETURN. However, when the condition at 8000 is false, execution falls through to 8005 without branching to 8010’s NEXT first — the NEXT l at 8010 would need to be reached for the loop to continue. This is a structural anomaly that may cause incorrect rendering for uppercase (black) pieces in graphical mode.
• Color selection branch: Line 200 branches to GO TO 1000 only if the player enters “u” (intending white/lower case), but sets d$="white (lower case)". The logic seems inverted — the white player would normally play lowercase pieces, yet the branch skips board initialization at lines 130–133 which is already done. The color labeling may confuse players.
• Move input prompt: Line 3010 expects the STOP sentinel as the string " STOP " (with spaces), which requires the player to type exactly that string including surrounding spaces, making it easy to miss.
• Uninitialized graph on continue: When loading a saved game (GO TO 1000 from line 70), graph is never set, so it retains whatever value it had — or may be uninitialized on a fresh load, potentially causing issues at line 1035’s conditional POKE.