DEVICE: GreaseWeazle 4.1
   DRIVE: TEAC FD-55BR
   SUITE: FluxEngine (decoder.retries=various, drive.revolutions=various)
ARCHIVER: Lee Smallbone
ARCHIVED: 2026-05-26 13:00 (GMT/UTC)

NOTES: 
Disk from a large (200+) disk collection purchased from eBay.

Disk in good physical condition but magnetic media contaminated with widespread mould.

An initial disk clean with isopropyl alcohol and medical swabs in the 3D printed drive cleaning rig took place, as well as deep cleaning of the drive before beginning. Repeated cleaning took place during attempts due to oxide shedding. After 13 attempts, all that could be read had been read and the sector map was unchanging. Proof, once again, that "Parrot" brand disks are absolute garbage when it comes to longevity.

Disk (what was left of it) returned to original sleeve for archiving.

Approximately 95% of the disk data had been recovered. As a test subject, we then pushed this flux recovery through our AI Vintage Data Recovery AI Platform to see if we could recover the remaining 5%:

==============[ AI REPORT ] ===============

What went in

Three sector images from the best read attempts, three flux captures, one screenshot of the FluxEngine session. First job for the AI was to fingerprint everything, and it immediately handed me an embarrassing discovery: the three .scp files are byte-identical. Same MD5 on all three. Somewhere across 13 attempts and repeated drive cleans I'd saved one flux capture under three filenames. Note to self, and to anyone else doing this work at 1am: checksum your captures as you take them.

So the actual source material was one flux capture plus three genuinely independent sector-level reads, which differed from each other in 67 of the disk's 720 sectors. Standard 360K geometry — 40 cylinders, 2 heads, 9 sectors, FAT12, OEM string MSDOS3.2.

The flux

The capture was decoded with the Greaseweazle codec against the ibm.360 profile. Of 720 sectors, exactly 154 came back with valid CRCs. The other 566 payloads are the literal ASCII string -=[BAD SECTOR]=- repeated — FluxEngine's damage filler — so there were no partially-mangled bitstreams to arbitrate with, just 154 sectors of certainty. Gold sectors.

Those gold sectors earned their keep as a calibration set. Read #1 agreed with all 154. Reads #2 and #3 each contradicted the flux at exactly one sector. Conclusion: all three reads are excellent where checkable, none is infallible, and — this becomes the theme of the whole exercise — agreement between reads is not the same thing as truth.

The filesystem, or what was left of it

Both FAT copies survived intact and identical in every read, which is the single luckiest thing about this disk. The directory structure did not fare as well. The /DEMO subdirectory's cluster read as pure zeros in every source including the flux — its entire contents orphaned. The /SHORTIES directory was mangled in read #1 (one entry claiming a start cluster of 65,249 and a size of 4.2GB, which would be impressive for a 360K floppy) but intact in reads #2 and #3.

A FAT orphan scan turned up 227 allocated-but-unreferenced clusters forming 12 chains. Twelve lost files, sitting in the data area with nothing pointing at them.

The disk identifies its own dead

This is the part I enjoyed most. The disk documented itself. PCPLUS.BAT changes into \DEMO and runs something called DARKSIDE. The recovered menu screen (OCTOBER2.SCR) announces "This month's demo is DARKSIDE the new Freescape game from Incentive Software" and promises support for EGA, CGA and Hercules. The largest orphan chain is an MZ executable of exactly 20,905 bytes by its own header, containing the menu strings 1. CGA 4 colour / 2. EGA 16 colour / 3. Hercules monochrome — and the filenames of its six orphaned siblings.

Assigning the three renderer builds to the right filenames didn't need guesswork either. One executable writes to segment B800 — CGA. One writes to A000 — EGA. One writes to B000 and pokes the 6845 registers at ports 3B4h/3B8h — Hercules, unmistakably. Every MZ header's declared size matched its FAT chain length to the cluster. The remaining orphans fell out of the intact SHORTIES directory from reads #2/#3: a hardware detector, a system checker, and FANTASY2.DAT — the Adventure Writer competition winner mentioned in the batch file, full of jungle and tower.

The /DEMO directory was then rebuilt from scratch: correct names, correct sizes, correct start clusters. The one thing genuinely unrecoverable was its timestamps, which died with the sector; the rebuilt entries carry the stamp from DEMO's own entry in the root directory (08-Aug-1988), consistent with the mastering dates across the rest of the disk. That is the only fabricated data on this image, and now you know about it.

Merging: where votes lie

Assembly ran per-sector: flux gold first, unanimous sectors next, then the 67 disputes. The obvious policy — throw away all-zero/all-0xF6 dropout sectors when structured data exists, then majority vote — resolved 65 of them. The interesting work was auditing the result, because majority voting has a failure mode this disk exploited repeatedly: two reads sharing the same physical damage produce the same wrong bytes, and outvote the one clean read.

Content-plausibility analysis caught six of these. Two were in documentation files, where the outvoted minority read was 512/512 printable text restoring, among other things, the PeasyDos SETTATT command reference with perfect grammatical continuity. The rest were binary, and the evidence there is the kind I'd frame and hang on the wall: at one sector boundary in DOSMAP.EXE, the majority tail was garbage while the minority tail ended mid-instruction-sequence — push [bp+0Eh] / push [bp+0Ch] / push [bp+0Ah] — completed by push [bp+08h] / call at the top of the next, undisputed sector. Instruction-stream continuity across a sector seam. In FANTASY2.DAT, the minority read ends "…that the tower is" and the next sector begins " surrounded by a jungle". You don't argue with that.

Two sectors defeated voting entirely — three-way disagreement. The first sector of OCTOBER2.SCR was recovered by recognising that one candidate was coherent CP437 screen furniture matching the file's other frames; the rebuilt screen renders perfectly. And one sector in the middle of the EGA build of Dark Side was a judgement call: two reads were 0xFF-saturated dropout, the third shared both the statistical fingerprint of the surrounding clean world-data and a literal 15-byte motif with the adjacent sector. I took it, flagged it as the recovery's weakest link, and moved on. Remember this sector. It comes back later with a medal.

The manifest

An independent extraction of this exact coverdisk lives on archive.org (pcplus_coverdisk_issue25, contributed by Richard Davies — thank you). Its _files.xml manifest provides MD5, SHA1 and CRC32 for all 30 files. Ground truth, at file granularity.

First comparison: 26 of 30 files byte-perfect, including every content-plausibility arbitration above. Four executables mismatched, and here the checksums stopped being a scorecard and became a search target:

DSIDEH.EXE had six disputed sectors — 64 candidate combinations across three reads. Hash all 64, find the match. It revealed two more correlated-corruption sectors where the lone minority read had been right all along.

DSIDEE.EXE had eighteen disputed sectors — ~393,000 combinations, tamed by forking the MD5 state at each disputed sector instead of rehashing 46KB per attempt. The winning combination flipped one more sector to a minority read, and proved something better: the weakest-link sector, the single-source judgement call in the EGA world data, was byte-for-byte correct. The fingerprint hadn't lied.

DARKSIDE.EXE and DOSMAN.EXE would not yield. No combination of read candidates matched. No per-byte mixture of the disagreeing reads matched. A full-file CRC32 burst-error solve — any corruption confined to a 32-bit window at any offset is exactly recoverable from the checksum by GF(2) linear algebra, which is a lovely party trick — found nothing. The damage was wide. And, it turned out, mostly not where anyone was looking.

Three donor sectors

With local evidence exhausted, three sectors were transplanted from the archive.org extraction (fetched browser-side against embedded per-sector hashes, so only the differing sectors ever moved). What they revealed justified the entire exercise:

The disputed sector in DARKSIDE.EXE turned out to be all zeros. Both "structured" reads there were two bytes of noise on a blank region — the one place on the disk where the discard-the-dropout-fills heuristic had discarded the truth.

The other two grafts landed in sectors that were never disputed at all. One sector of DARKSIDE.EXE: 226 bytes wrong, identical in all three reads. One sector of DOSMAN.EXE: 505 of 512 bytes wrong, identical in all three reads. The same physical damage, decoding the same wrong way, pass after pass after pass. No voting scheme, no statistics, no checksum algebra could ever have caught them, because there was no dissent to work with. Meanwhile the sector in DOSMAN that was disputed — the one I'd have pointed at — had been arbitrated correctly from the start.

That's the lesson I'm taking from this disk, and it's worth putting in bold for anyone doing preservation work: re-reading one dying disk N times does not give you N sources. Correlated misreads are indistinguishable from truth until an independent copy exists to disagree with them. Which is, quietly, the entire argument for why redundant preservation matters — this recovery only reached 100% because someone else imaged their copy of the same magazine disk four years ago.

Final state

All 30 files verify against the archive.org manifest on both MD5 and CRC32 — the complete allocated data area is externally proven, byte for byte. Internally: every FAT chain length matches its file size, both FAT copies identical, all ten MZ headers agree with their directory entries, zero orphaned clusters, zero cross-links. The image mounts cleanly, shows 1,024 bytes free — a properly packed cover disk — and works in VirtualBox, 86Box, PCem, DOSBox (imgmount a disk.img -t floppy), or written back to real media via GreaseWeazle.

The only deviations from the 1988 artefact: the synthesized /DEMO timestamps declared above, and free-space sectors, which are best-effort and mean nothing. Everything a running program can touch is exact.

Not bad for a disk that was flaking oxide onto the heads at almost every sector.

Checksums

File       MD5
Read #1    06f7fdf1f08b2ea6994f5141aec32c3b
Read #2    c86b0c6e8df75faa63c2986b4e3c5210
Read #3    985ebd26cd369f25dc3fc0c182f63457

Flux capture (×3, identical — ahem) 0b4ae444e56bfd173043e6add73f527a
Recovered image                     67ee314dc8fb904c38d455762cf83c3e

Recovered image SHA-256: 4418a02ac3283297437fa8d914659aa1a45014c9027468a67885ee65f5027594

Reference extraction: archive.org/details/pcplus_coverdisk_issue25, contributed by Richard Davies.

Have a nice October.