Quiz Maker

This is a quiz-authoring and quiz-taking program published in Syntax Quarterly (Spring 1983), written by Dale F. Lipinski. It allows the user to build a quiz with up to three formats — multiple choice (up to 9 options), true/false, or direct answer — storing all text in a single packed string array A$ with offset pointers held in a 2D numeric array A(). Memory is carefully budgeted before entry begins: line 230 uses PEEK on system variables 16386/16387 (RAMTOP) and 16412/16413 (E_LINE) to calculate available character storage E, which is then reported as total and per-question averages. The program also supports optional wrong-answer explanations, records a running score, and offers to SAVE the completed quiz back to tape at the end.

---

Program Analysis

Program Structure

The program divides into three broad phases: configuration (lines 10–280), quiz entry (lines 290–760), and quiz delivery (lines 770–1240). A final block at lines 1250–1270 handles the auto-run SAVE of the shell program.

1. Configuration (10–280): Collects quiz type (C$), number of questions (A), explanation flag (D$), and number of choices (B for multiple choice). Computes available string space E via PEEK, then dimensions both arrays.
2. Quiz Entry (290–760): For each question, stores question text, answer, optional explanation, and (for multiple choice) each lettered choice into the packed string A$, recording segment offsets in the numeric array A().
3. Quiz Delivery (770–1240): Prompts for title and player name, then loops through all questions, checks answers, updates score S, and optionally displays explanations for wrong answers.

Memory Management via PEEK

Line 230 is the most technically notable line in the program:

LET E=(PEEK 16386-PEEK 16412+256*(PEEK 16387-PEEK 16413)-50)-1300-(D*(A+1)*5)

This calculates free RAM by subtracting the E_LINE pointer (16412/16413, the current end of BASIC workspace) from RAMTOP (16386/16387), then subtracts an overhead estimate of 1300 bytes plus the space the two arrays will themselves occupy (D*(A+1)*5 bytes, since each numeric array element takes 5 bytes). The result E is used to dimension A$ at line 299, ensuring the string buffer fits in available memory. This is a practical, if fragile, approach — the constants 50 and 1300 are empirical guesses at interpreter overhead.

Packed String / Pointer Array Idiom

All text (questions, answers, explanations, choices) is stored in a single string A$ dimensioned to E characters. Segment boundaries are tracked in a 2D numeric array A(A+1, D) where each row corresponds to one question and each column holds a character offset:

Column	Meaning
A(F,1)	Start of question text
A(F,2)	Start of answer
A(F,3)	Start of explanation
A(F,4) … A(F,D)	Start of each multiple-choice option
A(F+1,1)	End marker (= A(F,D))

Retrieval during the quiz phase slices A$ with expressions like A$(A(C,1) TO A(C,2)-1). This is an efficient, if error-prone, manual memory management technique for a BASIC environment lacking dynamic data structures.

Answer Encoding for Multiple Choice

Line 705 prepends each choice with CHR$ (C+28), mapping choice numbers 1–9 to ZX81 character codes 29–37 (the inverse-video digits 1–9). Line 735 then checks whether the stored answer text matches the current choice text; if so, it overwrites the first byte of the answer field with that same encoded character. At quiz time (line 955), for multiple-choice mode, K$ is set to just this single encoded byte, so comparison at line 1020 (K$=F$) works correctly without the user knowing about the encoding.

Input Validation Pattern

Throughout the program, single-character inputs are validated by testing CODE against known ZX81 character codes. For example:

• Line 70: IF CODE C$<=28 OR CODE C$>=32 THEN GOTO 40 — accepts only codes 29, 30, 31 (inverse “1”, “2”, “3”).
• Line 140: IF CODE D$<=27 OR CODE D$>=30 — accepts codes 28 or 29 (inverse “0” or “1”).
• Line 270: IF CODE E$<=27 OR CODE E$>=29 — accepts only code 28 (inverse “0”).

This relies on ZX81’s keyboard INPUT returning inverse-video digit characters rather than plain ASCII, a platform-specific behavior hobbyists exploited for simple menu selection.

Notable Idiom: B$ as a Reusable Prompt Banner

Line 30 defines B$ as a long string of block-graphic characters (▀ tiles) followed by the inverse-video text “ENTER ANSWER”. This is PRINTed at the bottom of most input screens as a visual prompt bar. Slicing B$( TO 32) at line 950 prints only the graphic portion, omitting the text label where it would be inappropriate.

Bugs and Anomalies

• Line 530 condition is always false: IF CODE D$<=28 OR CODE D$>=3 — since CODE D$ is always ≥ 3 for any non-empty string, this condition is always true and execution never falls through to line 540 (the explanation-entry block). The explanation feature is therefore broken; H$ retains whatever value was set at line 160 (a single space). The correct test was probably >=30 (matching the validation at line 140).
• Line 410/420/520/620/730 off-by-one: Segments are stored as A$(A(F,1) TO A(F,1)+H) where H=LEN E$, which copies H+1 characters (an extra trailing character bleeds into the next segment). This is compensated for at retrieval time by the -1 in slice end indices, but it wastes one byte per segment.
• Line 1170 comma after TAB 0: PRINT "QUIZ IS COMPLETE. THANK YOU",J$;TAB 0,,... — the comma after TAB 0 produces an extra blank line, which is cosmetic rather than functional.
• Line 1220 loops to 830 instead of 40: After a wrong answer at the save prompt, execution returns to line 830 (ask for player name) rather than restarting the whole quiz setup, meaning a second run reuses the existing A() and A$() data correctly but skips re-dimensioning.

FAST Mode

Line 20 invokes FAST mode for the entire program, suppressing the display refresh and significantly speeding up string operations during quiz entry. This is appropriate given the volume of string slicing and array writes performed during the authoring phase.