A state can be placed, which four things were queued behind

Lander reads sixteen bytes from /lander.state if the disk has one and
starts from those: position, velocity, where the station is, fuel, and
which screen to be in. A disk without the file is the game as it always
was, which is every other flight in the suite.

It exists because some states cannot be flown to. A successful dock needs
the lander alongside the station and matched, and NINETY SIX pad files
failed to get there - not for want of trying, but because climbing spends
sideways speed, so a lander cannot rise while matched and arrives slower
than orbital every time. Reaching it wants two burns and a phase. The
orbit check had already been deleted for the same reason, and the strike
check was flown on a nineteen frame window, which is the sort of fixture
that ends up measuring the boot time rather than the physics.

Binary, because that is what a file is on this machine. A tool to build
one from readable text is a small job for another day; until then the
tests write the bytes with the fields named, which reads plainly enough.

---- The buffer is a whole block, and that is not caution ----

osFileRead lands a file in Data Memory and a file is stored in blocks of
256, so reading sixteen bytes into sixteen bytes of room writes over
whatever follows. It did: the first version put the buffer in front of
the view tables, and the program read its state, wiped the numbers every
gauge draws from, and left immediately - "finished" and back to the
prompt, with nothing on the screen to say why.

Four checks, each seen to fail on its own break: a state file places the
lander (row 192 and twelve cells of gauge, against thirty one with no
file), a matched approach docks and is paid once and not once a frame, it
then rides the station a tile under it, and the same approach unmatched
is a wreck. The flown strike fixture and its narrow window are gone.

Programs/CosmOS/Apps/Lander.asm

@@ -48,6 +48,7 @@ start:
   ; floor the system gives every program does not.
   SWI osTakeScreen
 
+  CALL loadState            ; Before the view, because a state may say which view to be in.
   CALL setView              ; The block every gauge below reads its screen numbers out of.
   SETD.0 Wide
   LDA.0
@@ -2172,6 +2173,75 @@ showHeightSized:
   OUTA 0xE9                 ; And no depth, A being nought already.
   RET
 
+; ---- A state, placed rather than flown to ----
+;
+; Sixteen bytes read straight over the numbers the program would otherwise start with. If the
+; file is not there nothing happens and the defaults stand, so a disk without one is the game
+; as it has always been.
+;
+; ---- Which exists because some things cannot be flown to ----
+;
+; A successful dock needs the lander alongside the station and matched, and NINETY SIX pad
+; files failed to get there - not for want of trying, but because climbing spends sideways
+; speed, so a lander cannot rise while matched and arrives slower than orbital every time.
+; Reaching it wants two burns and a phase, which is a real manoeuvre rather than something a
+; straight line of button presses stumbles into. The same was true of the orbit, whose check
+; had to be deleted for measuring the boot time instead of the physics, and of the ride, and
+; of the strike, whose window is nineteen frames wide. Four things queued behind one facility.
+;
+; BINARY, because that is what a file is on this machine. A tool to build one from readable
+; text is a small job for another day; until then the tests write the bytes, which is plain
+; enough while the fields are named.
+loadState:
+  SETD.0 StateName
+  SETD.1 StateBuffer
+  SWI osFileRead
+  BNQ loadStateNone         ; Not there, or would not read, and either way the defaults stand.
+
+  SETD.0 StateAcross
+  SETD.1 AcrossLow
+  CALL copyWord
+  SETD.0 StateDown
+  SETD.1 DownLow
+  CALL copyWord
+  SETD.0 StateSpeedAcross
+  SETD.1 SpeedAcross
+  CALL copyWord
+  SETD.0 StateSpeedDown
+  SETD.1 SpeedDown
+  CALL copyWord
+  SETD.0 StateStation
+  SETD.1 StationLow
+  CALL copyWord
+  SETD.0 StateStationDown
+  SETD.1 StationDownLow
+  CALL copyWord
+
+  SETD.0 StateFuel
+  LDA.0
+  SETD.1 Fuel
+  STA.1
+  SETD.0 StateWide
+  LDA.0
+  SETD.1 Wide
+  STA.1
+  SETD.0 StateLanded
+  LDA.0
+  SETD.1 Landed
+  STA.1
+loadStateNone:
+  RET
+
+; Two bytes, from where DP0 says to where DP1 does.
+copyWord:
+  LDA.0
+  STA.1
+  INCD.0
+  INCD.1
+  LDA.0
+  STA.1
+  RET
+
 ; ---- Two zoom levels, which the device turns out to have already had ----
 ;
 ; Forty columns and eighty are the same map, the same 8x8 cells and the same engine; only how
@@ -2882,6 +2952,43 @@ ViewWide:
 ; Which of the two is up. Nought is forty columns, which is what the program starts in.
 Wide:
   0x00
+
+; ---- The sixteen bytes a state file holds, in the order it holds them ----
+;
+; Named rather than numbered, so whatever writes one and this that reads it are describing the
+; same fields. Low byte first, the way every other word here is.
+StateName:
+"/lander.state"
+StateBuffer:
+StateAcross:
+  0x00 0x00                 ; Where round the moon, in sixteenths.
+StateDown:
+  0x00 0x00                 ; And how far down, which is negative above the origin.
+StateSpeedAcross:
+  0x00 0x00
+StateSpeedDown:
+  0x00 0x00
+StateStation:
+  0x00 0x00                 ; Where the station is, so a rendezvous can start alongside one.
+StateStationDown:
+  0x00 0x00
+StateFuel:
+  0x00
+StateWide:
+  0x00                      ; Which screen to start in: some of this is only visible wide.
+StateLanded:
+  0x00
+StateSpare:
+  0x00                      ; Room, because sixteen is a rounder number than fifteen.
+
+; ---- And a whole block of room after them ----
+;
+; osFileRead lands a file in Data Memory and a file is stored in blocks of 256, so reading
+; sixteen bytes into sixteen bytes of room writes over whatever follows. It did: the first
+; version of this put the buffer in front of the view tables and the program read its state,
+; wiped the numbers every gauge draws from, and left immediately - "finished" and back to the
+; prompt, with nothing on the screen to say why.
+  #Reserve 0d240
 ; What B was doing last frame, because a pad says what is held and not what was pressed.
 ZoomWas:
   0x00