Michael Heilemann, The Norseman / The Viking — Field notes from the disk revival project: Apple II archiving
-=[ Every One of These Disks Is Fading ]=-
If you've ever tried to digitize an old Apple ][ floppy disk collection, finding the disks turns out to be the easy part. Trusting them is the hard part. A 40-year-old 5.25″ floppy can look perfectly fine and still be wrong: a flaky drive head, a marginal read, a sector that comes back as garbage without ever throwing an error. ADT Pro will happily hand you a .dsk file built out of that bad data, and you won't know it until the day you actually try to use it and get far enough in to hit the damaged data.
I recently picked up an old, broken Apple ][e to restore and pass along to someone who'll want to use it. It came with 170+ disks, most of which have data on both sides. Once I started looking at the machine itself, the problem list grew fast: a bad power supply, a drive that needed recalibrating, and a second drive that's going to need repair. The speed is running too low (-2632), and turning the grey pot doesn't change the drive speed. It's a Rana Elite 3, and if anyone reading this can help me fix the issue, I'd love to hear from you. I had one of these 40 years ago storing BBS data, and it burned in the Palisades fire, so getting this one running again means more to me than just fixing a random drive.
Before any of these 170+ disks (302 sides) go up anywhere (I may create a validated .dsk archive on the site here for download), every single image needs to be verified. Doing that by hand would take forever, and even then, I couldn't be sure I'd caught everything short of playing every game to completion. So I built a verification tool instead and leaned on AI to help me get it built faster than I could have working by myself.
What started out as a simple disk verification tool quickly turned into something more: a validation and repair tool. There are a lot of these disk images already floating around online, and it occurred to me that instead of treating every bad read as a dead end, I could cross-check against them.
-=[ The Golden Rule ]=-
One rule guided the design from the start: nothing that comes off a disk during ripping ever gets modified. Whatever lands in that first directory stays exactly as it arrived. That means the whole pipeline can be rerun on the same source data at any time. If something changes downstream, I can delete the working directories, original disks (disks that only have one scan), merged disks (merged from multiple scans), repaired disks, and downloaded reference disks, and regenerate everything from the untouched originals. More on how that works below and detailed in future blog posts that I hope to write and release once per week.
-=[ Why "It Copied Fine" Isn't Good Enough ]=-
A floppy disk transfer can succeed completely, byte for byte, sector for sector, with zero read errors reported, and still be wrong. A drive with a slightly dirty head, or a disk with one weak track, doesn't usually throw an error. It just reads back something. Sometimes that something is 256 bytes of whatever the controller returned when it gave up, zero-filled or padded, sitting right there in your .dsk file looking exactly as legitimate as every other sector around it.
A naive "did the transfer finish" check does not catch that. You need to understand the filesystem supposedly living inside those bytes: DOS 3.3's VTOC and catalog, ProDOS's directory tree. And you need to validate the data. Does this catalog entry's track/sector chain terminate? Does it point anywhere off the edge of the disk? Does the disk's own bookkeeping agree with what's sitting in those sectors? A disk can pass a checksum and still fail every one of those tests.
Once the physical disk itself degrades past the point of a clean read, and 40-year-old floppies do that on their own timeline, whatever's in the archive is what that title is, permanently. A silently corrupted disk image that nobody catches now can become the canonical, wrong copy of that game.
-=[ Why Did I Even Do This? ]=-
Mostly just to see if I could. Nobody asked for a verification and repair pipeline for a stack of 40-year-old floppies. There's no deadline, no client, no one waiting on it. Somewhere between parsing the VTOC and writing the bit map check, "can I build this" turned into "I want to build this right." Whether anyone else ever uses it is beside the point.
-=[ What This Series Covers ]=-
This is the first post in a 12-part series exploring the real pipeline built in layers, each layer earning its place by catching something the layer before it missed. Here's what's coming:
Part 1 (You are here): Every One of These Disks Is Fading.
Part 2: Wiring the Bridge: seriALL, a Floppy Emu, and Two Drives
Part 3: The Calibrated Capture: Why Every Disk Gets Read More Than Once
Part 4: Reading DOS 3.3 the Way DOS Does
Part 5: The Bit Map Doesn't Lie
Part 6: ProDOS, Briefly.
Part 7: Trust No Single Read: Consensus Repair
Part 8: Borrowing Bytes: Cross-Referencing Against the Archive
Part 9: Protected Disks, Honest Limits, and Shipping It
Part 10: Beyond Sectors: What Flux-Level Imaging Actually Captures
Part 11: Flux Capture Workflow: Weak Bits, Half-Tracks, and Multiple Revolutions
Part 12: Feeding Flux Evidence Into the Pipeline
-=[ Applying Archivist Principles ]=-
Every technique in this series is something a tape-recovery or bit-rot-conscious archivist would already recognize: multiple independent reads, majority voting, cross-referencing against known-good references, never trusting a single source. The only new part is applying it methodically, disk by disk, to a personal Apple II collection instead of doing what I suspect most of us have historically done: image it once, glance at the directory listing, and move on.
Next week: the hardware. What's plugged into what, why a Floppy Emu is standing in for a boot disk, and why two drives instead of one turned out to matter more than I expected.
Fair winds and following seas,
The Norseman