Header Readers

Header Readers is a dual-mode tape header analysis utility that reads and decodes the metadata blocks written at the start of tape-saved files. The program offers two operating modes: a streaming list mode (lines 10–270) that continuously reads and displays headers one after another, and a detailed single-header mode (lines 500–950) that decodes each field individually including program area size, variable area size, auto-start line, array variable names, and starting addresses. Both modes rely on short machine code routines POKEd into RAM at address 30000 (or 29957) to interface directly with the tape hardware. The list mode encodes its machine code as a space-delimited decimal string in n$ and uses VAL slicing to extract and POKE each byte, while the 2068 mode READs its routine from DATA statements. A menu at line 1000 lets the user choose between the two modes at startup.

---

Program Structure

The listing is divided into three functional blocks, selected from a menu at line 1000:

1. Lines 10–270 — Streaming list mode: continuously reads tape headers and prints a compact table showing filename, length, and type remarks.
2. Lines 500–950 — Single-header detail mode: reads one header at a time and decodes every field with descriptive labels, with an option to COPY the output or loop for another header.
3. Lines 960–990 — A raw hex/decimal dump of the 17 bytes stored from address 30001, reachable from the detail mode flow (after line 900) but never explicitly branched to from the menu.

The entry point is line 1000, which presents a two-option menu. RUN on line 1040 restarts the whole program if neither option is chosen. Line 9900 contains a SAVE command to preserve the program.

Machine Code Injection — List Mode

Lines 40–60 install a machine code routine at address 30000. The bytes are encoded as a space-delimited decimal string in n$. The loop at line 60 iterates 16 times, each iteration calling VAL n$( TO PI) — using PI (≈3.14159) as the upper bound of a string slice, which VAL truncates to 3, effectively reading the first three characters of the remaining string — and then advances n$ forward by 4 characters with n$=a$(4 TO ). Note the reference to a$ here when the variable was named n$, which is a bug: the slice should read n$(4 TO ), so the loop as written will either error or produce incorrect POKEs depending on the value of a$ at runtime.

The DEF FN p(x) at line 40 also establishes p=30016 as a base pointer into the header buffer, used throughout lines 130–240 to PEEK decoded header fields.

Machine Code Injection — Detail Mode

Lines 510–580 use READ/DATA to POKE 44 bytes into addresses 29957–30000. The routine is invoked via RANDOMIZE USR 29957 at line 630. After the call, the decoded header byte at address 30001 holds the file type, and addresses 30002–30017 hold the filename and parameter fields.

Line 540 contains a DATA value of c (an unquoted variable reference) and NOT PI (which evaluates to 0) mixed with numeric literals. The c reference is suspicious — it would be read as the current value of the variable c during the FOR/READ loop, which is the loop control variable itself. This is almost certainly a typo for a numeric literal (likely 0 or another byte value).

Line 610 does POKE 30001,4 to pre-initialize the type byte to an invalid value (4 = “not a header”), then calls CLEAR with no argument — on most implementations this resets variables, which would undo the carefully POKEd routine. This line appears anomalous.

Header Field Decoding

Both modes decode the standard 17-byte tape header format. The field layout assumed by the program is:

Offset	Field	Mode
+0	File type (0=BASIC, 1=Num Array, 2=Char Array, 3=Code)	Both
+1 to +10	Filename (10 chars)	Both
+11/+12	Data length (16-bit LE)	List mode
+12/+13	Data length (detail: 30012/30013)	Detail mode
+13/+14	Parameter 1 (start address or auto-start line)	List mode
+14/+15	Parameter 1 (detail: 30014/30015)	Detail mode
+15/+16	Parameter 2 (program area length for BASIC)	List mode
+16/+17	Parameter 2 (detail: 30016/30017)	Detail mode

Array Variable Name Decoding

In the list mode (lines 220–230), array variable names are recovered by reading the descriptor byte at p+14, dividing by 32 to get a “tier” value t, and computing the character code as s - 32*t + 96. If t=2 or t=6, a $ suffix is appended for string arrays.

In the detail mode (lines 850–860), the approach is different: for numeric arrays (type 1), two candidate names are computed as CHR$(PEEK 30015 - 64) and CHR$(PEEK 30015 - 32), joined with ” OR “; for character arrays (type 2), CHR$(PEEK 30015 - 128)+"$" and CHR$(PEEK 30015 - 96)+"$".

Notable BASIC Idioms

• NOT PI evaluates to 0 (since PI is non-zero, NOT returns 0), used pervasively as a readable zero literal.
• SGN PI evaluates to 1 (PI > 0), used as the FOR loop start value in line 60.
• VAL "number" in GO TO and CLEAR statements is a standard memory-saving idiom.
• TAB PI - LEN STR$ i at line 980 uses PI (≈3) to right-align single and double digit numbers in a column of width 3.
• PAUSE NOT PI (line 90) pauses for 0 frames, which combined with the subsequent keypress check acts as a wait-for-key idiom.
• Line 750 uses OVER 1 to overlay the filename a$ on an underline of underscores, producing an underlined appearance.

Bugs and Anomalies

• Line 60 — wrong variable name: The loop advances the string with n$=a$(4 TO ) but the string being built is n$. This should be n$=n$(4 TO ). As written, this will read from a$ (likely empty or undefined), corrupting the POKEd machine code bytes after the first iteration.
• Line 540 — bare c in DATA: The DATA statement contains the token c as a value. During the READ loop, c is the loop variable, so the byte POKEd will equal the current loop index rather than a fixed opcode. This is almost certainly a missing numeric literal.
• Line 610 — bare CLEAR: CLEAR without an argument resets all variables. This executes after POKEing machine code into RAM, but the machine code occupies fixed numeric addresses so survives CLEAR; however, it also resets the RAMTOP, which may reclaim the POKEd area depending on implementation.
• Line 900 — typo “Lenght”: The label prints as “Lenght:” instead of “Length:”.
• Line 960 — unreachable from menu: The raw byte dump block at lines 960–990 is never branched to from the main menu or from the detail mode’s normal flow at line 910 (which goes to the INPUT prompt). It appears to be dead code or a debug remnant.