Chiller

A disputed memory

Was a cross impossible to collect?

A 2022 comment on Lemon64 recalls a cross that could not be reached, and a crack that the player believed fixed it.⁸ In the copy studied, every cross can be taken and the whole journey out and back can be finished, although the game then loops back to the forest.

The three lowest crosses, in the graveyard, the ghetto, and the cinema on the way home, sit in the bottom two rows. The boy cannot stand lower than row 22 (move_sprite stops him at Y $E3), but the test for what he touches looks below and beside him, reaching rows 23 and 24 (probe_offset, $5145). So he takes each of the three by walking left along the ground.

Whether another release or a crack moved a cross, or whether some order of play can leave a player stuck, is not known.

Secret

Secret: enemies could once be killed, for points

In Chiller you cannot hurt an enemy, and there are no lives and no scrolling. Its code has all three, and a second sound player whose every write goes nowhere. None of it can be reached in play.

What	Where	Why it never runs
An enemy being hit, the enemy dying, points per enemy	`unused_shot_hit` `$CDC7`, `unused_kill_enemy` `$2F7B`, `add_score_for` `$CE6B`	nothing calls them
Lives: a starting count, take one, restart the screen	`$45ED`, `new_life` `$CAED`, `lose_life` `$CEDA`	called only from the code above
A scroller that moves the whole play area a cell at a time	`scroll_timer` `$C011`, `scroll_left` `$C412`	every screen sets its period to `$FF`, off
A sound player with a 56-note table	`unused_sound_player` `$CA80`, `$C300`	every sound-chip store in it is aimed at `$FFFF`
Fire putting a second sprite on top of the boy, facing his way, with a sound, and that sprite switched off when it hits the scenery	`switch_check` `$C7D4`, `sprite1_hit_scenery` `$C4FB`	the first works only on a screen with no jumping, and every screen has jumping; the second is switched off on every screen (`$45FE` = 0)
Screen-editor tools: a box drawer, a character plotter, fills	`unused_editor_tools` `$5198`, `unused_screen_tools` `$C038`	they call only each other

The code does not say how an enemy was hit; the first routine is named for a shot only because a shot is one possibility. unused_kill_enemy takes the enemy from the boy's last collision ($CF5E, $CF5F, written by sprite_touch), so it may once have been enough to touch an enemy. The row above may be a shot's beginning: fire puts a second sprite on the boy, facing his way, with a sound, and it vanishes when it hits the scenery. No code has been found that moves that sprite along, so nothing left in the game settles which.

The sound player was silenced without being removed. Its stores all point at the last byte of memory, so it still steps through its notes and makes no sound.

Secret

Secret: the magic crosses were once silver

Three of the first five levels carry a spare score line that is never shown. It says SILVER CROSSES where the game says MAGIC CROSSES.

Top: hud_cinema at $8E00, never copied to the screen. Bottom: hud_template at $8400, the one the game uses. Both drawn with the game's own letters.

Unfinished

Unfinished: a PRESS CTRL FOR MENU prompt that never appears

After GAME OVER the game still calls a routine meant to put PRESS CTRL FOR MENU on the bottom row. The routine reads the text, the screen and the colours, and writes nothing. It looks like a feature left out before release, with its prompt stubbed so it never shows.

The text at $574A, drawn here as it would have looked. The routine loops 19 times over LDA $574A,X, LDA $07CA,X, LDA $D805, LDA $DBCA,X: four loads and no store.

An older forest card is left behind the same way: card_forest_title ($5D0D) is still there, and its printer, $5E00, is never called.

Quirk

Quirk: an enemy that wears every sprite in the game

In the forest on the way home, one enemy never settles on a shape. The enemy plays 107 frames, and most of them are memory that was never meant to be a sprite: program code, the character set, and the boy's and the girl's own frames.

The enemy in slot 1 of the forest on the way home, stepping through its frames as enemy_move ($CCAB) does, in the colour the game gives it.

Each screen's settings name the first and last frame of each enemy, and the enemy steps from one to the other and starts again. On the way out, the forest's slot 1 runs from frame $88 to $8B. On the way home, the last frame is $F2 ($7523), so the enemy carries on past its own four frames, through the other enemies' shapes, into the code at $2A00, then the character set at $3000, and then the players' frames, before it starts again.

$7523 is the byte that the title screen's flicker writes to by mistake, in place of the video chip's $D023 (title_flicker, $7580). The flicker reads $D023, whose top four bits always read as 1, flips one bit, and stores the result, so whatever it writes is $F0 or more. The flicker runs on the title after every game over, so the enemy keeps its 107 frames however often you play. The copy studied holds $F2 there even before the first game, which suggests the game was saved from memory after its title had already run.

Odds and ends

Things the manual never told you

Small slips and leftovers in the code.

The enemies can speed up, but nobody has seen it. Each enemy slot has a count the code calls lives. A life here is one entrance: coming back on screen uses one, and leaving by an edge gives it back. When every slot has used up its count and all five are off the screen, a LEVEL counter goes up, is shown over the play area, and every enemy's movement and animation delays are halved. Edges refund a life and most slots start with 200, so play does not seem to get there. (level_up $2C19; speed_up $5681; counts at $CF76, from $45E7)
The jump sound should rise as he falls. The routine adds 5 to the frequency's low byte, but its carry test branches to the very next instruction. The high byte goes down by one every step regardless, and the pitch keeps dropping. (jump_pitch_fall $5518; the branch at $5524)
The title should flicker two colours. On the title after a game, the flicker routine is meant to change both multicolour registers, $D022 and $D023. Its second store goes to $7523, a byte in the last screen's settings, so only one flickers, and an enemy in the forest changes shape (above). (title_flicker $7580)

Open questions

What we're still unsure of

Whether the three NOPs at $7F06-$7F08, the length of one subroutine call, replaced an ending or something else. The surviving code does not say.
Whether the LEVEL counter can ever appear in real play. Nothing here proves it cannot.
Screenshots of the way back taken in an emulator show a stray fence patch on the cinema and a crosses counter reading 2S or 5S where the way to the house reads 05. They were taken with crosses moved beside the boy, so that may be the cause.
What $1000-$1FFF held. It repeats every 64 bytes like sprite data, but drawn as sprites it is noise.
Whether $4A90-$4AFF, shaped like more enemy paths, was ever used. No screen's settings point at it.
Which of the manual's ghouls, zombies, ghosts and bats is which shape.