Reboot, and the machine device that makes it possible

Until now the only way to restart was to stop the emulator and run it
again, which meant the one thing the machine could not do was the thing
Once was written for. The loop now closes without leaving it:

  > Once /System/Boot/bare.bin
  next start: /System/Boot/bare.bin, once
  > Reboot
  starting again
  stage two
  just this once: /System/Boot/bare.bin
  bare metal: no system, just this

Writing 1 to port 0x13 asks the machine to start over. A PORT RATHER THAN A
SERVICE, because a reset has to work when the system does not: something
only askable through SWI would be unavailable in exactly the case that
wants it most, and a program that owns the whole machine has no system to
ask. It is device class 0x04, in the range kept for the machine rather than
among the peripherals, because it is not one - it is not attached to
anything and cannot be unplugged.

WHAT A RESET REPEATS IS HOW THE MACHINE STARTED. Named an image, the
emulator places it again; named none, the ROM is shadowed again and reads
the disk. Anything else would mean a reset changed what the machine IS,
which is the one thing a reset must not do. Both are tested.

Taken between instructions, because a device cannot restart the machine
from inside the instruction that asked: the CPU is part way through a step
and its state is not yet anything a reset could leave behind consistently.

The disk stays attached and keeps everything written to it - that is what
warm means. The vector table is cleared, which is the one deliberate
departure from leaving memory alone: a vector points into whatever
installed it, and after a reset that program is not running, so a handler
left behind would aim an interrupt at an address belonging to something
gone. It is the argument CosmOS already makes at exit, applied to the
machine.

Reboot is 45 bytes, most of them the word it prints.

SplitBit Programming Manual.md

@@ -507,6 +507,7 @@ If nothing is installed for the vector a device refused with, the machine stops
 | 0x10 | A test device. Writing anything to it puts its own line up, so that interrupt handling can be exercised without waiting on anything. The byte written is ignored. | 0x10 |
 | 0x11 | A device that refuses everything, in both directions, so that refusal can be exercised without the memory controller. | 0x11 |
 | 0x20 - 0x23 | The disk. See Storage. It interrupts on 0x20, its base port. | 0x13 |
+| 0x13 | The machine itself. Writing 1 asks it to start over: whatever put the first instruction in memory does it again, and the CPU begins where the boot vector points. A port rather than a service, because a reset has to work when the system does not - and a program that owns the whole machine has no system to ask. The disk is not unplugged and keeps what was written to it; the vector table is cleared, because a handler left behind would aim an interrupt into a program that is no longer running. | 0x04 |
 | 0x12 | A device that owns 256 bytes of memory. Writing to its port fills that memory with the byte written, standing in for a disk controller reading a sector. Its memory is unreachable until it is registered as a bank. | 0x12 |
 | 0xE0 - 0xEF | The memory controller. See The Memory Controller. | 0x03 |
 | 0xFF | The bus registry. See Asking What Is There. | 0x01 |
@@ -546,7 +547,8 @@ One thing to be careful of: the registry remembers which port it was asked about
 | 0x01 | Bus registry. |
 | 0x02 | Console. |
 | 0x03 | Memory controller. |
-| 0x04 - 0x0F | Reserved for the machine itself. |
+| 0x04 | The machine itself. Writing 1 to its port asks it to start over. |
+| 0x05 - 0x0F | Reserved for the machine itself. |
 | 0x10 | Test device, which raises its own line. |
 | 0x11 | Test device, which refuses everything. |
 | 0x12 | Test device, which owns memory. |