Screen Layout Examination

This program fills the entire display file and attribute memory with user-specified byte values, allowing direct exploration of how the screen layout works. The user enters a pixel byte (0–255) that is POKEd into all 6,144 bytes of display RAM (16384–22527), and a colour/attribute byte (0–255) that is POKEd into all 768 attribute cells (22528–23295). It then prints the chosen values on screen and waits for a keypress before looping back to accept new values. Because PRINT AT writes into the already-modified display, the text rendering itself demonstrates how attribute bytes affect ink and paper colours for any character cell.

Program Analysis

Program Structure

The program is organised into clearly labelled REM-delimited sections, each announced by a comment block before the working code. The overall flow is a simple loop: set up display attributes, get two values from the user, POKE them into screen memory, display a summary, wait for a keypress, then restart.

1. Lines 10–29: REM headers only (no executable code)
2. Line 30: Reset display attributes to a clean black-on-white state
3. Lines 50–80: Input validation loop for byte and color
4. Lines 100–120: POKE loops filling display file and attribute file
5. Line 140: Print summary using PRINT AT
6. Line 160: Busy-wait for any keypress
7. Line 170: Loop back to line 10

Memory Map Usage

The program directly addresses the two distinct regions of screen RAM:

Filling the entire display file with a single byte value is an effective demonstration because each byte controls eight horizontal pixels in one character row. Values like 255 (all pixels on), 0 (all pixels off), 170 (10101010 alternating), or 85 (01010101 alternating) produce visually distinct and instructive patterns.

Attribute Byte Encoding

The color value is POKEd into every attribute cell. The attribute byte encodes: bit 7 = FLASH, bit 6 = BRIGHT, bits 5–3 = PAPER colour (0–7), bits 2–0 = INK colour (0–7). Setting all 768 attribute cells to the same value means a uniform colour scheme fills the screen, which interacts visibly with whatever pixel pattern the display file byte produces.

Key BASIC Idioms

• Input validation by re-entry: Lines 60 and 80 use IF … THEN GO TO to re-prompt when the value is out of range, a standard BASIC guard pattern.
• Busy-wait keypress loop: Line 160 uses IF INKEY$="" THEN GO TO 160 — a polling loop that spins until any key is held down. Note that unlike the PAUSE 0/INKEY$ idiom, this will retrigger immediately if a key is already held when the line is reached.
• Multi-expression PRINT AT: Line 140 chains multiple AT clauses in a single PRINT statement, avoiding separate PRINT AT calls for efficiency.
• Loop variable reuse: Both POKE loops at lines 100 and 120 reuse the variable x, which is acceptable because the first loop has fully completed before the second begins.

Notable Techniques

The program intentionally overwrites all display memory before issuing any PRINT statement. This means the PRINT AT on line 140 renders text on top of the already-POKEd pixel and attribute values. The text will inherit whatever color was chosen for the attribute cells surrounding those character positions, vividly illustrating the relationship between the attribute file and the display file.

Restarting at line 10 (rather than a lower line) ensures that INK, PAPER, BORDER, and CLS are re-applied every cycle, giving the user a clean input prompt regardless of what was previously POKEd to the screen.

Potential Issues

• The busy-wait at line 160 polls INKEY$ continuously. If the key used to confirm the INPUT prompts (ENTER) has not been fully released before line 160 is reached, the loop exits immediately without the user seeing the display. A PAUSE 1 or key-release check before line 160 would make the behaviour more predictable.
• The variable names byte and color are multi-character, so the interpreter stores only the first two characters as the variable identifier (by and co respectively in terms of internal representation). This is not a bug but is worth noting for readability: any variable starting with the same two letters would collide.

Content

Appears On

Fort Worth TS2068 Club Library Tape

This tape is a compilation of programs from user group members (Robert Burton, David Baulch, Frank Bouldin, Chuck Dawson, Ryan

Timex Sinclair Public Domain Library Tape 2001

One of a series of library tapes. Programs on these tapes were renamed to a number series. This tape contained

Related Products

Related Articles

Related Content

Image Gallery

Source Code

   10 REM Screen layout
   11 REM examination
   12 REM 
   20 REM Set up
   21 REM 
   30 INK 0: PAPER 7: BORDER 7: FLASH 0: BRIGHT 0: CLS 
   40 REM 
   41 REM Get values
   42 REM 
   50 INPUT "Enter byte (0>255) ";byte
   60 IF byte<0 OR byte>255 THEN GO TO 50
   70 INPUT "Enter color (0>255) ";color
   80 IF color<0 OR color>255 THEN GO TO 70
   90 REM 
   91 REM Alter Screen
   92 REM 
  100 FOR x=16384 TO 22527: POKE x,byte: NEXT x
  110 REM 
  111 REM Alter Colors
  112 REM 
  120 FOR x=22528 TO 23295: POKE x,color: NEXT x
  130 REM 
  131 REM Display Values
  132 REM 
  140 PRINT AT 2,4;"Byte = ";byte;AT 6,4;"Color = ";color;AT 10,4;"Press a key to alter"
  150 REM 
  151 REM Wait for keypress
  152 REM 
  160 IF INKEY$="" THEN GO TO 160
  170 GO TO 10

Note: Type-in program listings on this website use ZMAKEBAS notation for graphics characters.