Grid took the disk's bank number, and gave the screen back untidy

Found by playing with it: after running Grid, the shell could not start
anything by name and dir said the disk was empty. Several commands after
the program that did it had exited, and nothing had said a word.

BANK NUMBERS ARE ONE NAMESPACE FOR THE WHOLE MACHINE. Grid registered video
memory as bank 3, which is the number CosmOS gives the disk's buffer when
it mounts - and that does not fail, it succeeds. Every read the filesystem
made afterwards came out of video memory. Grid uses 4 now, and the CosmOS
README has a table of who owns what, because the one place this was written
down was a line in a service description about sbfsMount.

Nothing hands bank numbers out and nothing refuses one that is taken. If
programs start wanting banks routinely, a service that allocates them is
what should exist rather than a longer table - noted there rather than
built, since one program wanting one bank is not yet a system.

Also puts the cursor home on the way out. The map was emptied and the
console was not told, so the shell carried on writing from wherever the
cursor had been standing when Grid started - twelve rows down a screen with
nothing on it. Clearing is what homes a cursor and it costs one write.

The regression test runs a program by name, then Grid, then the same
program again; the second one is the check. Putting Grid back on bank 3
fails it.

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

Programs/CosmOS/Apps/Grid.asm

@@ -30,7 +30,14 @@ start:
   ;
   ; The CPU cannot touch it. It belongs to the device, and the only way in is to give it a
   ; bank number and go through the memory controller - the same as the disk's buffer.
-  INIA 0d3
+  ;
+  ; FOUR, BECAUSE THREE IS THE DISK'S. Bank numbers are one namespace for the whole machine
+  ; and nothing hands them out: 0 is Program Memory, 1 is Data, 2 is the bank table, and
+  ; CosmOS gives 3 to the disk's buffer when it mounts. This asked for 3, which does not
+  ; fail - it succeeds, and the disk's buffer quietly becomes the screen. Every read the
+  ; filesystem made after that came out of video memory, so the shell found an empty disk
+  ; and could not start anything by name. Nothing said a word.
+  INIA 0d4
   OUTA 0xE3                 ; DestBank: the number it will answer to.
   INIA 0x30
   OUTA 0xE2                 ; SourceLow: the port of the device that owns it.
@@ -123,7 +130,7 @@ finished:
   ; grid underneath its own output.
   OUTA 0x34                 ; A is still nought, from the three above.
 
-  INIA 0d3
+  INIA 0d4
   OUTA 0xE3
   INIA 0x40
   OUTA 0xE4
@@ -137,6 +144,15 @@ finished:
   INIA 0x02
   OUTA 0xE8                 ; Fill.
 
+  ; ---- And the cursor back to the top ----
+  ;
+  ; The Fill above empties the map and says nothing to the console about it, so the shell
+  ; carried on writing from wherever the cursor had been left standing when this program
+  ; started - part way down a screen that no longer has anything on it. Clearing is what
+  ; puts a cursor home, and it costs one write.
+  INIA 0x01
+  OUTA 0x05
+
   ; ---- And the colours it woke up with ----
   ;
   ; Only the first pair, and that is worth being honest about. The console's own scheme is
@@ -154,7 +170,7 @@ finished:
   ; THE REAL ANSWER IS A COMMAND TO THE SCREEN saying "give me back what you woke up with",
   ; the same way the console has one for clearing. There is not one, and this program is the
   ; first thing that ever wanted it.
-  INIA 0d3
+  INIA 0d4
   OUTA 0xE3
   INIA 0xFC
   OUTA 0xE4
@@ -206,7 +222,7 @@ putTile:
   INCD.1
   LDA.1
   OUTA 0xE2
-  INIA 0d3
+  INIA 0d4
   OUTA 0xE3
   INIA 0x32
   OUTA 0xE4
@@ -239,7 +255,7 @@ putTile:
 ; writes with no arithmetic in it at all. The colours that change do so by adding sixteen to
 ; a running value, which is the same reason.
 putPalette:
-  INIA 0d3
+  INIA 0d4
   OUTA 0xE3
   INIA 0xFC
   OUTA 0xE4
@@ -330,7 +346,7 @@ putMap:
   STA.0
 
 everyRow:
-  INIA 0d3
+  INIA 0d4
   OUTA 0xE3
   SETD.0 MapRow
   LDA.0

Programs/CosmOS/README.md

@@ -797,6 +797,31 @@ An application may also include its own libraries or access hardware ports direc
 The services are an interface offered by the system, not the only way software is allowed
 to use the computer.
 
+### Bank Numbers Are One Namespace:
+
+A program that wants a device's memory registers it as a bank, and **bank numbers belong to
+the whole machine**. Nothing hands them out and nothing refuses a number that is already
+spoken for - registering one that is taken does not fail, it succeeds, and whatever held it
+before quietly answers to nothing.
+
+| Bank | Whose |
+| --- | --- |
+| 0 | Program Memory. The machine's. |
+| 1 | Data Memory. The machine's. |
+| 2 | The bank table. The machine's. |
+| 3 | The disk's buffer, given at mount by `sbfsMount`. CosmOS needs it for as long as it is running. |
+| 4 and up | Free for a program to use. |
+
+`Grid` learned this the hard way and is the reason the table is here. It asked for 3, took the
+disk's buffer, and every read the filesystem made afterwards came out of video memory - so the
+shell found an empty disk and could not start anything by name, several commands after the
+program that did it had exited. Nothing said a word, because from the controller's point of
+view nothing went wrong.
+
+**A program returns a bank by giving it back**, which today means knowing what was there
+before. There is no service that hands out a free number, and if this becomes a common thing
+for programs to want then that is what should exist rather than a longer table.
+
 ## What A Program May Ask The System For:
 
 A loaded program is on its own hardware and can do anything the machine can do - it is a fence, not a wall. But the things it usually wants are things the system is already doing, and asking is both shorter and the only way to reach code that was assembled separately. `CALL` needs a label, and a label has to be in the same assembly; `SWI` needs only a number both sides agree on.