scsi: unify A2091/A4091 into a [scsi] controller picker

[codewiz]

Folds the two SCSI host adapters into a single [scsi] section with a
controller key, and surfaces it in the launcher as a one-of picker instead of
a second seven-drive block.

Config

[a4091] is gone. [scsi] gains controller = "a2091" | "a4091" (default
"a2091", so every existing [scsi] config keeps working untouched):

[scsi]
controller = "a4091"   # or "a2091" (default)
rom = "a4091.rom"
unit0 = "workbench.hdf"

• ScsiConfig gains a ScsiController enum; emulator.rs switches on it to
  build one board, replacing the two independent if cfg.scsi.enabled() /
  if cfg.a4091.enabled() blocks.
• rom_odd (the A2091 split even/odd EPROM half) is validated as A2091-only;
  the A4091 has a single ROM.
• Hard cut: [a4091] is removed rather than kept as an alias. The feature only
  just landed (A4091 Zorro III SCSI controller: 53C710 model, SCRIPTS phase engine, drives scan and mount #123), so its install base is ~nil and the migration is a
  one-line rename.

Launcher

A "SCSI controller" cycle (None -> A2091 (Z2) -> A4091 (Z3)) on the Hard Disk
tab drives the shared boot-ROM + unit rows. With no controller the ROM and
drives grey out ("no controller"); rom_odd greys unless A2091. The tab stays
at its current length.

Design choice: mutually exclusive, not independent

The engine can genuinely run both boards at once -- they are separate Zorro
autoconfig cards (A2091 is Zorro II, A4091 is Zorro III), each in its own slot,
and before this change the config exposed both [scsi] and [a4091]
simultaneously. So "one controller" is a deliberate UI/config simplification,
not an engine limitation.

The alternative considered was keeping both boards independently
configurable and adding a full A4091 section to the launcher: its own boot-ROM
row plus seven more unit rows. That is the most faithful to the hardware (you
could physically plug both), but it nearly doubles the Hard Disk tab -- 11 rows
to ~19 -- for a configuration essentially nobody runs (two SCSI HBAs in one
machine). The clutter falls on every user to serve a rounding-error use case.

Why mutually exclusive won:

• No round-trip hazard. The launcher both reads and writes configs. If the
  config could express two controllers but the UI could only show one, loading
  a two-board config and saving it would silently drop a board. Collapsing to a
  single [scsi] controller gives the config and the UI identical expressive
  power, so a save can never lose data -- the round-trip is correct by
  construction rather than by a documented caveat.
• Compact by default. One picker plus the existing ROM/unit rows; the second
  controller costs zero extra rows. Progressive greying keeps even the populated
  case legible.
• Matches real use. A machine has one SCSI controller. The picker mirrors how
  people actually configure these boards (pick your HBA, attach drives).

The cost is that the rare "both at once" setup is no longer expressible. Given
it was brand-new, undocumented in the example config, and of no practical
demand, that is a good trade for a clean single-controller model end to end.

Testing

• cargo build, full cargo test (config + scsi suites), and cargo clippy
  all clean.
• Manually verified in the launcher GUI: the SCSI controller picker cycles
  None -> A2091 (Z2) -> A4091 (Z3); the ROM/unit rows grey with no controller
  and rom_odd greys unless A2091; the config round-trips (saving writes the
  expected [scsi] controller/rom/units and reloads correctly); and a machine
  booted with a selected controller.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR consolidates the A2091 and A4091 SCSI adapters into a single [scsi] configuration section by introducing a controller selector, and updates the launcher and emulator wiring so only one SCSI controller is configured/instantiated at a time.

Changes:

• Add ScsiController enum and [scsi].controller parsing/validation; remove the legacy [a4091] section.
• Update machine construction to instantiate either A2091 or A4091 based on cfg.scsi.controller, reusing shared drive plumbing.
• Update the launcher Hard Disk tab to include a “SCSI controller” cycle picker and to gray out SCSI ROM/unit fields when no controller is selected.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/video/launcher.rs	Adds a SCSI controller picker and emits [scsi] only when a controller is selected.
src/emulator.rs	Switches SCSI board instantiation to a single [scsi] path keyed by ScsiController.
src/config.rs	Introduces ScsiController, adds [scsi].controller parsing, and removes [a4091] support.
copperline.example.toml	Updates example documentation/comments for the new unified [scsi] configuration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codewiz]

@LinuxJedi let me know what you think of the current design of making A2091 and A4091 mutually exclusive.

Claude initially tried to support both at the same time by duplicating the 7 SCSI units, but it resulted in UI clutter.

Amiberry (and WinUAE, likely) takes a different approach: there's a top-level list of drives, and each one can be mapped to a controller and a target ID via drop-downs. To keep things simple, there's also an "auto" option.

The Amiberry way becomes important to support complex configurations with multiple contropllers, physical devices, CD changers and all that. Probably not worth it if you're planning to keep the Copperline UX simple and usable.

[LinuxJedi]

@LinuxJedi let me know what you think of the current design of making A2091 and A4091 mutually exclusive.

Claude initially tried to support both at the same time by duplicating the 7 SCSI units, but it resulted in UI clutter.

Amiberry (and WinUAE, likely) takes a different approach: there's a top-level list of drives, and each one can be mapped to a controller and a target ID via drop-downs. To keep things simple, there's also an "auto" option.

The Amiberry way becomes important to support complex configurations with multiple contropllers, physical devices, CD changers and all that. Probably not worth it if you're planning to keep the Copperline UX simple and usable.

I agree. For now lets keep it simple. If someone comes up with a real use case for supporting both at the same time, we can revisit.

[LinuxJedi]

Looks like you tmp/ and cap_%d. I don't think they should be here.

[codewiz]

Looks like you tmp/ and cap_%d. I don't think they should be here.

Ooopsie! I could blame Claude, but the truth is that I was sleeping on the helm: I approved a git add -A without looking at the output.

[LinuxJedi]

Looks like you tmp/ and cap_%d. I don't think they should be here.

Ooopsie! I could blame Claude, but the truth is that I was sleeping on the helm: I approved a git add -A without looking at the output.

No problem. We have all done it at some point. I even saw Fable accidentally add target/ in one bit of code it was trying to commit for me :)

[LinuxJedi]

Looks great! Many thanks.