---
title: "Screen Layout Examination"
id: 56315
type: "computer_media"
slug: "screen-layout-examination"
url: "http://localhost/computer_media/screen-layout-examination/"
markdown_url: "http://localhost/computer_media/screen-layout-examination.md"
published_at: "2024-08-04T10:49:54+00:00"
modified_at: "2026-03-30T21:45:17+00:00"
author: "David Anderson"
featured_image:
  url: "http://localhost/wp-content/uploads/2024/08/SCR-20240804-khqq.png"
excerpt: "Enter any byte value and watch it fill every pixel and every colour cell on screen — a hands-on tool for understanding display memory layout."
category:
  - name: "Archived Media"
    slug: "archived-media"
    taxonomy: "category"
    url: "http://localhost/category/archived-media/"
post_tag:
  - name: "Downloadable"
    slug: "downloadable"
    taxonomy: "post_tag"
    url: "http://localhost/tag/downloadable/"
  - name: "TS 2068"
    slug: "ts2068"
    taxonomy: "post_tag"
    url: "http://localhost/tag/ts2068/"
model:
  - name: "Timex/Sinclair 2068"
    slug: "ts-2068"
    taxonomy: "model"
    url: "http://localhost/model/ts-2068/"
genre:
  - name: "Demo"
    slug: "demo"
    taxonomy: "genre"
    url: "http://localhost/type/demo/"
media_contents:
  - id: 56277
    title: "Timex Sinclair Public Domain Library Tape 2001"
    type: "computer_media"
    url: "http://localhost/computer_media/timex-sinclair-public-domain-library-tape-2001/"
  - id: 60550
    title: "Fort Worth TS2068 Club Library Tape"
    type: "computer_media"
    url: "http://localhost/computer_media/fort-worth-ts2068-club-library-tape/"
media_type: "Program"
download_url: "https://archive.org/download/timex-sinclair-software-archive/Screen%20Layout%20Examination%20%28198x%29%28TS2068%29%28US%29%28Program%29.zip"
mediadate: "198x"
images:
  - url: "http://localhost/wp-content/uploads/2024/08/SCR-20240804-khqq.png"
media_type_tags: "Demo"
---

# 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:

| Region | Start | End | Size | Purpose |
| --- | --- | --- | --- | --- |
| Display file | 16384 | 22527 | 6144 bytes | Pixel bitmap (192×256 pixels) |
| Attribute file | 22528 | 23295 | 768 bytes | Colour/flash/bright per 8×8 cell |

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.

## 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
```