Give the system another page of each memory

CosmOS had 1,161 bytes of Program Memory left before the address applications
load at, and Tab completion is not going to fit in that with anything to spare.
So the wall moves up one page: the system keeps below 0x4FFF and 0x2FFF, and an
application is based at 0x5000 and 0x3000.

A PAGE IS A CHEAP THING TO GIVE IT AND AN EXPENSIVE THING TO RUN OUT OF. An
application still has 44K of Program Memory before the vector table and the
largest one here uses 7.5K, so what was taken from applications is space nothing
has ever asked for - while what the system gained is the difference between
building the next thing and counting bytes while building it.

Not doubling, which was the version that would have cost application space worth
minding. One page, and the same again when it is needed.

Nothing in the machine knows where the wall is, so this is 34 #Base lines, one
threshold in the fault handler, and the table in the CosmOS README that
Tests/docs.sh reads its limits out of.

The native assembler's scratch map had to move with it, and docs.sh said so
before anything ran: its data reached 0x40D6 and its buffers began at 0x4000, so
they were sitting on its variables. That file already carries a paragraph about
the floor coming up and the map staying where it was. It has happened twice now,
and been caught by a check the first time wrote.

Twenty three recordings are the same runs a page higher.

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

Programs/CosmOS/README.md

@@ -847,16 +847,24 @@ CosmOS divides the two SplitBit address spaces by convention:
 
 | Memory | CosmOS | Loaded application |
 | -- | -- | -- |
-| Program Memory |   `0x0000` through `0x3FFF` | `0x4000` and above |
-| Data Memory |  `0x0000` through `0x1FFF` | `0x2000` and above |
+| Program Memory |   `0x0000` through `0x4FFF` | `0x5000` and above |
+| Data Memory |  `0x0000` through `0x2FFF` | `0x3000` and above |
 
-Both of CosmOS's halves were doubled once it outgrew the first ones. **The division is a
+CosmOS's halves have been enlarged twice: doubled once when it outgrew the first ones, and
+given a page each when the shell learned to edit and remember a line. **The division is a
 convention and nothing enforced it**, so CosmOS quietly grew past `0x1FFF` and the next
 program loaded landed on top of its own code - which does not fail where it happens, it
 fails later, in whatever part of the shell the program happened to cover. `make test` now
 measures both segments against the numbers in this table, so the table is checked rather
 than merely written down.
 
+**A page is a cheap thing to give it and an expensive thing to run out of.** An application
+still has 44K of Program Memory before the vector table, and the largest one here uses 7.5K,
+so the space taken from applications is space nothing has ever asked for - while the space
+given to the system is the difference between building the next thing and counting bytes
+while building it. Moving the wall costs a `#Base` line in each application and a rebuild;
+that is the whole of it, because nothing in the machine knows where the wall is.
+
 **The table is checked against itself as well.** The first version of that check read only
 the CosmOS column, and so it passed a table whose Data row gave the system `0x3FFF` and an
 application `0x2000` - two columns that cannot both be true, sitting next to each other.
@@ -890,7 +898,7 @@ A minimal CosmOS application therefore looks like this:
 #Include services.asm
 
 #Program
-  #Base 0x4000
+  #Base 0x5000
 
 start:
   SETD.0 Message
@@ -898,7 +906,7 @@ start:
   SWI osExit
 
 #Data
-  #Base 0x2000
+  #Base 0x3000
 
 Message:
   "Hello from CosmOS."