CosmOS knows about all four drives

A mounted disk is EIGHT BYTES - where its directory starts, how many
blocks it is, how big the disk is, and where you are on it. They now sit
together in the data segment, and changing drives is one copy out and one
copy in. The other three thousand lines of filesystem go on reading the
same four names they always have and never learn there is more than one
disk, which is the whole reason this was affordable.

The version is not in the record. It is checked at mount and thrown away,
because a version one disk's zero parent already reads as "in the root".

Every drive is mounted at boot: the controller says how many are plugged
in and each is tried in turn. One with nothing in it, or a disk this
cannot read, is left unmounted rather than stopping the others, so a
machine with a good disk in drive 0 and a blank in drive 1 starts.

'drive' says which one, 'drive 1' goes to another, and the working
directory goes with it - where you are on a disk is part of which disk you
are on. A drive the machine has not got is refused, and refused
differently from one that is there with nothing readable in it.

Three things the assembly caught me on, all the same misunderstanding of
what survives a call:

  - OR reads A and B, and the bit came back from sbfsDriveBit in Q, which
    RET does not disturb - but RET does put A back. The mounted mask never
    got set and drive 0 was reported unmountable.
  - MVQA then RSTA throws away the copy it just made, so doubling a bit
    doubled nothing. SHL does it in one instruction, because A and B are
    one register to it.
  - There is no move from A to B. INB reads a port straight into B, which
    is what the drive count comparison wanted.

run.sh takes more than one image now, separated by a plus, since the
machine has four drives and a test that could only name one could not
check any of this.

The buffer note is forgotten on a drive change and that is DELIBERATELY
kept although nothing can currently reach it: only the file read-ahead
consults it, a directory scan does not, and finding a file requires a
scan which overwrites the note on the way past. Two disks were built with
the same file at the same block to try to catch it and the answer was
right either way. Three instructions to hold an invariant rather than a
story about a bug - and the comment says so instead of claiming a fix.

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

Programs/CosmOS/Source/cosmos.asm

@@ -77,7 +77,7 @@ boot:
   ; Find out whether there is a filesystem to talk to. Doing this once at boot rather than
   ; once per command means a disk swapped underneath us is not noticed, which is honest
   ; for a machine whose disk is a file named on the command line.
-  CALL sbfsMount
+  CALL sbfsMountAll
   SETD.0 DiskReady
   BNQ bootNoDisk
   INIA 0x01
@@ -259,6 +259,11 @@ promptWhere:
   CALL textSame
   BRQ doRename
 
+  SETD.0 CommandLine
+  SETD.1 DriveName
+  CALL textSame
+  BRQ doDrive
+
   SETD.0 CommandLine
   SETD.1 ClearName
   CALL textSame
@@ -1658,6 +1663,67 @@ fileComplain:
   CALL newLine
   BRI commandFailed
 
+; ---- drive ----
+;
+; Which disk the shell is standing on. With nothing after it, says which; with a number, goes
+; there - and the working directory goes with it, because where you are on a disk is part of
+; which disk you are on rather than something the shell keeps on the side.
+doDrive:
+  SETD.1 TextRest
+  LDD.0.1
+  LDA.0
+  BRA driveSay
+
+  ; One digit. Anything else is not a drive number, and the machines this is imitating never
+  ; had ten drives either.
+  INIB 0d48
+  CCF
+  SUB
+  MVQA
+  INIB 0d10
+  CCF
+  SUB
+  BNC driveNoSuch           ; Ten or more, so it was not a digit at all.
+
+  ; Is there such a drive on this machine?
+  SETD.1 DriveWanted
+  STA.1
+  INB 0x25                  ; How many drives, straight into B: there is no move from A to it.
+  LDA.1
+  CCF
+  SUB                       ; Borrows when the wanted one is inside the count.
+  BNC driveNoSuch
+
+  ; And is there anything readable in it? A drive with no disk is a real drive and an empty
+  ; one, so this is a different answer from "there is no such drive".
+  CALL sbfsDriveBit
+  MVQA
+  SETD.1 SbfsMounted
+  LDB.1
+  AND
+  BRQ driveNotReadable
+
+  SETD.1 DriveWanted
+  LDA.1
+  CALL sbfsUse
+  BRI prompt
+
+driveSay:
+  INA 0x24
+  INIB 0d48
+  CCF
+  ADD
+  OUTQ 0x00
+  CALL newLine
+  BRI prompt
+
+driveNoSuch:
+  SETD.0 DriveNoSuch
+  BRI fileComplain
+driveNotReadable:
+  SETD.0 DriveNotReadable
+  BRI fileComplain
+
 ; ---- clear ----
 ;
 ; The console has done this since before there was a screen to do it on: writing 1 to the
@@ -3703,6 +3769,8 @@ PromptText:
 ; not what went wrong, and what went wrong has already been said in words.
 LineFailed:
   0x00
+DriveWanted:
+  0x00
 
 
 LastStatus:
@@ -3721,6 +3789,10 @@ ScriptNotOne:
 "do: that is not a script - it wants #! on the first line"
 ScriptTooDeep:
 "do: scripts are only four deep"
+DriveNoSuch:
+"drive: this machine has no such drive"
+DriveNotReadable:
+"drive: nothing this can read is in that drive"
 StartupName:
 "/System/Boot/startup.sh"
 StartupNotOne:
@@ -3916,6 +3988,8 @@ EchoName:
 "echo"
 ClearName:
 "clear"
+DriveName:
+"drive"
 LoadName:
 "load"
 RunName: