World Geography

World Geography is an educational quiz program that tests knowledge of countries, islands, continents, oceans, and seas by flashing their locations on a world map displayed using ZX81 block graphics. The program operates in two modes: a review mode (option 1) that names each location while highlighting it, and an identify mode (option 2) that prompts the player to type the name from memory. A machine code routine stored in REM line 1 handles smooth scrolling of the map display, accessed via USR calls to calculated addresses based on the DFILE pointer at address 16396/16397. Coordinates for each of the 19 countries/islands or 17 geographic features are packed as two-byte entries in a string array P$, with screen positions encoded as raw character codes including values above 128 that are sign-extended by subtracting 256 to give signed offsets.

---

Program Analysis

Program Structure

The program is divided into several logical phases:

1. Initialisation (lines 1–40): A machine code routine is embedded in REM line 1. Key system addresses are computed: DF (display file address), GET (a custom keypress-reading routine offset), and M (the fixed address 16540 for the map scroll routine).
2. Mode selection (lines 100–210): The player chooses Review (1) or Identify (2), then chooses Countries/Islands (A) or Continents/Oceans/Seas (B).
3. Data loading (lines 1000–1110 and 2000–2100): Two parallel string arrays, N$ (names) and P$ (map positions), are built from packed string literals A$ using fixed-stride slicing.
4. Quiz loop (lines 5000–5520): Items are presented in random non-repeating order. The map is scrolled to the correct position, the location is flashed, and in Identify mode the player’s typed answer is checked.

Machine Code Usage

REM line 1 contains a substantial Z80 machine code payload. It is invoked in three distinct ways:

• USR GET — reads the current keypress and stores it in G$; returns 0 (false) if no key is pressed, enabling the polling loops at lines 112 and 200.
• USR M (address 16540) — scrolls the map one step; called in loops at lines 5012–5014, 5080–5100, and 5130–5134 to pan horizontally and vertically.
• USR 16875 at line 5140 — performs a separate map operation (likely resetting or returning a status value used by the flash routine).

The address GET is dynamically computed as DF - 289, tying the routine’s entry point to the current display file location. This is a common ZX81 technique to make code position-independent relative to the BASIC/display file boundary.

Coordinate Encoding

Map positions are stored in P$(A) as two raw bytes. The first byte (accessed via CODE P$(D)) encodes the horizontal offset; the second byte (CODE P$(D,2)) encodes the vertical offset Y. Values above 128 are treated as negative by subtracting 256 at line 5065, giving a signed range of approximately −128 to +127. This compact two-byte encoding avoids the overhead of storing integer variables for each location.

Data Packing

Names and coordinates are stored in long string literals A$ and sliced into fixed-length arrays using a stride loop. For countries/islands, LN=17 (name length) and NN=19 (count); for geographic features, LN=18 and NN=17. The slice expression N$(A)=A$(1+LN*(A-1) TO ) relies on ZX81 string-array assignment truncating to the declared field width, neatly packing each name. CHR$ calls are used for characters that cannot be typed directly in the source editor.

Randomisation and Non-Repeating Order

A tracking array T$(NN) is used at lines 5016–5034 to avoid repeating items within a round. Each element starts as a null character (code 0); when an item is shown, T$(D) is set to "1". The test IF CODE T$(D) THEN GOTO 5030 re-draws a random index until an unseen one is found. When CT=NN the round restarts, re-dimensioning T$ implicitly resets it (via GOTO 5000 which re-executes DIM T$).

Map Flashing Technique

Lines 5190–5240 implement a flash effect at the map location. The display file address B is computed from DF, the row offset A (derived from Y), and a column of 33 characters per row. The character at B is read into F; a “complement” value C is computed as either 23 or 23+128 depending on whether the original character has bit 7 set (i.e., is already inverse). The cell is then toggled between C and F fifteen times in a short delay loop, producing a visible flash.

Scrolling Control

The POKE sequence at lines 5000–5004 initialises the scroll state. POKE 16522 at lines 5070 and 5120 sets the scroll direction: value 34 = right, 36 = left (or similar encoding). The number of scroll steps is computed from the difference between the current and target coordinates, with wrap-around logic handling the case where going the other way around the map is shorter (the B>0 AND B<42 OR B<-42 condition at line 5120).

Notable BASIC Idioms

• IF USR M THEN REM — calls machine code but discards any return value; the REM acts as a no-op target. The IF condition is always evaluated, ensuring the USR call executes every iteration.
• FOR A=1 TO ABS(...) with empty body — used as a delay loop and also as a counted scroll loop, with the loop variable serving double duty.
• LET G$=G$( TO USR GET) at line 5260 — uses the machine code return value as a string slice length to extract exactly the typed portion of the padded answer string.
• Lines 5010–5014 call USR M four times per iteration over eight iterations (32 total) — likely performing an initial map setup or centering scroll before the quiz begins.

Possible Anomalies

• Line 5180 computes B=DF+412+33*A*(Y<1 OR Y>26): the multiplication by a boolean condition means that when Y is out of range 1–26, B jumps by 33×A, which could point outside valid display memory. This may be intentional (off-map items skip the flash) or a latent boundary issue.
• The coordinate data in P$ is built from raw character codes embedded in string literals, some via CHR$ and some as literal block-graphic escape sequences. The mixing of methods makes the data difficult to audit without running the code.
• REM line 2 contains what appears to be a garbled BASIC listing artifact — its tokens do not form valid statements and are likely the residue of a previously different line or an encoding artifact from the file format.