Skip to content

Collect something worth the risk

  • Sinclair ZX Spectrum
  • Assembly

A safe route keeps the ship alive. A star gives the player a reason to leave it. We will let an object’s kind choose its picture and contact consequence.

The byte at record offset 2 now means kind: 0 is free, 1 is meteor, 2 is star. Nonzero still means occupied, so the existing pool search and occupied-object count keep their meaning. We have extended a concrete representation rather than adding a second pool.

The event table regains all 120 accepted entries: one hundred meteors and twenty stars. Events now contain X, speed, next delay, drift and kind. Their stride is five, so waves now adds the event index to HL five times. It copies the fifth field into a new byte, spawn_kind, and spawn stores that at offset 2 where it used to store 1. The object stride stays five because kind replaces active rather than adding another field.

Source · view and edit
ZX Spectrum
Companion file: assets.inc

The include line reads this editable data when you assemble. Keep it beside your source for a local build.

Edit the source, then assemble.

Edits are saved in this browser. Keep a downloaded copy of work you want to keep.

Focus the Spectrum screen to use the keyboard, or hold these buttons. Assemble again for a fresh machine.

Run the program to inspect it. Editing source does not change the running machine.

score
—
hull
—
wave
—
Read the active object records

These rows read the twenty-slot pool. Empty slots are omitted. The display samples RAM while the program runs, so values can change between observations.

SlotXYKind / activeSpeedDrift

One contact test, two consequences

Both kinds move down at their stored speed and use the same contact region. After the shared distance test, kind 2 branches to the star path: it adds one to score and retires the star without damaging the ship. Any other kind reaches the new label meteor_contact, where the existing code clears hull as before.

meteor-storm.asm, excerpt
advance_meteors_absolute:
 cp 16
 jp nc,advance_meteors_skip
 ld a,(ix+2)
 cp 2
 jr nz,meteor_contact
 ld c,1
 ld a,(score)
 add a,c
 ld (score),a
 jr advance_meteors_remove
meteor_contact:
 ; One contact ends this attempt; no recovery state is needed.
 xor a
 ld (hull),a
 push bc
 call impact_sound
 pop bc

The star path puts the award in C with ld c,1, reads score into A, adds C and stores the sum. It then jumps to advance_meteors_remove, the label just after this excerpt, which frees the record.

Stars bypass horizontal drift before the drift gate. Their event record can contain a drift byte, but their kind determines that it will not be used. Watch a star’s X in the active-record table: it should stay fixed as Y increases.

draw_meteor now selects meteor_sprites or star_sprites from kind; both choices meet at the new label draw_object, which sets the height and draws. Its name has survived the first implementation, but it draws either falling object. The caller must not clear kind before erasing: the old kind selects the image that must be XORed away.

meteor-storm.asm, excerpt
draw_meteor:
 ld hl,meteor_sprites
 ld a,(ix+2)
 cp 2
 jr nz,draw_object
 ld hl,star_sprites
draw_object:
 ld a,12
 jp draw_sprite

Award a pickup only once

After adding a point unit, the star takes the same removal path used when an object leaves the play area. That clears kind to zero. On the next visit, the slot is free and its old coordinates cannot award more points.

What if we incremented score but left the star active until it passed the ship?

Show the explanation

The same contact could be found again on later updates, awarding points repeatedly. Collection is a state transition, not just a sound or a displayed number. Retiring the object makes the one-pickup rule explicit.

The score byte stores tens of points: 1 means 10 points, 2 means 20. Each star adds one unit. score sits inside the run block, so every run starts it at zero. This program does not print the score yet: read it in the inspector above, which shows 1 after the first star. The next lesson follows that byte into its printed decimal representation.

Try changing one star’s event kind from 2 to 1 in the companion file, then reassemble. It should use meteor artwork, take the drift path and become harmful. Change all three expectations before running; a data edit can affect several branches that agree on the meaning of kind. Revert restores the companion file as well as the main source.

Sources

The maintained Meteor Storm source linked through this page supplies the game rules and data layout. Its experiments run original Z80 instructions on an emulated 48K PAL Spectrum; the game rules are design choices, not hardware properties.

Run it here

This unit's program, built for you.

Program
meteor-storm.tap
Machine
ZX Spectrum 48K (PAL)

Download meteor-storm.tap