A boot payload can arrange its own Data Segment

Stage one places Program Memory and nothing else, because knowing where a
payload's data ends and its code begins would mean knowing a format, and
knowing formats is what ROM must do as little of as possible. But the real
second stage needs a Data Segment: sbfs.asm has variables and a string it
compares against.

The answer needs nothing new. A loadable image is written into the slot as
code followed by data, so the data image is already in Program Memory just
past the code - and the payload's first instructions blit it down to where
it was assembled for. Proved by slotData.asm, which prints from a string it
placed itself.

The padding is the part worth recording. The blit needs a length and the
assembler will not work out the difference between two labels, so the
segment is padded to a round number and that number is what gets copied.
The first draft padded to 257 and copied 256, and the byte that did not
arrive was padding, so it worked by luck. It is exact now and says why.

This is the shape the user asked for and it goes further than the
mechanism: the second stage becomes a loader for the machine's ORDINARY
image format rather than for anything boot-specific, so bare metal SplitBit
stops being a special case. A program that wants no operating system is
just an image, developed under CosmOS like any other, and selectable at
boot because it is a file.

Tests/expected/bootDataRuns.out

@@ -0,0 +1,3 @@
+a payload with data of its own
+Execution halted.
+[exit 0]

Tests/lint-baseline.txt

@@ -1,3 +1,4 @@
+Programs/Boot/slotData.asm	redundant-setd	1
 Programs/Boot/stage1.asm	redundant-setd	2
 Programs/CosmOS/Apps/Copy.asm	redundant-setd	2
 Programs/CosmOS/Apps/Edit.asm	redundant-setd	3

Tests/makedisks.sh

@@ -377,3 +377,12 @@ tail -c +17 "$WORK/otherSlot.sbx" > "$WORK/otherSlot.raw"
 # And the same disk with the other slot chosen, so both are exercised.
 cp "$DISKS/chain.img" "$DISKS/chainAlt.img"
 "$TOOL" bootslot "$DISKS/chainAlt.img" 1 >/dev/null
+
+# And a slot whose payload has a Data Segment of its own. Stage one places Program Memory
+# and nothing else, so the payload copies its data down from just past its own code - which
+# is the mechanism the real second stage will need, since sbfs.asm has variables and a
+# string it compares against.
+"$TOOL" format "$DISKS/chainData.img" 256 4 4 >/dev/null
+"$ROOT/Assembler" "$ROOT/Programs/Boot/slotData.asm" -o "$WORK/slotData.sbx" >/dev/null
+tail -c +17 "$WORK/slotData.sbx" > "$WORK/slotData.raw"
+"$TOOL" boot "$DISKS/chainData.img" "$WORK/slotData.raw" 0 >/dev/null

Tests/manifest

@@ -368,6 +368,12 @@ bootChainAlt         | Boot/stage1.asm                    | run      | -
 # A disk with no boot area cannot be started, and says so in the one character a ROM has
 # room to say anything in.
 bootNoArea           | Boot/stage1.asm                    | run      | -                  | -     | disks/sbfs.img
+# A payload that arranges its own Data Segment, by copying it down from just past its own
+# code. Stage one places Program Memory and nothing else - knowing where a payload's data
+# ended would mean knowing a format - so this is how the real second stage will get the
+# variables and the string that sbfs.asm needs.
+bootData             | Boot/slotData.asm                  | assemble | -                  | -
+bootDataRuns         | Boot/stage1.asm                    | run      | -                  | -     | disks/chainData.img
 # Reading a disk that has directories on it. The machine can walk a path at this point but
 # cannot make a directory, so the disk is built by the host tool and read here - which is
 # the two implementations checking each other rather than either checking itself.