2068 Windows

This program demonstrates a windowing system for the TS2068, drawing up to three overlapping rectangular windows on screen using custom UDG (User Defined Graphic) characters for the window borders. Two machine code routines are embedded via DATA statements and POKEd into memory: one saves a 24×32 screen region to a buffer at address 59199, and the other restores it, enabling non-destructive window display using LDIR block-copy instructions. The program stores window geometry (row, column, width, depth) as formatted strings in a DIM array and parses them with VAL at runtime. A POKE to address 23659 (the lower-screen control) toggles between 0 and 2 to suppress or restore the lower display area during drawing. After the three demonstration windows, the user may enter custom window coordinates to test their own layout.

---

Program Structure

The program is organized into a linear demonstration flow followed by a subroutine block:

1. Lines 20–30: Initialization — clear memory, call setup subroutine, fill screen with test pattern, save screen via machine code.
2. Lines 40–130: Sequential display of three demo windows, each waiting for a specific keypress before proceeding.
3. Line 150: Easter egg — prints “Move over MACintosh!” character by character from a DATA statement using CHR$.
4. Lines 160–300: User-input loop allowing custom window coordinates, then drawing and pausing.
5. Lines 170–260: Core window-drawing subroutine, handling UDG border rendering and lower-screen toggling.
6. Lines 310–340: Setup subroutine — initializes DIM array, POKEs machine code, reads UDG pixel data, and reads default window coordinate strings.

Machine Code Routines

Two Z80 machine code routines are POKEd into memory starting at address 59199 (store) and 59211 (renew), each using the Z80 LDIR instruction (opcode ED B0) for a block memory copy of 24×32 = 768 bytes (the full text screen):

• store (59199): Copies from display memory at 16384 ($4000) to buffer at 59223 ($E757). Parameters: BC=24 (rows, though actually 768 bytes should use BC=0,24 i.e. LD BC,24*32).
• renew (59211): Copies the buffer back to display memory, restoring the background screen before each new window is drawn.

The DATA sequence for these routines is: 1,0,24,17,87,231,33,0,64,237,176,201,1,0,24,17,0,64,33,87,231,237,176,201. Each 12-byte block decodes to: LD BC,6144 (note: 1,0,24 = LD BC,$1800 = 6144, covering the full character display); LD DE,$E757; LD HL,$4000; LDIR; RET. The second routine reverses source and destination.

A second block of 64 bytes is POKEd to addresses 65368–65431, containing UDG pixel patterns (read from DATA line 330) for the eight window-border characters (UDGs \\a through \\h, chars 144–151), defining corners and edge tiles.

Window Geometry Encoding

Window parameters are stored as fixed-format 11-character strings in a DIM w$(PI,11) array — using PI (≈3.14, truncated to 3) to dimension exactly three rows. Each string follows the pattern "RR,DD,CC,WW" (row, depth, column, width), parsed at line 170 with VAL w$(n, TO 2), VAL w$(n,4 TO 5), etc.

Window	String	Row	Depth	Col	Width
1	“11,12,02,03”	11	12	2	3
2	“13,20,02,17”	13	20	2	17
3	“10,08,16,04”	10	8	16	4

Lower Screen Control

The system variable at address 23659 (lower) controls the number of lines in the lower (INPUT/scrolling) display area. The program POKEs it to 0 before printing window graphics and restores it to 2 afterward. This prevents the lower screen from interfering with windows drawn near the bottom of the display. Line 130 explicitly wraps its PRINT between POKE lower,0 and POKE lower,2 for window 3, which is positioned in the lower region.

UDG Border Drawing

The window-drawing subroutine (lines 170–260) uses UDG characters 144–151 (\\a through \\h) for all eight border elements:

• CHR$ 144 / CHR$ 146: top-left and top-right corners
• CHR$ 145: top horizontal fill
• CHR$ 147 / CHR$ 148: left and right vertical sides
• CHR$ 149 / CHR$ 151: bottom-left and bottom-right corners
• CHR$ 150: bottom horizontal fill

The interior of each window is filled with spaces. The subroutine also handles an edge case (line 250) where the window bottom row falls on line 22 or 23: it uses OVER 1 to XOR-print spaces across the remaining columns before printing the corner, avoiding scroll or display corruption.

Key BASIC Idioms

• DIM w$(PI,11) exploits the fact that PI truncates to 3 to define a 3-row string array without using the literal digit — a space-saving trick.
• VAL "number" is used implicitly through substring slicing of the coordinate strings, which is more compact than storing separate numeric variables for each window.
• RESTORE 150 before the DATA on line 150 and RESTORE 310 on line 310 ensure the correct DATA pointer regardless of prior reads.
• The keypress loops (lines 60, 100, 140) poll INKEY$ directly with a self-referencing GO TO, a standard tight-loop wait idiom.

Bugs and Anomalies

• Line 280 contains a spelling error in the prompt: “Cooridnates” instead of “Coordinates”.
• The boundary check at line 180 uses r+d>24 and c+w>32; given that screen positions are 0-based (0–23 rows, 0–31 cols), windows with r+d=24 or c+w=32 are actually valid but would be flagged as too large — a slight off-by-one in the guard condition.
• The DATA on line 330 uses lowercase a as a placeholder value (likely 0 or a don’t-care filler for UDG rows that are blank), which is unusual but syntactically valid since BASIC reads numeric DATA values.
• Line 50 includes embedded control characters \\{16}\\{0} (INK 0) inside the PRINT statement to set ink color, directly embedded in the source as character codes 16 and 0.