jake/SplitBit-Emulator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Reboot, and the machine device that makes it possible

Browse Source 
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.
This commit is contained in:
Anachronaut
2026-08-27 20:56:46 -04:00
parent 7b28f48f52
commit 79727044b7
13 changed files with 199 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+22
View File
@@ -296,6 +296,28 @@ so a machine interrupted while updating its only boot slot would not boot at all
the one failure on this disk with no way back. Writing the slot that is *not* live and then
moving one byte in the superblock turns that into a machine that boots what it had before.
### Starting Again:
Writing `1` to port `0x13` asks the machine to start over, and `Reboot` is the program that
does it - forty five bytes, most of them the word it prints.
**A port rather than a service**, because a reset has to work when the system does not.
Something that could only be asked for 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.
**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 for the rest. Anything else
would mean a reset changed what the machine *is*, which is the one thing a reset must not
do. It is taken between instructions, because a device cannot restart the machine from
inside the instruction that asked.
The disk is not unplugged and keeps everything written to it. That is what warm means: the
machine starts again, the world it starts into does not. **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 when it takes a program's vectors back at exit.
### Starting Something Else Just This Once:
A program that owns the whole machine has nowhere to run. It cannot be started from the