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.
Anachronaut
c312853f8e