Give the screen back: osTakeScreen, and the RAM disk earns its keep

A program that takes the whole screen leaves the shell a blank one, and
whatever was on it is gone. There was nowhere to put 48K of video memory on
a machine with 64K of Data Memory that CosmOS already lives in.

A DRIVE MADE OF MEMORY IS SOMEWHERE. The screen goes to a file on the
scratch drive - the first volatile drive found at boot - like any other
file, and comes back from handleExit alongside the vectors and console mode
already put back there. The filesystem does the allocating, so this
invented nothing: it is 196 pages of tiles, map and palette, with a block
on the front holding the cursor, the four scroll registers and the mode.

NOT AUTOMATIC, and that is the whole design. Saving on every program start
would be cheap enough; restoring on every exit would be wrong, because dir
and Files and Say print and stop and their output is the reason you ran
them. A program says it took the screen, and one that says nothing behaves
exactly as every program did before this existed.

It deleted thirty lines of Grid, and they were all wrong anyway: four
scroll registers put back by hand, the map filled with spaces, the cursor
sent home, palette bank 0 written out - and the other fifteen banks kept
Grid's colours, because there was nowhere to have kept the real ones. Grid
is 64 bytes smaller and gives back what was actually there.

The check compares the screen before against the screen after, CELL BY
CELL, and allows only the rows around the cursor to differ - found from
where the text ends rather than guessed at, because the first version
assumed the cursor was near the bottom of the screen and let three real
differences through.

Two things cost time and neither was the feature:

  - An edit adding "SWI osTakeScreen" to Grid was in the same script as a
    failing s.index, so the file was never written - and the COMMENT
    describing the call did land, from a later edit. Grid documented a call
    it did not make, and read as though it should have worked.
  - docs.sh caught osTakeScreen having no row in the services table, which
    is the check the service layer added for exactly this and the second
    time it has earned itself.

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

Programs/CosmOS/Source/sbfs.asm

@@ -284,6 +284,9 @@ sbfsMountAll:
   SETD.1 SbfsDrive
   STA.1
   OUTA 0x24                 ; Drive 0, whatever the controller was left on.
+  INIA 0xFF
+  SETD.1 SbfsScratch1
+  STA.1                     ; No scratch drive until one is found.
 
   ; The live record belongs to nobody yet, so every slot starts empty and a drive that fails
   ; to mount keeps an empty one.
@@ -347,6 +350,26 @@ sbfsMountEach:
   BNQ sbfsMountNext
 
 sbfsMountGot:
+  ; ---- And whether this is the one to keep scratch on ----
+  ;
+  ; A volatile drive is somewhere the system may write without asking, because nothing on it
+  ; outlives the machine. The FIRST one found is the scratch drive; a machine with two has
+  ; made a decision nobody expressed, and taking the lower number is at least predictable.
+  INA 0x26
+  INIB 0x01
+  AND
+  BRQ sbfsMountNotScratch
+  SETD.1 SbfsScratch1
+  LDA.1
+  INIB 0xFF
+  CCF
+  SUB
+  BNQ sbfsMountNotScratch   ; There is one already.
+  SETD.1 SbfsDriveAt
+  LDA.1
+  SETD.1 SbfsScratch1
+  STA.1
+sbfsMountNotScratch:
 
   ; Mounted: remember which, and put the live record where it belongs.
   SETD.1 SbfsDriveAt
@@ -3661,6 +3684,10 @@ SbfsDriveCount:
   0x00
 SbfsDriveAt:
   0x00
+; Which drive the system may write scratch to, or 0xFF for a machine with none. It is a drive
+; the machine called volatile, so nothing written there was ever going to survive anyway.
+SbfsScratch1:
+  0xFF
 SbfsPathWanted:
   0x00