Implement MOUNT/IMGMOUNT/BOOT batch commands, FAT12/16/32 floppy support, multi-image disc switching, 8272A FDC emulation, CDDA, virtual images, write-back, MSCDEX rework, correct BIOS/DOS layering via IFloppyDriveAccess, and full UI integration

[Copilot]

Description of Changes

• FAT12 floppy image parsing (BiosParameterBlock, FatDirectoryEntry, Fat12FileSystem) with full cluster-chain traversal
• FAT16/FAT32 support: FatFileSystem with FatType enum; Microsoft-spec cluster-count type detection; correct cluster arithmetic for all three FAT variants
• Robust floppy image mounting: FloppyDiskDrive.ApplyCurrentImage() now uses FatFileSystem (FAT12/16/32 auto-detection) instead of the FAT12-only Fat12FileSystem, preventing OverflowException crashes when mounting larger or non-standard floppy images (e.g. FAT16 images with >4084 clusters); defensive overflow guards added to FatFileSystem.ReadFat() and DetectFatType() for degenerate BPB values; Dos.MountImageAsFloppy() catches InvalidDataException/IOException and logs a user-readable error instead of crashing
• Per-image dirty tracking: FloppyDiskDrive image list stores (byte[], string, bool isDirty) tuples; MarkDirty(), IsDirty, and FlushToDisk() operate per-image and reset on image swap
• ISoundChannelCreator interface: Dos, DosBatchExecutionEngine, and DosProcessManager depend on ISoundChannelCreator (implemented by SoftwareMixer) instead of a nullable SoftwareMixer?; CD audio player is wired for UI-mounted CD-ROM drives
• Drive-change batch command (X:): DosBatchExecutionEngine recognises bare drive-letter tokens (e.g. C:) as drive-change commands, matching DOSBox Staging
• BOOT batch command for floppy images (DOSBox Staging parity): new BootCommandHandler and BootFloppyLaunchRequest; TryHandleBoot parses BOOT [image...] [-l A|B], mounts an image on-the-fly when a path is supplied, validates the 0xAA55 boot signature, and rejects hard-disk drive letters (HDD images explicitly out of scope per task). DosProcessManager.BootFromFloppy writes sector 0 to physical 0x7C00 and sets up CPU registers per BIOS bootstrap convention (CS:IP=0000:7C00, SS:SP=0000:7C00, DL=0/1, BX=7C00, CX=1, IF=1) - matching DOSBox Staging boot.cpp. DosProgramLoader.LoadLaunchRequest dispatches the new request after AUTOEXEC.BAT
• MscdexService duplicate-entry prevention: AddDrive() replaces any existing entry for the same drive letter
• CD-ROM drive status canonicalisation: Dos.GetDriveStatuses() no longer returns both a Fixed and a CdRom entry for MSCDEX-mounted CD letters, fixing a UI bug that caused repeating "ejected"/"mounted" toast notifications every poll tick
• SeekOnly guard in FloppyDiskNoiseDevice.ActivateSpin() and AddSamplesNormalized in FloppySoundEmulator for correct floppy noise behaviour
• Embedded floppy WAV resources shipped as EmbeddedResource items in Spice86.Core
• Full UI integration: drive menu with HDD entries, mount-folder/mount-image buttons, file filters, drive labels, polling-based status indicators (IDriveStatusProvider), Avalonia toast notifications for drive events, multi-image disc switching via Ctrl-F4 (IDiscSwapper)

Rationale behind Changes

DOS games and tools commonly require FAT12/16 floppy images, ISO/CUE+BIN CD-ROMs, MSCDEX, and MOUNT/IMGMOUNT/BOOT batch commands to install and run. Spice86 previously only supported a host-folder shell drive, which prevented running titles that bootstrap from raw floppy/CD images, switch discs mid-game, or rely on a real DOS bootstrap (e.g. boot sectors). Aligning the storage stack and batch command surface with DOSBox Staging makes those workflows possible while keeping clean architectural boundaries (BIOS depends only on IFloppyDriveAccess, MSCDEX is owned by DOS, UI uses polling).

Suggested Testing Steps

• Run dotnet test tests/Spice86.Tests - 1962 tests pass
• Mount a FAT16 floppy image (e.g. Exodus.img, ~3 MB) via the Drives menu and verify directory listing / file open
• In a batch file or --CDrive'd folder run MOUNT D /path/to/folder, IMGMOUNT D "C:\my games\disc.iso" -t iso, and BOOT image.img -l A to verify drive-letter, image, and boot bootstrapping
• Mount/unmount a CD-ROM repeatedly from the UI and confirm only a single set of toast notifications fires (no repeating eject/mount loop)
• Insert/eject multiple images on a single floppy or CD drive and use Ctrl-F4 to swap, confirming dirty state is preserved per image

[maximilien-noal]

@copilot implement full emulated floppy disk drive support, including images, fat understanding, UI controls and indicators for the drives and with full TDD driven developpement.

All from:

https://github.com/dosbox-staging/dosbox-staging

Respect OOP, SRP, and our way of writing code.

And the mscdex is not a service. It is owned by dos and provided by DOS via a Spice.Shared interface. The UI always use polling to get updates.

[maximilien-noal]

// ---------- internals ----------

Avoid such comments

MscdexService is mandatory, not nullable.

Seems like sometimes services are injected but not actually used ?

[maximilien-noal]

@copilot It's weird for the bios layer to depend on DOS, how does dosbox staging does it ?

https://github.com/dosbox-staging/dosbox-staging

[maximilien-noal]

@copilot reveiw and fix everything by comparing with https://github.com/dosbox-staging/dosbox-staging

Without going out of scope. Focus on CDs, folders as hard drives, UI toast notifications repeating when mounting an ISO.

[Copilot]

@copilot reveiw and fix everything by comparing with https://github.com/dosbox-staging/dosbox-staging

Without going out of scope. Focus on CDs, folders as hard drives, UI toast not...

Focused on the concrete repeating-toast bug for CDs in c0cdc21.

Root cause: Dos.GetDriveStatuses() returned two entries for an MSCDEX-mounted CD-ROM letter — one as Fixed (from the _driveMap iteration, since RegisterCdRomDriveLetter inserts the letter there for D: drive-change support) and one as CdRom (from the MSCDEX iteration). The two entries had different CurrentImagePath values (empty vs. real path), so each 1 s poll tick in DrivesMenuViewModel.NotifyIfChanged alternated between them, firing "ejected" then "mounted" toasts forever.

Fix: collect MSCDEX drive letters first, then skip those letters from the _driveMap iteration so only the canonical CdRom status is emitted. Folder-as-CD (MountFolderAsCdRom) and image-as-CD (MountImageAsCdRom) both go through this path, and DOSBox Staging similarly surfaces a CD-ROM as a single drive-table entry rather than a Fixed+CdRom pair. All 1953 tests still pass.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• av-build-tel-api-v1.avaloniaui.net
  • Triggering command: /usr/share/dotnet/dotnet dotnet exec --runtimeconfig /home/REDACTED/.nuget/packages/avalonia.buildservices/11.3.2/tools/netstandard2.0/runtimeconfig.json /home/REDACTED/.nuget/packages/avalonia.buildservices/11.3.2/tools/netstandard2.0/Avalonia.BuildServices.Collector.dll (dns block)
• https://api.github.com/repos/microsoft/kiota/releases
  • Triggering command: /tmp/Spice86.Tests/Tools/Kiota/kiota /tmp/Spice86.Tests/Tools/Kiota/kiota info -d /tmp/Spice86.Tests/HttpApiGeneratedClient/e967631e50e1487cae428520de91292f/openapi.json -l CSharp (http block)
  • Triggering command: /tmp/Spice86.Tests/Tools/Kiota/kiota /tmp/Spice86.Tests/Tools/Kiota/kiota generate -l CSharp -d /tmp/Spice86.Tests/HttpApiGeneratedClient/e967631e50e1487cae428520de91292f/openapi.json -c Spice86HttpApiClient -n Spice86.Generated.HttpApi -o /tmp/Spice86.Tests/HttpApiGeneratedClient/e967631e50e1487cae428520de91292f/Client --clean-output (http block)
  • Triggering command: /tmp/Spice86.Tests/Tools/Kiota/kiota /tmp/Spice86.Tests/Tools/Kiota/kiota info -d /tmp/Spice86.Tests/HttpApiGeneratedClient/90234de47bdf412dba9c0bea0d2b3cdd/openapi.yaml -l CSharp (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[maximilien-noal]

@copilot working with https://github.com/dosbox-staging/dosbox-staging and our path for BIOS file support in consideration, support fully the BOOT.COM command when booting a flopy image.

(Ignore booting on a hard disk drive image, and hard disk drive images too)

[Copilot]

@copilot working with https://github.com/dosbox-staging/dosbox-staging and our path for BIOS file support in consideration, support fully the BOOT.COM command when booting a flopy image.

(Ignore boot...

Implemented BOOT [image...] [-l A|B] in commit e2a9026, matching DOSBox Staging's floppy boot path.

Production:

• BootFloppyLaunchRequest flows the chosen drive letter through the batch pipeline.
• BootCommandHandler registered next to MOUNT/IMGMOUNT; TryHandleBoot parses optional inline image paths (mounts via MountFloppyImage + AddFloppyImage for swap chains), validates the 0xAA55 signature, rejects hard-disk letters per the scope you specified.
• DosProcessManager.BootFromFloppy(driveLetter) loads the 512-byte sector into physical 0x7C00 and sets BIOS bootstrap registers: CS:IP=0000:7C00, SS:SP=0000:7C00, DL=0|1, BX=0x7C00, CX=1, others cleared, IF=1 — matches dosbox-staging boot.cpp.
• DosProgramLoader.LoadLaunchRequest dispatches the new request so the CPU resumes at 0:7C00 after AUTOEXEC.

TDD: 9 new tests cover sector placement, register layout for A: and B:, signature validation, hard-disk rejection, and end-to-end batch-engine wiring (BatchEngine_BootCommand_*). Full suite still green (1962 passed).

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• av-build-tel-api-v1.avaloniaui.net
  • Triggering command: /usr/share/dotnet/dotnet dotnet exec --runtimeconfig /home/REDACTED/.nuget/packages/avalonia.buildservices/11.3.2/tools/netstandard2.0/runtimeconfig.json /home/REDACTED/.nuget/packages/avalonia.buildservices/11.3.2/tools/netstandard2.0/Avalonia.BuildServices.Collector.dll (dns block)
• https://api.github.com/repos/microsoft/kiota/releases
  • Triggering command: /tmp/Spice86.Tests/Tools/Kiota/kiota /tmp/Spice86.Tests/Tools/Kiota/kiota info -d /tmp/Spice86.Tests/HttpApiGeneratedClient/11240378778e474eb336dd7c81656c7d/openapi.json -l CSharp (http block)
  • Triggering command: /tmp/Spice86.Tests/Tools/Kiota/kiota /tmp/Spice86.Tests/Tools/Kiota/kiota generate -l CSharp -d /tmp/Spice86.Tests/HttpApiGeneratedClient/11240378778e474eb336dd7c81656c7d/openapi.json -c Spice86HttpApiClient -n Spice86.Generated.HttpApi -o /tmp/Spice86.Tests/HttpApiGeneratedClient/11240378778e474eb336dd7c81656c7d/Client --clean-output (http block)
  • Triggering command: /tmp/Spice86.Tests/Tools/Kiota/kiota /tmp/Spice86.Tests/Tools/Kiota/kiota info -d /tmp/Spice86.Tests/HttpApiGeneratedClient/4a8eae4094784b62b2def0e9fb33ecde/openapi.yaml -l CSharp (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)