Make UDGs

This program is a User-Defined Graphic (UDG) character generator that allows the user to design, edit, compile, save, and load custom UDG characters (slots \a through \u) on a grid-based interface. The editing grid is drawn using PLOT and DRAW commands to create an 8×8 pixel matrix, and individual pixel states are stored in a two-dimensional array `u(8,8)`. Compilation converts the binary matrix rows into byte values using the “BIN ” string prefix trick with `VAL`, then POKEs them directly into UDG memory via `POKE USR a$+j`. The SAVE and LOAD routines operate on a fixed 168-byte block starting at address 65368, which corresponds to the UDG character table. An EDIT function reverse-engineers existing UDG data from memory by reading bytes at the UDG base address (derived from system variables 23675–23676) and decomposing each byte into bits using repeated halving.

---

Program Analysis

Program Structure

The program is organized as a menu-driven application with a persistent display loop. After initialization, it presents a grid interface and repeatedly prompts the user for a UDG letter and then a command letter or coordinate. Control is dispatched via a series of IF … GO TO branches rather than a structured menu loop.

Line(s)	Purpose
10–30	Initialization: DIM array, set display attributes, call grid subroutine
40–130	Draw the UI: UDG key listing, sample graphics, coordinate labels
140–150	Print function menu and title/credits
160–310	Main input loop: select UDG, select command or set pixel
320–450	Compile routine: convert array to BIN bytes and POKE into UDG RAM
460–560	Delete routine: clear a single pixel in the array and on screen
570–640	Subroutine: draw the 8×8 PLOT/DRAW grid
650–790	Edit routine: read existing UDG bytes from memory and decompose into array
800–850	Load routine: tape LOAD of 168-byte UDG block
860–880	Save routine: tape SAVE of 168-byte UDG block
900	SAVE the program itself with autostart

Grid Drawing Subroutine

Lines 570–640 draw a 9×9 line grid (forming an 8×8 cell matrix) using PLOT and DRAW. Two FOR loops, each stepping by 8 pixels over the range 0–64, draw vertical and horizontal lines respectively. This creates a clean pixel-editing workspace in the lower-left portion of the screen coordinate space.

BIN String Trick for Compilation

The compile routine (lines 360–430) constructs a string of the form "BIN 01101010" by concatenating the literal prefix "BIN " with the eight values from row j+1 of the u() array using STR$. VAL b$ then evaluates this string as a BASIC expression, causing the interpreter to parse the BIN keyword and return the numeric byte value. This is then POKEd directly to USR a$+j, writing into the UDG definition area.

Edit / Reverse-Engineering UDG Data

The edit routine at lines 650–790 reads back existing UDG bytes from memory. It first reconstructs the base address of the UDG table by reading system variables at addresses 23675 and 23676 (the UDG system variable, stored little-endian): LET c=PEEK 23675+256*PEEK 23676. For each of the 8 rows of the selected character, it reads one byte and decomposes it into 8 bits using repeated integer halving: LET x=INT(b/2): LET d=b-2*x: LET b=x. Bits are extracted least-significant-first (right-to-left), so the loop variable l runs from 8 down to 1, correctly mapping bits to columns.

Save/Load of UDG Block

Lines 800–880 save and load the entire 21-character UDG block (21 characters × 8 bytes = 168 bytes) as a CODE block at address 65368. This address is the standard location of the UDG area at the top of a 48K RAM configuration. After a load or save completes, the program calls RUN to reinitialize, which is a clean way to reset the display and array state.

UDG Reference Display

Lines 40–60 iterate over UDGs \a through \u (indices 0–20), printing the lowercase letter name, an equals sign, and then CHR$(144+i) — the actual UDG character — so the user can see both the label and the current rendered glyph side by side. Lines 80–130 show a pre-arranged sample layout of the UDGs in pairs and a numeric row label, providing a visual reference panel.

Notable Techniques

• The "BIN " + STR$(bit) concatenation trick avoids manual bit-shifting arithmetic entirely, delegating binary-to-decimal conversion to the BASIC interpreter itself.
• The EDIT routine uses the UDG base pointer from system variables rather than a hardcoded address, making it resilient to RAM configurations where the UDG table could theoretically be relocated.
• Pixel setting (line 300) prints the block graphic \:: (a solid block) directly at the calculated screen position AT 13+N, L-1, keeping the display in sync with the array without redrawing the whole grid.
• Delete (line 540) uses a space character to erase the corresponding cell, again without grid redraw.
• Line 130 uses an inline FOR … NEXT on a single line to print row numbers 1–8 along the grid’s right edge efficiently.

Bugs and Anomalies

• Line 170 restricts UDG selection to codes 97–117 (letters a–u, 21 UDGs), which is correct. However, line 250 restricts column coordinates to 97–104 (a–h, 8 columns), also correct for 8-pixel width.
• Line 650 uses the variable name A$ (uppercase) while elsewhere the selected UDG letter is stored in a$ (lowercase). In Sinclair BASIC, variable names are case-sensitive only for single-letter numeric variables; string variable names like a$ and A$ are treated as distinct. This means the EDIT routine at line 670 uses CODE A$ rather than CODE a$, which would be uninitialized unless the user happened to use INPUT with uppercase. This is a likely bug — the intent was almost certainly a$.
• Lines 850 and 880: line 850 appears between the Load and Save routines but contains the Save banner print; the Save routine actually begins at line 860. This means the “SAVING DATA” flash message (line 850) is never reached from the Save dispatch at line 240 (GO TO 860), so the visual feedback is skipped for saves.
• The optional printer output at line 410 uses LPRINT VAL b$;" " with a trailing space for separation, but there is no LPRINT newline between rows, relying on the printer’s line width to wrap — this may produce garbled output on some printer interfaces.