Byte Mapped Scroll

Byte Mapped Scroll is a machine code utility that enables smooth, byte-aligned scrolling of arbitrary rectangular regions of the TS2068/ZX screen. The program POKEs 232 bytes of Z80 machine code above RAMTOP (starting at address 65135) and provides routines for scrolling up or down, with or without wrap-around, accessed via RANDOMIZE USR calls. Users can interactively define the scroll region by specifying top line, bottom line, left column, and right column coordinates, then test the scroll behavior and optionally SAVE the machine code block for use in their own programs. The code block occupies addresses 65135–65366, and the BASIC shell patches key parameter addresses (such as 65139, 65140, 65158, 65187, 65288, 65337, 65345, 65354, and 65362) with the computed scroll region geometry before execution. A built-in demonstration section shows three scroll modes using PLOT/DRAW graphics and repeated PRINT output.

---

Program Structure

The program is organized into several functional segments:

• Lines 1–6: Setup — clears memory above address 65134, displays a loading message, and calls the machine code loader subroutine at line 1000.
• Line 10–12: Main menu — offers Demonstration, Develop/Test/Save, or Save Program options.
• Lines 14–50: Interactive scroll region definition and code-usage instructions.
• Lines 100–114: Subroutine to accept and validate scroll region parameters (top, bottom, left, right), then POKE the computed values into the machine code.
• Lines 1000–1016: Machine code loader — READs DATA bytes and POKEs them into RAM above RAMTOP (65135–65366).
• Lines 1008–1014: DATA statements containing the Z80 machine code bytes.
• Line 1016: DATA containing five target addresses used during parameter patching in line 108.
• Lines 9100–9116: Demonstration #1 — scroll up with wrap-around, using PLOT/DRAW graphics.
• Lines 9200–9209: Demonstration #2 — interactive up/down scroll without wrap, controlled by arrow keys (6 and 7).
• Lines 9300–9314: Demonstration #3 / test scroll subroutine used also from line 28.
• Line 9999: Saves the BASIC program with auto-run.

Machine Code Layout

The machine code block is POKEd into addresses 65135–65366. Lines 1002–1006 load it in two passes with an intentional zero-fill gap:

• 65135–65217: First DATA block (83 bytes, loaded by line 1002).
• 65218–65281: Zero-filled region (64 bytes, line 1004) — likely used as workspace or padding.
• 65282–65366: Second DATA block (85 bytes, loaded by line 1006).

The four USR entry points exposed to the user are:

Address	Function
65203	Initialize wrap-around (called before scroll loop starts)
65138	Wrap-around terminator (called after scroll loop)
65333	Scroll up one step
65350	Scroll down one step
65135	Non-wrap terminator / stop condition

Parameter Patching

Rather than passing parameters through registers, the BASIC code directly patches addresses inside the machine code block before calling it. Line 108 uses a RESTORE 1016 and a FOR/READ/POKE loop to write the bottom-line value (b-1) into five separate addresses within the code. Lines 110–112 compute and POKE additional parameters:

• 65158 and 65187: column count (cl), controlling loop width.
• 65345 and 65354: top line + 1 (y+1), controlling loop top boundary.
• 65139, 65140, 65287, 65288: high and low bytes of the starting screen address (co = 256*(y+1)+x).

The screen coordinate system used here is non-standard: lines are numbered 0–175 from bottom to top and columns 0–31 left to right. Line 108 converts the user-supplied column values by computing X = X + 8 and A = A + 1 - (X/8) to produce byte-aligned offsets.

Notable BASIC Idioms and Techniques

• PAUSE 0 / INKEY$ pattern: Used extensively (lines 10, 28, 48, 9116, 9313) for efficient keypress waiting without blocking indefinitely.
• CODE z$ comparison: Lines 20 and 24 use CODE z$=121 (ASCII ‘y’) instead of z$="y", a common idiom for case-sensitive single-character input testing.
• POKE 23617,236: In line 100, this POKEs the system variable that controls the input line editor, likely setting a custom prompt width or suppressing the lower-screen input area scrolling.
• RESTORE with a specific line: Line 108 uses RESTORE 1016 to re-read only the address DATA on line 1016, separately from the machine code DATA on lines 1008–1014.
• Variable reuse for USR addresses: Variables s, w, and z hold USR entry-point addresses selected based on scroll direction and wrap mode, avoiding hard-coded calls throughout the test loop.
• RANDOMIZE USR 2217: Line 50 calls address 2217 before the SAVE — this is a well-known technique to invoke the ROM tape-save header routine directly.

Scroll Region Geometry

Line 110 computes cl = INT(a AND a <= (256-x)/8). This expression uses a Boolean result (0 or 1) as an arithmetic value: if a fits within the available byte width given the column offset, cl equals a; otherwise it is 0. This is an attempt at a clamping guard, though the logic is somewhat fragile — if a exceeds the bound, cl silently becomes 0 rather than clamping to the maximum legal value.

Demonstration Mode

The three demonstration programs illustrate the scroll routines in action. Demo #1 (lines 9105–9116) sets a scroll region covering most of the screen, draws a geometric pattern with PLOT/DRAW, and then loops on RANDOMIZE USR 65138 (wrap-around scroll) until a key is pressed. Demo #2 (lines 9200–9209) fills the screen with repeated text and allows the user to scroll up or down interactively using keys "7" and "6" respectively, testing for ENTER (CODE 13) to exit. Demo #3 / the test subroutine (lines 9300–9314) is also called from line 28 during the develop-and-test workflow.

Potential Issues

• Line 9200 prints the loop variable as N (uppercase) in NEXT N but defines it as n (lowercase) in the FOR — on most Sinclair BASICs these are treated as the same variable, so this is not a functional bug.
• The column-clamping logic in line 110 (described above) may produce a zero column count if parameters are near boundary values, causing silent failure rather than an error.
• Line 12 re-reads INKEY$ after PAUSE 0 has already consumed the keypress in line 10; if the user releases the key before line 12 is reached, the condition will be false and the program will fall through to the development path even if "3" was pressed. This is a minor timing-dependent bug.