Landing pads, carved rather than looked for

A random walk does not leave flat ground and a lander wants some. Four
pads are cut into the moon after it is generated, each four columns
levelled to whatever height its first column happened to have - so they
sit in the landscape rather than on a shelf above it. The moon decides
where they are; this only decides that they are flat.

Searching for flat spots was the alternative and it can fail, which means
a fallback that carves anyway - the carving, plus a search nobody needed.

They are marked by an ATTRIBUTE and not a tile of their own, which costs
no art at all: a nibble is added to every index in a tile, so one solid
block is grey moon or a cyan pad depending on the byte beside it.

Which columns are pads is an array, because asking has to be one lookup.
Four comparisons per column per row is 12,800 of them for one screen, and
the landing verdict asks the same question again.

THE LANDER STARTS ABOVE ONE, because that is where a porter's day begins.
Starting in the middle of nowhere meant a straight descent landed in the
middle of nowhere, which is a fine thing to be able to do and a poor thing
to have to.

That change cost the crash test its teeth, and the way it did is worth
keeping. It held nothing at all and let the lander fall - and a short drop
onto the high ground of the base you started above is survivable, which is
correct, and left the test saying nothing. It holds Right now: lateral
speed has no limit and nothing slows it, so a slide always ends badly
however the rest is tuned.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW

Tests/manifest

@@ -1014,14 +1014,19 @@ cosmosSprite         | CosmOS/Source/cosmos.asm           | run      | -
 padTest              | testPrograms/padTest.asm           | run      | -                  | -     | -                | -                  | padTest.pad
 # ---- Lunar Porter, arriving ----
 #
-# The same program, the same keys, and two different controllers. One holds nothing at all and
-# the lander falls the whole way; the other pulses the thruster six frames in sixteen and
-# brings it down slowly enough to survive.
+# The same program, the same keys, and two different controllers. One holds Right and never
+# stops, so it arrives sliding; the other pulses the thruster six frames in sixteen and comes
+# down slowly enough to survive.
 #
 # WHAT SAYS WHICH IS THE SPEED AT THE MOMENT IT ARRIVES, and nothing else - the terrain is the
-# same terrain, from the same fixed seed, so the two runs differ only in what was held. That
-# is the whole of the game's difficulty in two fixtures.
-cosmosLanderCrash    | CosmOS/Source/cosmos.asm           | run      | -                  | 60000000 | disks/cosmos.img | lander.keys | landerFall.pad
+# same terrain, from the same fixed seed, so the two runs differ only in what was held.
+#
+# SLIDING RATHER THAN FALLING, and the difference matters. The crash fixture used to hold
+# nothing at all, and stopped crashing the day the lander began its day above a base: a short
+# drop onto high ground is survivable, which is correct and made the test say nothing. Lateral
+# speed has no limit and nothing slows it, so a slide always ends badly however the rest is
+# tuned.
+cosmosLanderCrash    | CosmOS/Source/cosmos.asm           | run      | -                  | 60000000 | disks/cosmos.img | lander.keys | landerSlide.pad
 cosmosLanderSoft     | CosmOS/Source/cosmos.asm           | run      | -                  | 60000000 | disks/cosmos.img | lander.keys | landerSoft.pad
 # ---- And the same landing, flown from the second controller ----
 #