The font comes from a chip, not from RAM that remembers

videoReset zeroed video memory and then wrote the font and the sixteen colour
schemes into it, and the comment above that said out loud what was wrong with
it: "everything here is ordinary video memory". RAM does not wake up with
anything in it. That was the last piece of magic in this device, and it looked
harmless until something wanted the font BACK - a program that redefines a glyph
had destroyed the only copy there was.

So the device has a character generator, the way the machines this one is
pretending to be really did, and the copy into RAM is a thing it DOES rather
than a state it mysteriously starts in. Command port 0x39: bit 0 for the font,
bit 1 for the schemes.

THE RAM IS STILL RAM. A program may overwrite every glyph and every colour and
should be able to, which is what makes this a tile engine rather than a text
display. What changed is that it is no longer a one way door.

NEITHER COMMAND CLEARS WHAT IT DOES NOT OWN. The font used to clear the whole of
tile memory before writing itself, which was harmless while it happened only at
reset and is wrong the moment a program can ask: a program that defined a tile
of its own and then wanted its text back would have paid for it with the tile.

The reason it is a chip rather than a file on the disk, which was the other
candidate: the boot chain prints before CosmOS exists. Stage one prints "?" when
there is nothing to boot, and if the font came off the disk then the message
about the disk having failed would be the one thing that could not be drawn. A
system that wants its own font still loads one over the top - the ROM is the
floor, not the policy.

Two things that had been worked around now simply work. The shell asks for both
whenever a program exits, so a program that redefined a letter no longer leaves
it unable to spell, and Grid no longer needs to have saved the screen to avoid
handing back green text on blue. And the fault screen asks for the glyphs first,
because a message spelled in somebody's tile graphics is no message at all.

Five video checks. Two runs each for the font and the schemes, since the map
holds a tile NUMBER and the glyph is looked up when the frame is drawn - so
restoring changes every cell using it, including ones drawn before, and what the
two runs differ by is the command. The third guards the decision not to clear:
tile 200 has to survive the font coming back.

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

Programs/CosmOS/README.md

@@ -633,6 +633,13 @@ returned to the prompt, and the program is recorded as having stopped rather tha
 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 glyphs and the colours come back too.** A program is as free to redefine a letter as
+any other tile, so one that did has left the shell unable to spell, and one that wrote its
+own palette used to hand back green text on blue. Both were permanent until the video device
+grew a character generator to ask. The shell asks for both whenever a program exits, before
+restoring a saved screen, so a program that saved one still gets back what was actually on
+it and a program that saved nothing at least leaves something readable.
+
 **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

Programs/CosmOS/Source/cosmos.asm

@@ -1442,6 +1442,12 @@ faultScreen:
   ; have left every ink the same as every paper. Attribute one draws in palette entries 16
   ; and 17, so those two are written and the rest of the program's colours are left alone -
   ; there is nothing to be gained here by taking away more than is needed.
+  ; The glyphs first, since a program is as free to redefine a letter as any other tile and
+  ; a message spelled in somebody's tile graphics is no message at all. It touches only the
+  ; console's own tiles, so a program's are left where they are.
+  INIA 0x01
+  OUTA 0x39
+
   CALL screenBank
   INIA 0d4
   OUTA 0xE3
@@ -3177,6 +3183,20 @@ screenSane:
   RSTA
   OUTA 0x37
   OUTA 0x38                 ; No fraction of a cell in either direction.
+
+  ; ---- And glyphs and colours that can be read ----
+  ;
+  ; A program may redefine any tile and any colour, and the font lives in tiles like anything
+  ; else - so a program that redefined a letter has left the shell unable to spell, and one
+  ; that wrote its own palette handed back green text on blue. Both used to be permanent:
+  ; there was nowhere to get the originals from, because the only copy was the one that had
+  ; been drawn over. The device has a character generator now and this is what it is for.
+  ;
+  ; BEFORE screenGive, like everything else here, so that a program which SAVED the screen
+  ; gets back what was actually on it rather than what a clean machine looks like. This is
+  ; the floor for the programs that saved nothing.
+  INIA 0x03
+  OUTA 0x39
   RET
 
 ; Video memory as bank 4, which is what makes it reachable at all. Bank 3 is the disk's; see

Programs/Examples/tune.asm

@@ -37,6 +37,10 @@
 
 #Program
 
+#Include services.asm
+
+#Base 0x4000
+
 start:
 
   ; ---- The instrument ----
@@ -182,7 +186,7 @@ lastRing:
   CIF
   RSTA
   OUTA 0x35
-  HALT
+  SWI osExit
 
 ; Sixty times a second, and it has nothing to do. WAIT only needs something to have happened,
 ; and this is the something. A handler still has to exist: an interrupt with nothing installed
@@ -192,6 +196,8 @@ frame:
 
 #Data
 
+#Base 0x2000
+
 ; ---- Notes and how long they last ----
 ;
 ; Pairs: a MIDI note, then a count of frames. 60 is middle C and every 12 is an octave. A zero