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.

README.md

@@ -283,6 +283,23 @@ has versions - all of that lives in the boot area, on the disk, where it can be
 It reads the live slot into Program Memory, jumps to the first byte, and prints one
 character and stops if there is nothing to start.
 
+`Programs/Boot/stage2.asm` is what sits in the slot. It mounts the filesystem, finds the
+system by name, and takes the image apart: code into Program Memory, data into Data
+Memory, and each vector written through the controller, which is the only thing that can
+write Program Memory at all. The entry point is noticed on the boot vector's way past,
+because Program Memory cannot be read back to look it up afterwards.
+
+**What it loads is an ordinary boot image** - the same SPBT file the emulator has always
+been handed directly. That 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 that wants no operating system under it is just an image,
+written under CosmOS like any other, and startable because it is a file.
+
+Stage two arranges its own Data Segment. Stage one places Program Memory and nothing else,
+since knowing where a payload's data ended would mean knowing a format, so the image is
+written into the slot as code followed by data and stage two's first act is to blit its
+data down from just past its own code.
+
 SplitDisk speaks the same on disk format SplitBit does, so an image it makes is one the machine can read, and one the machine writes is one it can read back. It is a convenience rather than a necessity: SplitBit writes its own filesystem, and now assembles its own programs, so a disk can be filled without leaving the machine.
 
 Files are laid down contiguously, so a disk can have free blocks without having them in one piece. When that happens `put` says so rather than putting part of a file on.