My Amiga wouldn’t notice when I changed disk images on the Gotek. I was certain it was a config setting. It was a jumper. And then it was a cable. Not one line of configuration was ever the fix.
The setup
- Amiga A500
- DF0: Gotek running FlashFloppy, mounted internally on the 34-pin floppy header
- DF1: a second Gotek running FlashFloppy, on the external DB23 floppy port
- Both drives: stock Goteks, rotary encoder + OLED
The symptom
When I selected a different disk image on a Gotek (rotary encoder, autoselect), the Amiga never noticed. dir DF0: from the CLI kept returning the boot disk’s contents — cached — no matter which image I picked. Booting from a selected image worked fine, so the drive clearly worked; it just wouldn’t register a disk change.
That points at one signal: /CHNG (disk change), which on the Amiga lives on pin 2. A drive pulls it low to say “the disk changed,” and the OS clears it by stepping the head. FlashFloppy models this with its chgrst option — so, naturally, I went hunting through config.
Act 1: the config rabbit hole (all dead ends)
chgrst = delay-2/delay-3— auto-clear /CHNG on a timer instead of waiting for a step. No difference.interface = shugart— the default isinterface = jc, which reads the physical JC jumper and only becomes shugart when it’s open; I forced it to rule the jumper out. No difference.chgrst = step(default) — now DF0 booted toDF0:????.
That ???? was the first real clue, though I misread it. It doesn’t mean “no disk” — it means “disk present, but I can’t validate it,” which is what you get when the disk-change line is misbehaving or the bus is dirty. So the signal path sort of existed, but nothing I typed into FF.CFG moved the needle. Config was a dead end. Time to stop typing and start unplugging.
Act 2: the clue that cracked the first bug
Booting with no USB sticks in the Goteks at all, I noticed Kickstart’s insert-disk animation flickering — drawing, then blanking, roughly once a second (KS1.3 hand-with-disk; KS3.1 a purple screen with the DF0 light pulsing on the same beat).
Two swaps did what hours of config never could:
- Swapped the DF0 Gotek for a real floppy drive → animation rock-steady. So the Amiga, cable, and bus were electrically fine as far as that test went.
- Unplugged the external DF1 Gotek → DF0 animated and validated perfectly, on both KS1.3 and KS3.1.
DF1 was sabotaging DF0.
Root cause #1: a floating select on the external drive
On the A500 the external DB23 port is not an independent bus. It shares /CHNG, /RDY, /TRK0 and read-data with the internal drive; only the select line differs (the port carries a dedicated /SEL1). Every drive is only allowed to drive those shared lines while it’s the selected drive.
My external Gotek was jumpered S1 — and here’s the trap:
The
S0/S1jumper names a pin on the Gotek’s own connector, not the Amiga drive number. It picks which pin the Gotek watches for “you’re selected.” The Amiga drive number is decided by which select signal is wired to that pin.
The A500 external port already addresses the drive as DF1 and routes its /SEL1 onto the S0 position. By setting the drive to S1, I pointed its select input at a pin nothing drives. It floated, the drive intermittently decided it was selected, and it drove the shared bus while the Amiga was talking to DF0. Contention → the ????, the flicker, the corruption.
Fix #1: external Gotek → S0. Both Goteks end up on S0 — correct, not a mistake, because each reads a different physical select line:
| Drive | Jumper | Select pin it reads | Becomes |
|---|---|---|---|
| Internal Gotek | S0 | internal header /SEL0 | DF0 |
| External Gotek | S0 | external port /SEL1 (via DB23 adapter) | DF1 |
The flicker vanished, DF0 validated cleanly with DF1 present, the ???? was gone. Surely now the disk-change would work.
It didn’t.
Act 3: same symptom, second cause
With the bus clean, DF0 still returned cached data on every swap — but now DF1 was in play too, and the deciding observation landed:
DF1 did disk-change perfectly. DF0 never did.
Same firmware, same config, opposite result. That single fact retired the entire software theory: FlashFloppy’s disk-change works, the Amiga’s detection works, the config approach works — on DF1. Whatever was wrong lived on DF0 alone. Forcing shugart and every chgrst mode changed nothing, because I was still tuning a signal that wasn’t arriving.
The fingerprint — the Amiga permanently reading pin 2 as “present, unchanged” — said the disk-change signal wasn’t reaching the CIA on DF0. And pin 2 is used only for disk-change: booting and reading data go over entirely different conductors. A single broken wire there would kill disk-change and leave everything else looking perfect.
Root cause #2: a dead pin-2 in the ribbon cable
I swapped the internal 34-pin ribbon cable. Disk-change immediately started working — on both DF0: and DF1:. The old cable had a dead (or marginal) pin-2 conductor — the outer wires on a ribbon are exactly the ones that crack. Boot and reads never touched it, so nothing else ever complained.
Done.
Bonus gotcha: a Gotek booted empty is invisible until reset
One more thing that bit me. If a Gotek powers on with no USB stick, and you insert one later, the Amiga ignores it — even though the Gotek’s own display shows the mounted image.
Not a FlashFloppy bug. The Amiga enumerates its floppy drives once, early in boot. A Gotek with no stick isn’t presenting as a live drive at that instant, so Kickstart records “no drive” and never re-checks until reset. No config changes this. Rule: have a stick with a valid image in at power-on — it needn’t be the final image; you can navigate afterwards.
The config I actually run
For reference, here’s the FF.CFG on both Goteks now — but note the caveat that’s the whole point of this post: none of these lines were the fix. The hardware was. Two are still worth keeping, though:
nav-mode = native
display-type=oled-128x64-rotate
autoselect-file-secs = 3
autoselect-folder-secs = 0
sort-priority = folders
rotary = full
chgrst = step
interface = shugartMost of it is personal taste (navigation, autoselect timing, sort order) and hardware (the OLED and the rotary encoder). The two Amiga-relevant lines:
interface = shugart— pins DSKCHG to pin 2, where the Amiga reads disk-change, regardless of the physical JC jumper. BecauseFF.CFGis read at every boot, setting this explicitly nails the interface down in software so it never depends on the jumper being where you assume. Jumper-proofing — not because it fixed anything.chgrst = step— the authentic real-drive disk-change reset: /CHNG clears when the Amiga steps the head. It’s the default. I’d tried delay-N while chasing the ghost, but with the wiring fixed, plain step behaves exactly like a real drive.
Lessons
- A believable software explanation can be completely wrong — twice. “Disk change isn’t registering” screamed disk-change config. It was a jumper, and then a cable.
????means “present but unvalidatable,” not “empty.” It’s a corruption/contention signal — a hint the wiring is dirty, not absent.- On a shared bus, the drive with the symptom isn’t always the drive at fault. DF0 showed the problem; DF1 (mis-jumpered) caused it.
S0/S1selects a pin, not a drive number. On the A500 external port, the “second” drive is correctly set to S0.- Pin 2 carries only disk-change. A drive that boots and reads flawlessly can still have a dead disk-change wire — a cracked ribbon conductor is enough.
- Isolate physically, and let a working unit be your probe. A real drive proved the bus; unplugging DF1 found the aggressor; DF1 working proved the fault was DF0-specific and pointed straight at the cable. Swapping parts beat every config edit.
