Give the disk four drives, behind one controller

SEVERAL DISKS ARE ONE CONTROLLER AND NOT SEVERAL DEVICES, and the
instruction set decided that rather than taste. A port is an immediate byte
inside the OUT that names it - portOut takes it from Program Memory - so a
program cannot compute one. "The disk on port 0x20 plus drive times four"
is not something this machine can say, and two disks as two devices would
mean a branch on the drive number in all eleven places sbfs.asm names a
disk port. A drive register is what a floppy controller has always been.

  0x24  Drive, which the block, command and status registers refer to
  0x25  Drives, read only: how many are plugged in

--disk given more than once fills them in order. What is per drive is the
image, its size and its write protection; the block register, the status
and the one buffer belong to the controller, which is the same division
real hardware makes.

A drive that is not there is refused rather than wrapped, because wrapping
means a program asking for a drive this machine has not got quietly reading
the one it has - the same shape of fault as taking a bank number somebody
else was using. An EMPTY drive is a different thing and is selectable: a
controller has its drives whether or not there are disks in them, and
reading one fails with the error bit the way an empty drive should.

Changing drives finishes whatever the one being left was in the middle of.
A transfer waits for the clock, so one may be owed at any moment, and
running it against the disk that is arriving would be a fault with no
owner.

Also stops parseOptions setting its defaults field by field. It was nine
assignments beside a struct, and a list beside a thing drifts from the
thing: adding two fields left them holding whatever was on the stack, so a
machine given one disk was told it already had four drives. It is one
zeroing now, and a default that is not nought can be written under it where
it reads as the exception. That struct growing a field once before left
Voyager linked against an object that disagreed about its size.

Nothing in CosmOS uses any of this yet. The mount record is next.

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

Source/Emulator/io.h

@@ -66,11 +66,29 @@
 // that spans more than one port raises its line on its base, which is the rule the
 // machine has not needed until now: the controller spans sixteen and never interrupts.
 #define PORT_DISK        0x20
-#define PORT_DISK_TOP    0x23
+#define PORT_DISK_TOP    0x25
 #define DISK_BLOCK_HIGH  0x20
 #define DISK_BLOCK_LOW   0x21
 #define DISK_COMMAND     0x22
 #define DISK_STATUS      0x23
+
+// ---- Several disks, one controller ----
+//
+// NOT SEVERAL DEVICES, and the instruction set is why. A port is an immediate byte inside the
+// OUT that names it, so a program cannot compute one - "the disk on port 0x20 + drive * 4" is
+// not something this machine can say. Two disks as two devices would mean a branch per access
+// in every one of the eleven places the filesystem names a disk port.
+//
+// So it is one controller with a drive register, which is what the machines this one is
+// pretending to be actually had: one floppy controller and four drives behind it. The block,
+// command and status registers all refer to whichever drive was last selected, and so does
+// the single buffer - which is honest, and which means a program that changes drives knows
+// the buffer no longer holds what it thought.
+#define DISK_DRIVE       0x24
+#define DISK_DRIVES      0x25
+
+// Four is a floppy controller's worth. The cost of another is a file handle.
+#define DISK_DRIVE_COUNT 4
 // ---- The screen ----
 //
 // Sixteen ports, like the controller, and it interrupts on its base the way the disk