The orbit check is back, and osFileRead says it reads in blocks

Placing a state retired the reason the orbit check was deleted. Reaching
a given orbit through the controls takes a sustained burn while holding
height, and the phase of that burn against the gravity tick - one frame
in ten - decides whether the thruster is seen at all, so two pad files a
frame apart fly differently. The old check passed against one disk and
failed against another, which is a check measuring the boot time rather
than the physics.

Placed at eighty sideways it climbs to row 51, falls to row 190, and
climbs again to row 20 - and the turning points are BROAD, tens of pixels
across, so the samples have nothing like the margin problem the old one
had. Three claims: it climbs, it turns over on its own, and it comes
round again no lower than the first time.

Both halves of the mechanic are separately caught. Without the outward
push it sinks and lands and never climbs; without the exchange it climbs
away and never comes back, which is the one way trip the whole thing
exists to prevent.

---- And osFileRead writes whole blocks, which nothing said ----

A disk is read a block at a time, so a sixteen byte file still puts 256
bytes where it is told to. Reserving exactly the file's length writes
over whatever follows - a quiet corruption rather than a refusal, and it
looks like a bug somewhere else entirely. It cost an afternoon here: the
state buffer sat in front of the view tables, so the program read its
state, wiped the numbers every gauge draws from, and left immediately.

Said now in services.asm beside the vector and in the CosmOS manual,
along with the pattern that works: reserve the length rounded up to the
next 256, read into that, and copy the parts wanted where they are wanted.

The orbit fixture also needs its own keyboard file. The shared one holds
a key down every forty eight bytes for the held-thruster check, which
would fly this orbit as well as measure it.

Programs/CosmOS/README.md

@@ -1259,7 +1259,7 @@ Those numbers are written down once, in `Programs/CosmOS/Source/services.asm`, w
 | osReadLine | DP0 names somewhere to put a line, B says how much room there is. Reads one from the console, with the shell's own editing - arrows, Home, End, Delete - but not its history. Q comes back holding how long it was. The console is left in whatever mode it was found in. |
 | osExit | Gives the machine back. Does not return. |
 | osArgument | DP0 names somewhere to put whatever followed the run command, B says how much room there is. |
-| osFileRead | DP0 names a file, DP1 says where to put it. Q is zero if it read, and DP3 comes back holding how many bytes there were. |
+| osFileRead | DP0 names a file, DP1 says where to put it. Q is zero if it read, and DP3 comes back holding how many bytes there were. It writes WHOLE BLOCKS: a sixteen byte file still puts 256 bytes where it is told, so the room given has to be the length rounded up to the next 256. |
 | osFileSave | DP0 names a file, DP1 is the bytes, A and B together are how many. Q is zero if it saved, whether or not it was there before. |
 | osFileDelete | DP0 names a file. Q is zero if it went. |
 | osFileRename | DP0 is the name a file has, DP1 the name it should have. Q is zero if it moved. |
@@ -1317,6 +1317,13 @@ A file of 256 blocks or more is refused by `osFileRead` rather than partly read,
 
 ### Reading A File That Will Not Fit:
 
+`osFileRead` writes in whole blocks, because a block is what a disk is read in. A sixteen
+byte file still puts 256 bytes wherever it is pointed, and a caller that reserves exactly the
+file's length writes over whatever follows it - which is a quiet corruption rather than a
+refusal, and looks like a bug somewhere else entirely. `DP3` still reports the file's own
+length; the bytes past it are the rest of the block. Reserve the length rounded up to the next
+256, read into that, and copy the parts wanted where they are wanted.
+
 `osFileRead` hands over a whole file, which settles the question for anything under 64K and settles nothing above it. CosmOS's own source is above it: the sources together are a hundred kilobytes and Data Memory is sixty four. A machine that assembles itself has to be able to read a file bigger than its memory, and this is what that stands on.
 
 So there is a second way to ask. `osFileInfo` says how big something is and `osFileBlock` hands over one block of it, and between them a program reads a file of any size through a buffer of 256 bytes.

Programs/CosmOS/Source/services.asm

@@ -41,6 +41,13 @@
 ; going out it is A and B together, and neither direction needs a record in memory that
 ; both sides have to agree on the shape of.
   osFileRead     0d20   ; DP0 names it, DP1 says where. Q is zero if it read, DP3 is how many bytes.
+                        ; ---- AND IT WRITES WHOLE BLOCKS ----
+                        ;
+                        ; A disk is read a block at a time, so a sixteen byte file still puts
+                        ; 256 bytes where it is told to. The room given has to be the file's
+                        ; length ROUNDED UP to the next 256, and a caller that gives exactly
+                        ; the length writes over whatever follows it. DP3 still says how many
+                        ; bytes are the file's; the rest is whatever was on the block.
   osFileSave     0d21   ; DP0 names it, DP1 is the bytes, A and B are how many. Q is zero if it saved.
   osFileDelete   0d22   ; DP0 names it. Q is zero if it went.
   osFileRename   0d23   ; DP0 is the name it has, DP1 the name it should have. Q is zero if it moved.