Take back the sixteen kilobytes the scratch map left behind

The assembler's buffers start at 0x8000, and the reason written beside them is
that everything above its own data is free. That was true when it was written.
The system kept below 0x1000 then; its data now reaches 0x1FFF, and the
assembler's own moved from 0x1000 to 0x2000 with it when both halves of the
memory map were doubled. The floor came up and the map stayed where it was,
leaving sixteen kilobytes between the two that nothing touched at all.

Starting at 0x4000 takes that back, with nearly four kilobytes of slack still
in front of it and room for the assembler's own data to double before the two
would meet.

All of it went to the output image, because that is the buffer that is actually
full. cosmos.bin is 13,245 bytes against the 13,312 it had, which is sixty
seven bytes - the next thing added to the system would have made the machine
unable to build it, and it would have shown up as a test going red rather than
as anything explicable at the machine. The label table has room yet, so this is
not the moment to share the space out evenly.

This is the third time a limit here has gone unnoticed until something hit it,
and the second where the cause was a number that stopped being true rather than
one that was ever wrong.

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

Programs/CosmOS/Assembler/scratch.asm

@@ -15,13 +15,30 @@
 ; below 0x1000, the staging area is only in use during a load, and the Stack comes down
 ; from the top. So the addresses are written down here and the file carries none of it.
 ;
-;   0x8000  3072   the label index, 768 entries of four
-;   0x8C00  8192   the label names, packed end to end
-;   0xAC00 13312   the output file being built
+;   0x4000  3072   the label index, 768 entries of four
+;   0x4C00  8192   the label names, packed end to end
+;   0x6C00 29696   the output file being built
 ;   0xE000  1792   the vector names, 64 entries of twenty eight
 ;   0xE700  2048   the reader's stack, six levels of 301
 ;   0xEF00   368   which files have been included, sixteen names of 23
 ;
+; IT USED TO START AT 0x8000, and the reason given was that everything above the
+; assembler's own data is free. That was true when it was written and stopped being true
+; without anything noticing: the system kept below 0x1000 then, and its data now reaches
+; 0x1FFF, and the assembler's own moved from 0x1000 to 0x2000 with it. The floor came up
+; and the map stayed where it was, leaving sixteen kilobytes between the two that nothing
+; touched.
+;
+; Starting at 0x4000 takes that back. The assembler's data is 4,114 bytes from 0x2000, so
+; there is still nearly four kilobytes of slack in front of this - and room for its data to
+; double before the two would meet.
+;
+; ALL SIXTEEN OF THOSE KILOBYTES WENT TO THE OUTPUT, which was the buffer that was actually
+; full: cosmos.bin is 13,245 bytes against the 13,312 it used to have, which is sixty seven
+; bytes, and the next thing added to the system would have made the machine unable to build
+; it. That is a wall the label table is not yet against, so this is not the place to start
+; sharing the room out evenly.
+;
 ; That ends at 0xF070, with the Stack coming down from 0xFFFF above it - nearly four
 ; kilobytes, against the tens of bytes of CALL frames this ever nests.
 ;
@@ -36,11 +53,11 @@
 ; second is bigger than the first, which is worth knowing: the hardest thing this assembles
 ; is not the operating system, it is itself.
 ScratchLabIndex:
-  0x80 0x00
+  0x40 0x00
 ScratchLabArena:
-  0x8C 0x00
+  0x4C 0x00
 ScratchImage:
-  0xAC 0x00
+  0x6C 0x00
 ScratchVecNames:
   0xE0 0x00
 ScratchSrcStack: