SD card and CLI rough edges (EPIC-15)

[diegoparrilla]

A reinserted SD card works again without a reset, the device says when there
isn't one instead of failing six different ways, a retried write chunk is no
longer written twice, and the CLI reports a dropped connection instead of a
Python traceback.

A reinserted card stayed dead — two causes, not one

The driver never learns the card left. sd_card_spi_init() begins with "Check if we're not
already initialized before proceeding" and returns early unless STA_NOINIT is set — and with
card-detect disabled on this board nothing ever sets it when a card is pulled. So on reinsertion the
driver still believed the old card was initialised, skipped its entire init sequence, and handed
FatFs a freshly powered card it had never spoken to, which failed on the first sector read.
sd_card_p->deinit() sets the bit back.

FatFs never asks. While the volume stays registered, mount_volume() never calls
disk_initialize() at all, so f_mount(NULL, "0:", 0) has to come first.

Both are needed. The first version of the fix had only the unregister, and the hardware caught it:
every retry still failed with FR_DISK_ERR.

And the removal cannot be detected from FatFs results. With the card physically out, volume
answered 200 with the cached size and free space, and a listing answered 200 with an empty
directory — FatFs serves what it cached and reports no error, so the "remount on the next failure"
trigger in the plan could never fire. The main loop now asks the card directly every 2 s by reading
sector 0 through disk_read(), which a cache cannot answer.

No card: one answer, and the menu says so

With no card	Before	After
volume	200 + cached free space	503 no_sd_card
listing	200 + empty directory	503 no_sd_card
download	500 disk_error	503 no_sd_card
upload / mkdir / runner load	500	503 no_sd_card

The menu header carries the state (GEMDRIVE SD: mounted / SD: NO CARD) and [G] and [U] are
refused with "Insert a working microSD card: GEMDRIVE needs one." rather than launching a mode
with no drive behind it. STORY-01's retry loop clears the block about two seconds after a card is
inserted, with no reset.

The state went on the header line rather than a row of its own because a new row breaks the
menu: the dividers are at fixed pixel rows and the icons are right-aligned per header row, so one
extra line struck Screenmem and Hook through, collided IP address with the USB CDC heading and
ran the status line into Select an option:. A framebuffer snapshot caught that.

A retried write chunk was written twice

After a timeout the ST re-sends the same 1 KB chunk with a fresh token, and the RP appended it
again: the file gained a duplicate and lost its tail. Nothing on the wire distinguished a retry from
new data.

An absolute offset does not work without more state than it looks: the m68k knows only how far it
has got within the current Fwrite call, not the file position, which the RP owns and Fseek
moves — so a relative offset cannot tell a retry of a call's first chunk from the first chunk of the
next call. Instead the m68k carries a sequence number that never repeats: write_seq, bumped once
per chunk and never per retry, sent in d5, which the protocol always transmits and the RP was
skipping. Each open file slot remembers the last sequence it accepted and the bytes it wrote; a
repeat is answered with that same count and not written again.

The CLI no longer prints tracebacks

urllib wraps some connection failures in URLError and lets the rest through as bare OSErrors.
Two exposures: urlopen() itself, and the reads after a successful open — the download loop and
the debug tail loop both called resp.read() with no handler at all, which is where a reboot
mid-transfer lands. CONNECTION_DROPPED names the family once (including IncompleteRead), and
everything maps to one error: line and exit 8.

Verified on hardware

Diego at the Atari, pulling the card and running the copies:

• Card pull: detected in ~2 s (sector read failed -- card gone), remounted ~4 s after
  reinsertion, volume and listings correct, 256 KB upload round-tripping identical, no reset.
• Booted with no card: retries every 2 s and picks one up when it appears.
• No-card gate: menu shows SD: NO CARD, [G] refused, all endpoints 503 no_sd_card; block
  lifts by itself on reinsertion.
• Retried write: a 512 KB copy with two chunks stalled 10 s each — the ST re-sent both, the RP
  logged repeat of chunk N, answering 1024 again for each, and the copy is byte-identical to
  the source. A first attempt at 2 s stalls produced no retries at all (inside the ST's
  COMMAND_TIMEOUT) and would have been a false pass.
• CLI against a real device: reset during a 4 MB download → connection dropped by the device (timed out), exit 8; panic during a 4 MB upload → [Errno 32] Broken pipe, exit 8.
• smoke.py 8/8 debug; CLI suite 119 tests (4 added), and the new tests were checked against the
  unfixed CLI, where all four fail with the traceback this was filed for.

Not verified

• Pulling the card while the ST has GEMDRIVE open. Today's pulls were with the ST idle or at the
  menu; the interesting case holds open handles across the pull.
• During a 4 MB upload, three 800 ms SELECT presses were not seen by the firmware, though the
  same injection works on an idle device. This could be the main loop not polling under load or the
  SWD injection failing to hold the pad; they need different fixes, so it is recorded rather than
  guessed at. A physical press during an upload would settle it.

Also found, not fixed here

Changing [D]rive in the menu does not change the drive the ST uses: the letter reaches the m68k in
the reply to its HELLO, which only happens when the ST boots the cartridge. The menu showed K:
while the console kept reporting drive=C (#2) until the ST was reset. Worth its own story.

The cartridge image is now 10,144 of 10,240 bytes.