I bought a brand-new Atari ST game in 2026, and the publisher's own instructions said to write it to a floppy disk. This is the bench post about doing exactly that—a Greaseweazle, a drive rescued from an SF314, the exact command that does the work, and a verify failure that vanished when I went looking for it.
Here's a sentence I didn't expect to type this decade: I purchased a new commercial Atari ST game, downloaded it, and the store page told me to write it to a floppy disk to play on real hardware. The game is Return to Blacktooth—the thirty-seven-years-later sequel to Head Over Heels, which now has its own post on Attract Mode—and the instruction is the itch.io page's honest, intended workflow: buy the download, write the .ST disk image to a real 3.5-inch floppy, boot it on a real ST. No gray areas, no dumps of somebody else's disks. A purchased game, moved to the medium the machine wants.
Which means the interesting question is the middle step. How does a file on a Windows PC in 2026 become a bootable Atari floppy? At this workshop, the answer is a Greaseweazle—and a floppy drive with a story of its own.
What a Greaseweazle is
The Greaseweazle, an open-source design by Keir Fraser, is a small USB board that speaks to a bare floppy drive at the lowest level there is: magnetic flux transitions. It doesn't care about file systems or platforms—it reads and writes the raw timing of the magnetism on the disk, which means the same cheap board handles Atari ST disks, Amiga disks, PC disks, and formats far weirder than any of those. Mine is a Greaseweazle V4.1, the model read straight off the silkscreen, living in a green 3D-printed case.
The software side is Keir's host tools (version 1.21 here) plus, on Windows, Don Mankin's GreaseweazleGUI front-end—though as you'll see, the GUI's best feature is that it shows you the real command it's about to run.
The board itself: Keir Fraser's Greaseweazle V4.1, silkscreen doing the introductions.
The drive: a rescue from an SF314
A Greaseweazle needs an actual drive mechanism, and mine came the long way around. It's a Mitsumi/TDK D357—Atari part number C070350-001, confirmed by the labels on the mechanism itself—the drive Atari shipped inside the SF314 external floppy. It came to me in a 520ST bundle: the 520ST itself had no internal drive, but two working external drives came with it, and one of them was an SF314. I fitted that SF314 with a GoTek floppy emulator for the flexibility of loading disk images off a USB stick (a swap that's earned its own short post), which retired its perfectly good period mechanism to bench duty. The drive built to read Atari disks now spends 2026 writing them.
The donor's papers: D357, the Mitsumi/TDK mechanism Atari shipped in the SF314.
Wiring is simple and slightly funny: the drive hangs off the Greaseweazle's 34-pin ribbon, jumpered as drive 0—there's a label reading "- - DRIVE=0" on the shield so I never have to think about it twice—and it drinks from two sources at once. The 5 V comes from the Greaseweazle board itself (there's a header for exactly this), and the 12 V comes from the bench supply, a Jesverty SPS-3010N idling at 12.14 volts. A drive with two landlords, perfectly content.
Where the drive came from: the SF314, now living its GoTek life.
The write, exactly as it happens
The GreaseweazleGUI's Write to Disk dialog assembles the command and shows it to you, which I appreciate—no mystery, and once you've seen it, you don't strictly need the GUI again. Here's the real one from this bench, writing an ST utility disk:
gw.exe write --diskdefs "..\diskdefs.cfg" --format=atarist.800 --erase-empty --device=COM4 "C:\Users\jeffreymays\Desktop\SysInfo.st" --drive=0
The GUI's best feature: it shows you the real command before it runs it.
The pieces that matter: --format=atarist.800 is the profile for a standard double-sided 800 KB Atari ST disk—80 cylinders, two heads, the geometry you watch scroll by as it writes. The input is the .ST disk image, exactly as downloaded. --erase-empty wipes unused tracks rather than leaving stale data. And the media is plain double-density stock, which is what ST images this size want.
Then you launch it and get one of the workshop's more satisfying spectacles: a console ticking through T0.0: Writing Track (Flux: 200.0ms period, 220.0ms total) line after line, both heads, all eighty cylinders, until the words you actually came for: All tracks verified.
The words you came for.
The verify failure that got away
About that verify step. My first attempt, on a yellow-labeled disk, failed verification. Fine—forty-year-old media, it happens. I grabbed a second disk, red label, wrote it, verified clean, moved on. Good bench hygiene, story over.
The suspect and the witness: the yellow disk that failed once, the red disk that booted.
Except that later, wanting the exact error text for this post, I rewrote the yellow disk to reproduce the failure—and it wrote and verified perfectly. Every track. Nothing wrong with it at all.
If you've read my EPROM cross-validation saga, you already know this gremlin. It's the same one from the time an EPROM misread refused to come back across five programmers: intermittent faults move, and the retest proving "nothing's wrong" doesn't prove nothing was wrong. It's why the verify pass on the day you write is the only evidence worth trusting—on chips, and apparently on magnetic flux too. The failure that won't reproduce is precisely the reason the verify step exists.
The payoff: booted on the real machine
The machine on the receiving end is my Atari 1040 STe (TOS 2.06, 4 MB). There are plenty of modern ways to move a file onto it—an ACSI2STM, a NetUSBee—but writing an actual floppy is my favorite by a mile. There's something satisfying about a disk you can hold and hear seek that a boring drag-and-drop just doesn't have. The disk went in, and the payoff shot is SysInfo running from a floppy that was a desktop file twenty minutes earlier. For Return to Blacktooth itself, one honest wrinkle worth recording: the itch.io page lists TOS 1.04 (ST) or 1.06 (STe) among its requirements, and my STe runs TOS 2.06—where it plays without complaint. I read those listed versions as the developer's tested baseline rather than a ceiling, and my machine seems to agree.
Twenty minutes from desktop file to floppy boot: SysInfo on the 1040 STe, SC1224 doing the honors.
And this pipeline doesn't stop at one game. The same rig writes the club's meeting floppies—the desktop in the write screenshots has DYNAMO.ST and friends sitting on it, disk images pulled straight off my own TNFS server, which is mapped as a network drive on the write PC. Download, write, verify, boot: the loop works the same whether the payload is a 2026 commercial release or a demo disk for Saturday's meeting.
What I learned
Two things. First, the humble part: the Greaseweazle makes this almost anticlimactic—a purchased modern game became a working Atari floppy on the first good disk, with the only drama supplied by media older than the game's own sequel gap. Second, the part I keep relearning on every medium this workshop touches: verify at write time, and believe the failure even when it won't repeat. The yellow disk never confessed. The red disk booted. That's not a mystery to solve; that's the procedure working.
Frequently asked
What do you need to write Atari ST floppies from a PC?
A Greaseweazle board (mine is a V4.1), Keir Fraser's host tools, a working 3.5-inch drive mechanism on the 34-pin ribbon set as drive 0 (with 5 V and 12 V supplied—the Greaseweazle provides 5 V; my 12 V comes from a bench supply), and double-density media for standard 800 KB ST images.
What format do you use for ST disk images?
For a normal double-sided ST disk, --format=atarist.800 with the .ST image as input. The GUI assembles this command for you and shows it before running.
Is writing a downloaded game to floppy legit?
When you bought the game, yes—Return to Blacktooth's own store page instructs exactly this workflow for playing on real hardware. Buying the download and writing your own disk is the intended path, not a workaround.
What if the write fails verification?
Use another disk and move on—but log which disk failed. In my case the failing disk later wrote perfectly; intermittent media faults are real, and the write-time verify is your only trustworthy evidence. Don't argue with it after the fact.
Further reading
- Greaseweazle, by Keir Fraser—hardware, host tools, and documentation: https://github.com/keirf/greaseweazle
- GreaseweazleGUI, the Windows front-end, by Don Mankin (Desert Sage Solutions): https://desertsagesolutions.com/greaseweazlegui/
- The D357/SF314 drive family, identified by part number (Atari-Forum): https://atari-forum.com/viewtopic.php?t=42135
- The Atari C070350 drive part numbers (AtariAge): https://forums.atariage.com/topic/184357-wanted-st-mega-2-floppy-drive-d357-co70350-003/
- The gremlin's previous appearance—my intermittent EPROM fault across five programmers: https://chicagolandretrotech.com/blogs/news/intermittent-eprom-read-fault-cross-validation-part-2
- The machine on the receiving end—my AmigaVision/MiSTer caretaking post, for the other half of the bench: https://chicagolandretrotech.com/blogs/news/amigavision-update-mister-error-0000-000b
I'm Jeffrey Mays. Bench Notes is where I write up the actual workshop work—burns, builds, repairs, and the occasional floppy disk that fails once and then pleads innocent forever. The game that started this one, Return to Blacktooth, now has its own story over on Attract Mode. Subscribe to catch the next one.
0 comments