The machine starts itself

stage two
  CosmOS
  > saved it
  read it back, 22 bytes:

Stage one hands over to stage two out of a boot slot; stage two mounts the
filesystem, finds /System/cosmos.bin, takes the image apart and places its
code, its data and its vector table, and jumps to the entry point the
vectors named. Nothing placed memory for it.

What it loads is an ORDINARY BOOT IMAGE, the same SPBT file the emulator
has always been handed. That was the user's call and it is the whole trick:
a second stage that loads the machine's normal image format is not a
boot-specific mechanism, so bare metal SplitBit stops being a special case.
A program wanting no operating system under it is just an image, written
under CosmOS like any other, and startable because it is a file.

Three things in it worth knowing:

- THE ENTRY POINT IS CAUGHT ON ITS WAY PAST. Program Memory cannot be read
  back, so the boot vector cannot be looked up after being installed; the
  vector loop notices the one addressed at 0xFC00 and keeps it.
- A missing "VEC" is not a fault. An image written before vectors existed
  simply ends after its data, and then the entry point is zero, which is
  what every such image has always relied on.
- Feature flags that are set mean an image asking for a machine this may
  not be, and the honest answer to a request that cannot be understood is
  to refuse rather than to run it anyway.

The test records that the system WORKS afterwards rather than that it
started. A loaded program running is what says the vector table arrived,
because a program reaches the system through SWI and nothing else; the file
written and the directory entered say the filesystem and the console came
up with it. A second disk has a boot slot and nothing to start, and says so
rather than jumping somewhere.

Tests/manifest

@@ -374,6 +374,21 @@ bootNoArea           | Boot/stage1.asm                    | run      | -
 # variables and the string that sbfs.asm needs.
 bootData             | Boot/slotData.asm                  | assemble | -                  | -
 bootDataRuns         | Boot/stage1.asm                    | run      | -                  | -     | disks/chainData.img
+
+# ---- The machine starting itself ----
+#
+# The whole chain: the emulator hands over stage one, stage one reads the live boot slot
+# into Program Memory and jumps, stage two mounts the filesystem, finds /System/cosmos.bin,
+# takes the image apart and places its code, its data and its vector table, and jumps to
+# the entry point the vectors named.
+#
+# WHAT IS RECORDED IS THAT THE SYSTEM WORKS AFTERWARDS, not that it started. A loaded
+# program running is what says the vector table arrived, because a program reaches the
+# system through SWI and nothing else; the file written and the directory entered say the
+# filesystem and the console came up with it.
+selfBoot             | Boot/stage1.asm                    | run      | selfBoot.in        | 90000000 | disks/selfboot.img
+# And a disk with a boot slot but nothing to start, which says so rather than jumping.
+selfBootNoSystem     | Boot/stage1.asm                    | run      | -                  | 90000000 | disks/nosystem.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.