Preserve original reads and side order
Assign a disk identifier and photograph labels and both sides. Record reader, physical drive, firmware and selected format. Keep the first dump unchanged with its log. Repeat reads where practical and compare results before selecting a master. Retain side ordering and any additional metadata rather than combining files by filename alone.
The FDSStick project page describes its reading and transfer route. FDSKey's original documentation describes another loader and physical-disk workflow. Follow the chosen tool's supported representation and hardware requirements. An FDS filename does not establish a complete flux capture or guarantee that copy-protection-related information was preserved.
Identify writable progress
Disk software can change disk contents when saving. Keep an untouched archival image and a clearly named playing copy. A backup taken before a session does not contain later progress. Follow the loader's documented commit behavior before switching games, removing its card or shutting down. FDSKey explicitly warns about allowing updated data to reach the card before power-off.
- Record edition, disk sides and visible progress.
- Preserve the current image before a write experiment.
- Use expendable media or a playing copy for a disposable save.
- Complete the documented write or commit sequence.
- Restart and verify actual in-game progress.
- Archive the changed image separately from the original master.
Do not overwrite the only surviving disk to test a restore. A physical write requires a documented compatible drive configuration; some transfer routes require hardware changes. Keep those changes and any write failure in the record. A read-only dump is not evidence that the same setup can safely write every disk.
Use an FDS-specific software build
A cartridge executable does not become a disk release by renaming it. Establish initialization, disk file layout, loading and side behavior using an actual FDS example. The original FDS bootloader example demonstrates a named FDS build workflow. Evaluate its required tools and target behavior, then build it unchanged before adapting it into an original project.
The FreeDiskSysROM project is a separate BIOS reimplementation with an explicit status table. Its goal is not proof that all intended disk-I/O functions are finished. If using a replacement BIOS, disclose the exact revision and tested APIs. Keep proprietary original BIOS data separate from redistributable homebrew unless permission allows inclusion.
Release verifiable results
Test boot, side changes, controls, sound, later loads and saving independently. Record results for emulator, virtual-disk loader and physical disks separately. Include source and asset licenses, tools, complete side layout, checksums and an acceptance sequence. A single successful emulator run does not establish physical write compatibility or mechanism alignment. See setup and drive service to keep those hardware questions distinct.