Traffic

Traffic is a TS 2068 animation program that scrolls either road vehicles or a train across two rows of the display using string-rotation techniques. The program uses 21 user-defined graphics (UDGs) loaded via machine-code POKEs to memory address 65368, with the DATA statements supplying the pixel patterns for cars, trucks, or train carriages. Two animation modes are supported: leftward scrolling (lines 30–110) rotates strings by shifting the first character to the end, while rightward scrolling (lines 120–200) takes the last character and prepends it. The user can select the subject (traffic or train), scrolling direction (left or right), and a PAUSE value to control animation speed; pressing Enter (CODE INKEY$ = 13) returns to the main menu.

---

Program Structure

The program is organized into distinct functional blocks, with the main entry point at line 740 rather than the top of the listing. Lines 30–110 handle leftward scrolling, lines 120–200 handle rightward scrolling, and lines 210–500 contain the UDG loader subroutine and cars/trucks DATA. Lines 510–730 hold the train scene definition and its DATA. The main menu and initialization logic sits at lines 740–820.

1. Lines 740–820: Initialization, menu, UDG loading dispatch, direction routing
2. Lines 240–260: Generic UDG POKE subroutine (“poker util”)
3. Lines 270–500: Cars and trucks scene setup and pixel data
4. Lines 510–730: Train scene setup and pixel data
5. Lines 30–110: Left-scroll animation loop
6. Lines 120–200: Right-scroll animation loop

UDG Loading Mechanism

The subroutine at line 250 reads a byte count from DATA into y, then POKEs successive bytes starting at address 65368, which is the UDG area. This is a compact, data-driven approach to defining custom characters entirely from BASIC without separate machine code routines. The variable y does double duty: it holds the count initially, then is overwritten by each data byte during the POKE loop. The two scenes (traffic and train) use separate RESTORE targets — RESTORE (defaulting to line 300) for traffic and RESTORE 540 for the train — so the same loader subroutine can serve both.

String-Rotation Animation

The scrolling effect is implemented purely through string manipulation rather than any display hardware trick. Two strings are animated simultaneously: a road/track string (c$ or f$) and a vehicle body string (a$), both 32 characters wide to fill a display row.

• Left scroll (lines 50–60): Takes the first character of each string and appends it to the right end — LET e$=c$(1): LET c$=c$(2 TO )+e$ — producing a circular left shift.
• Right scroll (lines 140–150): Takes the last character of each string and prepends it — LET g$=f$(32): LET f$=g$+f$ — producing a circular right shift. Note that this incorrectly builds f$ as g$+f$ rather than g$+f$(1 TO 31), so the string grows beyond 32 characters each iteration, which is a bug.

Both rows are printed together with a single PRINT AT 0,0 statement, keeping the two animation layers in sync.

Control Flow and Loop Design

Each animation loop runs a FOR b=1 TO 32 counter, but line 90 (and 180) reset b to 1 when it reaches 32, creating an infinite loop within the FOR...NEXT structure. This is an unusual idiom — the NEXT b at lines 110 and 200 is nominally reached but immediately loops back via the reassignment, effectively turning a finite FOR loop into an infinite one. Pressing Enter (detected as CODE INKEY$=13) breaks out to the main menu at line 740.

DATA Anomalies

The DATA statements (lines 300–500 and 550–730) mix lowercase y and uppercase Y as filler values within the pixel data. In Spectrum BASIC, both evaluate to the current value of the numeric variable y at the time READ is executed. Since y is set to 1 or 2 by the menu logic and then overwritten during the POKE loop, rows containing y/Y mid-sequence will read whatever value y last held, which changes on each iteration. This appears to be intentional shorthand for a common byte value (likely 0 or 255) but is fragile and dependent on loop state — a potential source of subtle graphic errors if the DATA ordering changes.

The train DATA at line 700 also contains PI as a DATA value, which evaluates to approximately 3.14159 and will be truncated to 3 when POKEd. This is almost certainly a typo for a numeric literal.

Key Variables

Variable	Purpose
a$	32-char vehicle body string (both scenes)
c$	32-char road/track string for left-scroll
f$	32-char road/track string for right-scroll
n	PAUSE duration controlling animation speed
rout	Scene selection (1=traffic, 2=train)
d$	Direction selection (“R”/”r” or other)
y	UDG byte count / loop data value (overloaded)
b	Animation loop counter (artificially kept infinite)

Notable Techniques and Bugs

• The UDG loader subroutine is reused for both scenes by changing the RESTORE target before calling it, avoiding code duplication.
• The right-scroll string growth bug (line 140: f$=g$+f$ without trimming) will cause the string to exceed 32 characters after the first iteration, likely producing a string-length error after a short time.
• The same bug appears at line 150 for a$: a$=b$+a$ without truncation.
• Using y as both the DATA sentinel and a recurring placeholder within DATA is a memory-saving trick but makes the code difficult to maintain and error-prone.
• Line 830 uses SAVE "traffic" LINE 1, directing auto-run to line 1 (the REM), which means the program does not auto-start at the intended entry point (line 740) when loaded from tape.