Font III

This program installs a machine code font-switching routine into RAM at address 65280, enabling four display styles for the system font: Bold, Modern, Italics, and Regular. The 80-byte machine code payload is loaded via a DATA/READ loop using POKE into the top of RAM, with CLEAR 65279 reserving that area from BASIC’s memory management. Once installed, the routine is invoked with RAND USR 65280 (or offsets 65281/65282 for alternate styles), and the font pointer at system variables 23606/23607 is updated to redirect character rendering to the modified font data. The REM lines serve as embedded documentation, noting the program is designed to be merged with a companion “banner3” program, and was published in ZX/TS Forum, September 1985.

---

Program Analysis

Program Structure

The program is split into two functional sections. Lines 20–70 handle initialization: reserving memory, loading machine code, and poking it into place. Lines 100–140 are pure documentation in the form of REM statements, explaining how to invoke each font style after the routine is installed.

1. Line 20: Clears the screen, reserves memory below 65280 with CLEAR 65279, then reads and POKEs 80 bytes of machine code into addresses 65280–65359.
2. Lines 30–70: Five DATA statements supply the 80 machine code bytes.
3. Lines 100–140: REM blocks document the four invocation methods.

Machine Code Installation

The loader loop at line 20 is a standard Sinclair idiom:

• CLEAR 65279 moves RAMTOP to 65279, preventing BASIC from overwriting the code at 65280 and above.
• FOR i=0 TO 79: READ k: POKE 65280+i,k: NEXT i deposits exactly 80 bytes into high RAM.
• The routine is placed near the top of the 64K address space (65280 = 0xFF00), a common location for small resident utilities.

Font Invocation Interface

The installed routine exposes three entry points, differentiated by the offset passed to RAND USR:

Style	Entry Point	System Variable Update
Bold	RAND USR 65280	POKE 23607,251
Modern	RAND USR 65281	POKE 23607,251
Italics	RAND USR 65282	POKE 23607,251
Regular	(no USR call)	POKE 23606,0: POKE 23607,60

System variables 23606–23607 hold the address of the character set (CHARS pointer). The value 60×256 + 0 = 15360 = 0x3C00 is the ROM’s built-in font base minus 256 (the standard default). Setting 23607 to 251 (0xFB = high byte of 0xFB00 area) redirects rendering to the machine code’s generated font data in high RAM. The low byte 23606 remains implicitly set by the USR call.

Machine Code Byte Analysis

Disassembling the 80-byte payload reveals Z80 code. Key observable patterns include:

• Byte 0 (0x00) = NOP — the three entry points at offsets 0, 1, 2 likely fall through to shared logic after skipping initialization steps.
• 0x79 = LD A,C; 0xCB,0x27 = SLA A — shift operations consistent with bit-manipulation for font style transforms (bold = ORing adjacent bits; italic = shifting rows).
• 0x21,0x00,0x3D = LD HL,0x3D00 and 0x11,0x00,0xFC = LD DE,0xFC00 — source (ROM font area) and destination (RAM buffer) addresses for copying/transforming glyph data.
• 0x01,0x00,0x03 = LD BC,0x0300 — loop count of 768 bytes = 96 characters × 8 bytes each, consistent with a full character set copy.
• 0xC9 = RET at byte 79 — clean return to BASIC via RAND USR.
• 0xB8,0x20,0xC4 near the end = CP B / JR NZ,offset — the inner copy/transform loop termination.

Notable BASIC Techniques

• Using RAND USR rather than PRINT USR or LET x=USR discards the return value cleanly without a variable assignment.
• The three adjacent entry points (65280, 65281, 65282) allow a single routine body to implement three behaviors by varying the starting instruction skipped — a compact Z80 technique exploiting fall-through.
• Restoring the Regular font requires only two POKEs to system variables with no USR call, since the ROM font needs no RAM copy.

Notes and Context

The line 5 and line 10 REM statements indicate this loader is intended to be MERGEd into a “banner3” program rather than run standalone. The publication credit in line 10 places this in ZX/TS Forum, September 1985. No anomalies or bugs are present; the byte count (0 TO 79 = 80 iterations) matches the DATA statements, which together supply exactly 80 comma-separated values.