Exercise and Calories

This program calculates calories burned during physical exercise activities and estimates the corresponding weight loss. It stores activity names as strings in a two-dimensional array and exploits the ZX81/TS1000 convention of using variable names that match activity strings, so that VAL A$(N) retrieves the calorie-per-hour value stored in the identically-named numeric variable (e.g., LET JOGGING=560). Up to 20 activities are supported, each with a name up to 12 characters and an associated number of hours. The total calorie count is converted to kilograms and pounds of weight loss using a 7000-calories-per-kilogram approximation, with results displayed in a right-aligned tabular format using TAB arithmetic.

---

Program Analysis

Program Structure

The program is divided into clearly labelled subroutines, with a main flow that proceeds through initialisation, a title/list display, user input, calculation, and output:

1. Line 8 / GOSUB 500 — initialises the calorie-per-hour constants and resets the accumulator C.
2. Line 10 / GOSUB 1000 — displays the title screen and activity list, then waits for ENTER.
3. Lines 15–90 — dimensions arrays and collects user input (activity names and hours).
4. Lines 91–200 — main output loop: prints the activity table, totals, and weight-loss estimate; handles “go again” logic.
5. Lines 500–800 — value-assignment subroutine for the 20 named activity variables.
6. Lines 1000–1220 — introductory display subroutine.
7. Lines 2000–2020 — per-activity formatting subroutine (converts calorie value to string X$).
8. Lines 3000–3030 — total formatting subroutine (converts accumulated total to string Y$).

The VAL A$(N) Trick

The most technically interesting feature is the calorie lookup mechanism at lines 110 and 2005:

LET C=C+(VAL A$(N)*H(N))

On the ZX81/TS1000, VAL evaluates a string as a BASIC expression. Because the activity names stored in A$(N) (e.g., "JOGGING") are also the names of numeric variables assigned in the subroutine at lines 500–700, VAL A$(N) effectively dereferences the activity name as a variable, returning its calorie-per-hour value. This is a compact and clever indirect-variable lookup that avoids any need for a lookup table or IF/THEN chain.

Activity Variables

Variable	Calories/Hour
BADMINTON	300
BASEBALL	360
BASKETBALL	500
BICYCLING	400
BOWLING	400
DANCING	300
FOOTBALL	550
GOLF	250
HANDBALL	600
JOGGING	560
RACQUETBALL	600
RUNNING	900
SITTING	100
SKATING	400
SKIING	600
SOCCER	550
TABLE TENNIS	230
TENNIS	440
VOLLEYBALL	350
WALKING	300

Note that TABLE TENNIS contains a space, which is valid as a ZX81 variable name only if typed as a multi-word name — the tokeniser treats it as a single variable on that platform.

Array Dimensions and Input

DIM A$(20,12) allocates a 20-row, 12-character string array for activity names. This imposes a hard 12-character limit; “RACQUETBALL” is exactly 11 characters, which fits, but any activity name longer than 12 characters would be silently truncated. DIM H(20) stores the corresponding hours as a numeric array. The program supports a maximum of 20 activities per session.

Right-Aligned Column Formatting

The program right-aligns calorie figures in a column at position T (set to 24) using the expression TAB T-LEN X$. The per-line calorie value is first converted to a string in subroutine 2000 and stored in X$; the total is handled analogously in subroutine 3000 using Y$. This is a standard ZX81 idiom for producing tidy tabular output without fixed-width formatting.

Weight Loss Calculation

The weight-loss estimate at line 140 uses the approximation of 7000 calories per kilogram of body fat (C/7000 for kg), then divides by 2.2 to convert to pounds. This figure (7000 kcal/kg) is a common rough estimate used in popular literature of the era; the more precise clinical value is approximately 7700 kcal/kg.

Input Wait Idiom

Line 1200 uses the busy-loop pattern IF INKEY$="" THEN GOTO 1200 to pause until a key is pressed. This is a standard ZX81 idiom. The “go again” logic at lines 180–200 re-enters at line 8, which re-runs the value-assignment subroutine (resetting C to 0 and re-declaring all activity variables) before presenting the activity list again.

Bugs and Anomalies

• Line 2000 has a mismatched delimiter: REM **LINE UP ROUTINE" uses a closing quote instead of the expected asterisk, though this is harmless since it is inside a REM statement.
• Line 110 accumulates C using VAL A$(N)*H(N), which is the same expression computed in GOSUB 2000 at line 2005. The subroutine result is discarded for accumulation purposes — the subroutine only provides the formatted string X$ for display. This is correct behaviour but slightly redundant.
• The introductory key-wait at line 1200 waits for any key to be held down (INKEY$ non-empty) rather than detecting a fresh keypress, meaning it will also advance if the user is still holding a key from a previous input.
• If the user enters an activity name that does not match any of the 20 predefined variables, VAL A$(N) will cause an error (variable not found), crashing the program.