Driver

Driver is a simple 3D road-driving game in which the player steers a car (drawn with four UDG characters) along a perspective road rendered using PLOT and DRAW commands. The road is represented by two diagonal lines converging toward the top of the screen, and the player uses keys “5” and “8” to steer left and right while random drift is added each frame via RND. Collision detection checks whether the player position variable p falls outside the road boundaries (108–150); a crash triggers a crash sound sequence using ascending BEEP tones and flashes the car graphic in red. The four UDGs (characters A–D) are loaded from DATA statements at startup, with each UDG occupying 8 bytes POKEd via USR.

---

Program Analysis

Program Structure

The program is organized into a main loop and two subroutines, with a linear initialization sequence at startup:

1. Line 20 calls the UDG-loading subroutine (280–300).
2. Line 30 calls the game-reset subroutine (230–270), which sets the border, paper, ink, clears the screen, resets p and sc, and draws the top road strip.
3. Line 40 draws the player’s car using four UDG characters at a fixed screen position.
4. Lines 50–130 form the main game loop: collision check, draw road lines, erase road lines (OVER 1), update position, add drift, increment score, and loop.
5. Lines 150–200 handle the crash sequence: draw final road lines without erasing, flash the car, play a sound effect, display the score, and prompt for replay.

Road Rendering Technique

The road perspective is drawn each frame using two PLOT/DRAW pairs anchored at the player’s position p on the bottom of the screen (y=159) and converging upward. Line 60 draws the left edge and line 70 the right edge. Lines 80–90 immediately redraw the same lines with OVER 1, which XORs the pixels back off, effectively erasing them before the next frame. This avoids a CLS flicker and produces a simple animation loop.

UDG Setup

The subroutine at lines 280–300 reads 32 bytes from DATA statements (lines 310–340) and POKEs them into the UDG area using POKE USR "a"+a,u. This defines four UDGs (A, B, C, D) of 8 bytes each, forming a 2×2 tile car graphic. The variable name u is reused here as the READ target despite also appearing as a literal character inside the string USR "a"; the DATA values labeled u in lines 310–320 appear to be placeholder tokens in the listing rather than the variable, suggesting a listing transcription artifact.

Player Input and Drift

Line 100 updates p based on INKEY$: pressing “5” moves left (subtracts 4) and pressing “8” moves right (adds 4), using the Boolean arithmetic idiom 4*(INKEY$="5") which evaluates to 4 when true and 0 when false. Line 110 adds a random perturbation of −10 to +9 each frame via INT(RND*20)-10, simulating road curvature or wind and making the game progressively harder to control.

Collision Detection

The boundary check at line 50 is a simple numeric range test on p. If p is less than 108 or greater than 150, the car is considered off-road and execution branches to the crash handler at line 150. The road boundaries are fixed constants; they do not widen or narrow dynamically.

Crash Sequence

On a crash, lines 150–160 draw the final road lines (without erasing them, leaving the position visible). Line 170 reprints the car UDGs with FLASH 1 and INK 2 (red), providing a visual crash indicator. Line 180 plays a rising-pitch sound effect using a FOR loop with two BEEP calls per iteration — one longer and one very short — over pitches 0 to 50. Line 190 prints the score, and line 200 uses INPUT LINE to wait for ENTER before looping back to reset.

Notable Anomalies

• Line 140 (STOP) and line 210 (GO TO 50) are unreachable dead code; the main loop at line 130 goes directly to line 50 and the crash handler at line 200 goes directly to line 30.
• The delay loop at line 200 (FOR z=1 TO 120:NEXT z) runs immediately after the INPUT statement — because INPUT LINE already blocks until ENTER is pressed, this delay executes after the key is pressed rather than before, making it a post-confirmation pause rather than an input throttle.
• The DATA values at lines 310–320 contain the token u, which in the context of the READ statement would attempt to read a variable rather than a numeric literal. This is likely a transcription issue in the listing where the actual pixel byte values were lost.
• The car graphic is always drawn at a fixed screen position (AT 15,15) regardless of p, meaning the car appears stationary on screen while the road moves — a perspective illusion consistent with many simple driving games of this style.

Variable Summary

Variable	Purpose
p	Horizontal road position (128 = center start)
sc	Score counter, incremented each frame
a	Loop counter for UDG loading and crash BEEP
u	READ target for UDG byte data
z	Post-input delay loop counter
a$	INPUT LINE buffer (contents ignored)