; Where the assembler's big buffers live.
;
; A map rather than a set of declarations, and it has a file of its own because the reader
; and the label table both need addresses out of it while neither includes the other.
;
#Data

; NOT #Reserve, AND THAT IS THE WHOLE POINT. Reserved space in a segment is written into
; the file as zeroes and copied at load, so 22K of scratch made a 34K file - and a loaded
; program is staged at 0x8000 before being put in place, which leaves exactly 32,768 bytes
; for the whole of it. The assembler could not load itself.
;
; None of this is initialised data. It is scratch, wanted only while the assembler is
; running, and while it is running everything above its own data is free: the system keeps
; 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.
;
;   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.
;
; The reader's levels went from 293 to 301 when an include gained somewhere to be looked
; for: the name in each level is a PATH now, and "/Lib/" is five characters of it. Six
; levels of 301 is 1806, so the room here has to stay above that - which is why the include
; list moved up rather than the stack simply being asked to fit.
;
; THE TWO THINGS THAT DECIDE THESE SIZES are the largest program it will be asked to build
; and the largest one it will be asked to read. CosmOS is 475 labels and 9,564 bytes of
; output; the assembler itself is 555 labels, about 6,800 bytes of name and 11,648 of output. The
; second is bigger than the first, which is worth knowing: the hardest thing this assembles
; is not the operating system, it is itself.
ScratchLabIndex:
  0x40 0x00
ScratchLabArena:
  0x4C 0x00
ScratchImage:
  0x6C 0x00
ScratchVecNames:
  0xE0 0x00
ScratchSrcStack:
  0xE7 0x00
ScratchIncNames:
  0xEF 0x00