A colour reaches a terminal as well as the screen

The console's attribute has always meant something to the screen and
nothing to the serial line: its low nibble picks one of sixteen ink and
paper pairs, and only videoPutCell ever read it. So the fault screen's
red was red in the window and grey down the wire, and Examples/colours
printed " ordinary  highlighted " with nothing to tell them apart.

It is said in ANSI now, on the same terms the cursor is said in: a
register write only marks it and the next character sends it, so setting
a scheme and printing nothing says nothing, and setting the same scheme
twice costs one sequence rather than two. Only the scheme nibble crosses
- the page bits say which tiles a cell draws from, which is a fact about
the screen's own art.

THE ORDER WAS ALREADY RIGHT, which is worth saying because it looks like
a borrowing and is not. Both sets enumerate a three-bit colour, red green
blue counted in binary: one is red in both, three is yellow in both, six
is cyan in both. The same arithmetic done twice, forty years apart. The
one place they differ is slot 0, and that difference is forced - this
screen is ink on black, so ink cannot be black, and slot 0 is grey where
ANSI's is black.

Every sequence begins with a reset, so going from bank 8 to bank 1 does
not write red on the grey paper bank 8 left behind.

Scheme 0 is a bare reset rather than grey on black, and a terminal is
assumed to start plain - so a machine that never asks for a colour says
nothing at all, and one that does put the terminal back on its way out.
Two ways out, because the two endings have different rules: stopping on
purpose goes through stdio, since atexit runs BEFORE the buffer is
flushed and a reset written to the file descriptor would arrive in front
of the text it is meant to follow. Dying on a signal writes the four
bytes directly and accepts that the buffer may be lost.

colourTest walks all sixteen and then halts WITH ONE STILL SET, so the
recording shows the reset after the halt line rather than before it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW

Tests/manifest

@@ -1202,6 +1202,21 @@ cosmosBlankDisk      | CosmOS/Source/cosmos.asm           | run      | cosmosBla
 printDecimalTest     | testPrograms/printDecimalTest.asm  | xfail    | -                  | -
 printDigitTest       | testPrograms/printDigitTest.asm    | xfail    | -                  | -
 printHexTest         | testPrograms/printHexTest.asm      | xfail    | -                  | -
+# ---- What a colour means down a serial line ----
+#
+# The console's attribute has always meant something to the SCREEN and nothing to a terminal:
+# its low nibble picks one of sixteen ink and paper pairs, and only videoPutCell read it. So a
+# fault printed in red was red in the window and grey down the wire.
+#
+# All sixteen, so the table is checked rather than sampled. Scheme 0 must say NOTHING - a
+# terminal is assumed to start plain, and a machine that never asks for a colour opening every
+# session with a reset would be noise in every recording here.
+#
+# AND IT STOPS IN COLOUR. What follows the halt line is the machine putting the terminal back,
+# which is the other half: an atexit handler runs before stdio flushes, so a reset written
+# straight to the file descriptor would come out in FRONT of the text it is meant to follow.
+# The recording shows it after, which is the only place it is worth anything.
+colourTest           | testPrograms/colourTest.asm        | run      | -                  | 200000
 # shiftTest calls printDecimal, which print.asm does not have. It looks like the
 # routine was renamed and this caller was never updated.
 shiftTest            | testPrograms/shiftTest.asm         | xfail    | -                  | -