How hard could it be to write “Hello, World!” on a half-century-old storage medium?

A few weeks ago, I was cleaning out a drawer of old DVDs when I found a physical "save button".

If you have not seen one of those, you might assume someone 3D printed the save icon as a joke. Actually, it's the other way around: the save icon is a picture of this object called a Floppy Disk. That's how, for almost 30 years everyone carried files(or a single file, to be more realistic) around and it was widely recognized.

But what is a Floppy Disk?

Inside the plastic shell, there is a flexible magnetic disc which is kind of "floppy". It spins at 300 RPM and has a small head that slides along a metal arm and flips tiny magnetic regions to store ones and zeros. The drive exposed raw signals handled by the controller. CPU would just ask the controller for sector 0 and go back to running Minesweeper.

Then floppy disks died, because USB sticks and CDs became more accessible and could store thousands of times more and much, much faster. But every piece of software you use today still shows you its picture when you want to save. It's fair to say the floppy disk sacrificed itself to become the symbol for saving. Seeing one again in 2026 makes me wonder: Can I write "hello world" onto this thing?

There is a boring answer: get a $20 USB floppy drive, plug it in, drag a text file over, done. But that felt like cheating and missing a point. The USB drive would do all the talking and I wanted to DO the talking. So a slightly different form of the same question is: can I get bytes onto this disk myself, signal by signal, using stuff I already have?

Doing my homework before asking AI to do mine

I'll be honest about the tempting version of this project: open Claude Code or Codex, type "write me an Arduino Floppy Disk driver," and watch what happens. I've tried that approach on other projects. What you get back is confident, plausible, and impossible for you to evaluate, because you skipped the part where you learn enough to have opinions. When the code doesn't work, you can't tell whether the bug is in the code, the wiring, or the architecture.

So before writing a single prompt, I did homework the old-fashioned way: I found the model number printed on my drive, dug up the 34-pin connector pinout, took photos of the drive's jumpers, and wrote down my actual constraints: Arduino Mega - because that's what I had, One track of one disk - because I don't need a filesystem, and I need "hello world."

Then I put the AI to work, but on research rather than code. I spun up three agents in parallel, each with a different question:

1. The interface. What do the 34 pins actually do? Which signals do I need for the minimal case, and which can I ignore?
2. Similar open-source projects. Who has done this before? (It turns out a lot of enthusiasts had a similar idea)
3. Feasibility. This was the question that could kill the project: can a 16 MHz ATmega328P bit-bang floppy signals at all? Floppy data timing is measured in single-digit microseconds. At 16 MHz, that's a budget of a few dozen clock cycles to read a pin, make a decision, and write a pin. The margin is thin enough that I wanted to know before connecting anything.

Fifteen minutes later I had three research summaries to read with my black tea, which is a strange and pleasant way to start a hardware project on Saturday morning. Then came the part I'd argue matters most: reviewing the proposal and pushing back. The first plan Claude synthesized was over-ambitious: it wanted to read and write PC-formatted disks, FAT12 filesystem and all, so the disk would mount on a real computer, which sounds tempting, but that's a nice way to spend three weekends failing. I cut the scope down to something I could hold in my head: spin the motor, move the head to the beginning(track 0), write bytes onto that one track, read them back, print them over serial.

Putting all together

I asked Claude to condense everything into a PLAN.md, with one rule: every milestone had to be verifiable with my eyes or ears, because at this stage I had no other debugging tools. The result was a sequence I genuinely liked:

1. Assert DRIVE_SELECT and MOTOR_ON → you should hear the disk spin.
2. Pulse STEP with DIRECTION set → you should see and hear the head move.
3. Seek outward until the TRACK00 signal fires → the drive tells you the head is home.
4. Watch for the INDEX pulse → one blip per rotation, five per second, printable over serial.
5. Only then: write one track, read it back, decode.

A plan where the first two milestones are "listen for a noise" is a plan an amateur can actually execute. If I'd started at step 5 — which is exactly where the naive one-shot prompt would have started me — every failure would have been silent and indistinguishable.

Claude wrote the first prototype in one sitting: pin definitions, motor control, head stepping, and the timing-critical write loop. It compiled. I flashed it, opened the serial monitor, and ran milestone one.

Nothing. Not a click, not a hum.

The first bug was mine, not Claude's. Floppy drives ignore every input unless DRIVE_SELECT is held active — and "active" on this connector means pulled low, a convention the 1970s was very fond of. My wiring treated it as a button to press rather than a state to hold. One line of code later, the drive spun up with a sound I hadn't heard in twenty years. I sat there grinning at a bare mechanism whirring on my desk.

The second bug cost an evening. The head stepped, TRACK00 fired, but the INDEX pulse — the once-per-rotation heartbeat — read as random noise. I described the symptom to Claude, which asked whether I'd added pull-up resistors. I had not. The drive's outputs are open-collector: they can pull a line down to zero, but they can't push it up to one — something has to do that for them, and nothing was.4 Every "signal" I'd been reading was an unconnected wire acting as a tiny antenna.

The third bug was my favorite, because it's the kind that makes hardware people nod knowingly. Writing appeared to work, but the read-back was corrupted — not fully garbage, just wrong in a pattern, with damage recurring at what looked like regular intervals. I told Claude exactly that: "the corruption seems periodic, roughly every millisecond." It answered almost immediately: the Arduino's millis() timer fires an interrupt every 1.024 milliseconds, and each one was pausing my timing-critical write loop for a few microseconds — an eternity when your bit windows are that small. The fix was one call to noInterrupts()

I re-flashed, wrote the track, read it back, and watched the serial monitor:

Why use AI at all?

Two evenings is the number worth dwelling on. Imagine what this project would have cost without AI: I'd have spent several hours just finding the right interface documentation, MFM encoding, browsed through removed Reddit posts where people almost had it working with a similar setup. All of this effort might not have been worth trying, and that’s where most hobby projects die silently, without a single line of code.

Using AI tools for hobby projects reminds me of 3D printing. 3D printing didn’t replace injection molding. When manufacturing thousands of precise units, you still cut steel because per-unit quality and cost are unbeatable. But what 3D printing gave us is cheap prototyping and made manufacturing accessible for everyone.

On another note, since using automated agents removes friction, it’s worth highlighting that friction is not universally bad, and we’ll never fully eliminate it. Without friction, there will be no learning and no getting into the flow state. The trick that worked for me was to deliberately choose which friction to keep that made the whole project fun. This is not a universal rule but the balance I landed on.

The floppy disk is back in the drawer, but it's different now: There is "Hello, World!" physically written on it. No computer on earth will ever read it, but I don’t mind that a 55-year-old storage medium holds a message written by a tool that didn't exist before.

Turns out the physical “save button” still works, you just have to press it very, very manually. Perhaps someday, someone decides to read the contents of this floppy disk. I wonder how they’ll go about doing that?!
Perhaps someday , another engineer will want to read the contents of this floppy disk and reply. I wonder how he’ll go about doing that.