Name a drive in a path

"1:/notes", or "1:" on its own for wherever that drive already was. Done in
sbfsWalk, which is where every path in the system arrives - eight callers
between the shell, the config reader and the filesystem - so it works for
anything that takes a path rather than for whichever commands somebody
remembered to change.

NAMING A DRIVE GOES THERE AND STAYS THERE. Switching for the length of one
command and switching back reads better and cannot work: a path resolves to
a start block and a length, and those mean nothing without the drive they
were read from. A load that resolved on drive 1 and then read its blocks on
drive 0 would read the right blocks of the wrong disk.

A name beginning with a digit is still a name. The colon is the whole of
what tells them apart, and /2things is on the fixture disk to keep it that
way.

Two bugs, and the second is the interesting one.

SUB sets carry on a BORROW, so a character below '0' leaves it set - and
the test for "not a digit" branched on clear. Every prefix was ignored.

Then the leading-separator test reads the first character through DP0,
which sbfsPathDrive could not move because RET puts DP0 back the way it
found it. It advanced SbfsPathAt and DP0 still pointed at the digit, so
every prefixed path was judged relative and walked from the named drive's
working directory. IT ONLY SHOWED WHEN THAT DRIVE WAS STANDING SOMEWHERE
OTHER THAN ITS ROOT, because a relative walk from the root is an absolute
one - so "cd 1:/2things" worked from a fresh boot and failed after "cd
1:/notes". The test does it in that order for that reason.

Copying between two disks is still not one command: each path resolves on
its own drive and the drive stays where the last path left it. That wants
Copy to change drives between blocks.

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

Programs/CosmOS/Source/sbfs.asm

@@ -414,12 +414,118 @@ sbfsFindRoot:
   ADD
   RET
 
+; ---- Is there a drive on the front of this path, and can we go there? ----
+;
+; A digit and a colon. Q is zero if the path is usable, whether or not one was there; Q is one
+; if a drive was named and it is not one this machine can read, which makes the whole path
+; unfindable - because it is.
+;
+; NAMING A DRIVE GOES THERE AND STAYS THERE. The alternative was to switch for the operation
+; and switch back, which reads better in a listing and cannot work: what a path resolves to is
+; a start block and a length, and those mean nothing without the drive they were read from. A
+; load that resolved on drive 1 and then read on drive 0 would read the right blocks of the
+; wrong disk.
+sbfsPathDrive:
+  SETD.1 SbfsPathAt
+  LDD.0.1
+  LDA.0
+  INIB 0d48                 ; '0'
+  CCF
+  SUB
+  BRC sbfsPathNoDrive       ; Borrowed, so it is below '0' and not a digit.
+  MVQA
+  INIB 0d10
+  CCF
+  SUB
+  BNC sbfsPathNoDrive       ; Ten or more, so not a digit either.
+
+  ; The character after it has to be a colon, or this is a name that begins with a digit.
+  ; DP1 is still SbfsPathAt, from the top of this routine.
+  LDD.0.1
+  INCD.0
+  LDA.0
+  INIB 0d58                 ; ':'
+  CCF
+  SUB
+  BNQ sbfsPathNoDrive
+
+  ; It is a drive. Is it one this machine has, with something readable in it?
+  LDD.0.1
+  LDA.0
+  INIB 0d48
+  CCF
+  SUB
+  MVQA
+  SETD.1 SbfsPathWanted
+  STA.1
+  CALL sbfsDriveBit
+  MVQA
+  SETD.1 SbfsMounted
+  LDB.1
+  AND
+  BRQ sbfsPathBadDrive
+
+  SETD.1 SbfsPathWanted
+  LDA.1
+  CALL sbfsUse
+
+  ; Past the digit and the colon. What follows is an ordinary path, and a bare "1:" is an
+  ; empty one - which walks to where that drive already was.
+  SETD.1 SbfsPathAt
+  LDD.0.1
+  INCD.0
+  INCD.0
+  STD.0.1
+
+sbfsPathNoDrive:
+  RSTA
+  RSTB
+  CCF
+  ADD
+  RET
+
+sbfsPathBadDrive:
+  RSTA
+  INIB 0d1
+  CCF
+  ADD
+  RET
+
 ; The walk itself. Q is zero if the whole path was walked, and SbfsAt says where it ended -
 ; which may be the root, and that is an answer rather than a failure.
 sbfsWalk:
   SETD.1 SbfsPathAt
   STD.0.1
 
+  ; ---- A drive in front of the path ----
+  ;
+  ; Done here because this is where every path in the system arrives - eight callers between
+  ; the shell, the config reader and this file - so naming a drive works everywhere at once
+  ; rather than in whichever commands somebody remembered.
+  CALL sbfsPathDrive
+  BNQ sbfsWalkNoDrive
+
+  ; ---- And DP0 has to be told ----
+  ;
+  ; sbfsPathDrive moved SbfsPathAt past the digit and the colon, but RET put DP0 back the way
+  ; it found it - so the test below for a leading separator was reading the DIGIT and calling
+  ; every prefixed path relative. It only showed when the drive being named was standing
+  ; somewhere other than its root, because a relative walk from the root is an absolute one.
+  SETD.1 SbfsPathAt
+  LDD.0.1
+  BRI sbfsWalkPath
+
+; A drive that this machine cannot read makes the path unfindable, because it is: there is
+; nowhere for the rest of it to be.
+sbfsWalkNoDrive:
+  RSTA
+  INIB 0d1
+  CCF
+  ADD
+  RET
+
+sbfsWalkPath:
+
   ; Where it starts. A path beginning with a separator is measured from the root, which is
   ; zero because a parent is an entry index PLUS ONE and the root is not an entry.
   ; Anything else is measured from wherever the machine already is.
@@ -3381,6 +3487,8 @@ SbfsDriveCount:
   0x00
 SbfsDriveAt:
   0x00
+SbfsPathWanted:
+  0x00
 
 SbfsFileStart:
   0x00 0x00