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

Tell the person where it hurts

Browse Source 
A fault stopped the machine and printed a line to standard error. On a terminal
that is a diagnosis. Behind a window it is a frozen picture and no reason at
all, because the message went somewhere nobody was looking - the machine looked
hung and was not. It had stopped, and said so invisibly.

CosmOS catches all five faults now and says what happened on the screen, with
the address, in red.

A FAULT ENDS THE PROGRAM, NOT THE MACHINE. That is the answer to "carry on or
start again", and it is not a compromise: a bare RETI from most of these meets
the instruction that failed and fails again, so carrying on was never on offer.
But the machine is almost never what is broken. Everything the shell puts back
when a program exits - the Stack, its vectors, the drive, the working directory,
the console, the screen - is exactly what wants putting back after one dies, so
the handler sets a status and joins handleExit. You are back at the prompt, and
the program is recorded as having STOPPED rather than finished, because saying
"finished" under a red fault message would be the shell contradicting itself.

A fault below where programs load is the system's own, and there is nothing to
go back to. That one says so and stops.

THE SCREEN GOES BACK TO A MODE TEXT CAN BE SEEN IN, and that is the part that
matters rather than the part that is prettiest. A program that faulted in bitmap
mode left the console with no text rows, so it draws nothing at all: the message
would be perfectly correct and completely invisible, which is the one thing it
must never be. Two palette entries go back for the same reason, since a program
that wrote its own colours can leave every ink the same as every paper. Only the
two the message needs, so the rest of what the program chose is left alone.

Both halves are checked by looking at the PICTURE, because the serial line was
never where the problem was. Crash blind ruins the palette and drops into bitmap
mode before it faults; without the mode the screen comes back 320 by 200 with
nothing on it, and without the palette it is the right size with the message
present and unreadable. Each break loses the red on its own.

Crash is also a program worth having: it breaks in whichever of the five ways
you name, so a fault screen can be looked at without having written a bug first.

Two things found on the way:

The native assembler keeps its OWN copy of the reserved vector names, so it did
not know NoHandler or NoDevice and built a cosmos.bin that differed from the
host assembler's. Caught by native.sh, which is exactly the drift that test
exists for.

And cosmosMonitor had dead input. It assembles code into 0x8000 and runs it, and
that code faults - which used to kill the machine, so everything after it in the
file had never run. It runs now, and the recording grew by sixty lines of
monitor session that had been unreachable since the day the fault was put there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
This commit is contained in:
Anachronaut
2026-09-01 15:08:20 -04:00
co-authored by Claude Opus 5
parent 000a6d39cb
commit fd9c4c75f8
19 changed files with 931 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Programs/CosmOS/README.md
+40
View File
@@ -599,8 +599,48 @@ from every assembly file in it. Several are old programs written for the bare ma
| Wander | Goes to the directory it is given and reads a file there by a bare name. The only thing that moves the machine from inside a program, and so the only thing that can check the shell puts the working directory back afterwards. |
| More | A forward-only pager. Space advances a screen, Return one line, and q stops. |
| Press | Says what the console handed it, in hexadecimal and by name. It reads a line and then keys, because the keys that are not characters are dropped in line mode and delivered in key mode, and both halves of that rule want showing. |
| Crash | Breaks on purpose, in whichever of the four ways the system now catches, so that a fault screen can be looked at without having written a bug first. |
| Mode | Forty columns or eighty, whichever the screen is not in. Ten instructions and no data at all, which is the point of it: it is the smallest shape a loadable program can take, and the loader used to stop the machine dead on one. |
### When Something Goes Wrong:
A fault used to stop the machine and print a line to whatever was behind it. On a terminal
that is a diagnosis; behind a window it is a frozen picture and no reason at all, because the
message went to a standard error nobody was looking at. **The machine looked hung and was
not** - it had stopped, and said so somewhere invisible.
CosmOS catches all five faults the machine can raise and says what happened on the screen:
```
> Crash opcode
that byte is not an instruction, at 404E
A 00 B 0F Q 00
the program was stopped
>
```
**A fault ends the program, not the machine.** That is not a compromise. A bare `RETI` from
most faults meets the very instruction that failed and fails again, so carrying on is not on
offer - but the machine is almost never what is broken. Everything the shell puts back when a
program exits, which is the Stack, any vectors it installed, the drive, the working directory,
the console and the screen, is exactly what wants putting back after one dies. So you are
returned to the prompt, and the program is recorded as having stopped rather than finished.
A fault *below* where programs load is the system's own code, and there is nothing to go back
to. That one says so and stops.
**The screen is put back into a mode text can be seen in first**, and that is the part that
matters most rather than the part that is prettiest. A program that faulted in bitmap mode
left the console with no text rows at all, so it draws nothing - the message about what went
wrong would be perfectly correct and completely invisible. Two palette entries are rewritten
for the same reason, since a program that wrote its own colours can leave every ink the same
as every paper. Only the two the message needs are touched; the rest of what the program
chose is left alone.
The address is where it happened, and it is exact. For a missing service or a device with
nobody listening it is the address *after* the instruction, because those two are the faults
where the instruction did dispatch and it was the entry that was empty.
### The Monitor:
The monitor is **part of the shell**, not a program the shell loads, and that is the whole reason it works. A loaded program occupies the one place a loaded program goes, so a monitor that was an application could never look at any other application: loading the thing you wanted to inspect would replace the thing doing the inspecting.