Every button acts on the target selected in the socket row: one socket (CS0 to CS3, or as many as configured), or ALL. The exact flashprog command of each step is printed in the log.

Asks flashprog which chip is in the socket and shows its name and size on the card. You rarely need it: the live scan already detects chips, and unknown chips are probed automatically (see Chip Detection).

• One socket: probes that socket.
• ALL: probes every socket one by one, and warns if the chips aren't all the same type (broadcast write and erase are then unavailable).

Probing isn't available while a job runs or is queued: the button is greyed and a click logs "Probing is not available during queue run."

Saves the chip's contents to a file.

• One socket: asks where to save; the suggested name is <chip>_CS<n>.bin.
• ALL: asks for a folder and saves one <chip>_CS<n>.bin per detected chip.

Compares a chip with an image file and reports match or mismatch.

• With verify on Pico on (default), the Pico computes a CRC32 of the chip and compares it with the image's CRC32. Nothing is read back over USB, so this is many times faster.
• Otherwise flashprog reads the chip back and compares (flashprog -v).
• ALL verifies every detected chip one by one.

Results go to the flash log and show on the card as ✓ verified or ✕ failed.

Erases the whole chip (all bytes become 0xFF) after a confirmation. ALL erases every chip at once over the broadcast line.

Flashes an image to the chip. The steps for one socket:

1. Blank check (on Pico), only with used blocks only. The image is split into 64 KiB blocks. Blocks that are entirely 0xFF in the image are "unused"; the Pico checks with a CRC32 whether those blocks on the chip are already blank.
2. Write. flashprog erases and writes the used blocks plus any unused block that wasn't blank. If more than 90 % of the blocks are used, it simply writes the whole chip.
3. Verify. On the Pico (CRC32) if verify on Pico is on, otherwise flashprog's own verify. Skipped entirely with skip verify -n.

Before writing you confirm the image and the target. If the image size doesn't match the chip, HydraFlasher offers to fix it. Your original file is never changed:

• image too big: truncate it to the chip size and save a copy as <name>_truncated.bin;
• image too small: pad it with 0xFF up to the chip size and save a copy as <name>_padded.bin.

Instead of using the file dialog, drag an image file from your file manager onto the window:

• onto a socket card (a socket, or ALL): selects that socket and writes the image to it. It's exactly like pressing write and picking the file: the size check, the pad/truncate offer and the "Flash it" confirmation all still come first, and while another job runs it's queued.
• onto the log: verifies the selected target against the image, like verify.

The card or log turns green while a file is over it. Dropping anywhere else, or dropping a folder or several files at once, only logs a hint. In production mode drops are ignored, because the batch image is fixed.

Drag and drop needs the optional tkinterdnd2 package (see Installation). When it's installed, the socket header reads drop an image to write and the welcome text in the log has a tip about it.

With ALL selected, write and erase use the broadcast chip select (cs=10, or cs=6 on older firmware), which selects every socket at once. Identical chips are erased and written in parallel, as fast as a single chip.

There's a catch, and HydraFlasher handles it for you. During a broadcast every chip answers at the same time, so nothing can be read over the broadcast. A broadcast write therefore:

1. re-probes the sockets and checks they still hold the chips you confirmed;
2. erases all chips over the broadcast, so they all start with identical contents (flashprog reads the chip before writing);
3. writes all chips over the broadcast;
4. verifies each chip on its own, never over the broadcast.

All inserted chips must be the same type. Otherwise the ALL card shows chip types differ and broadcast write and erase are refused. Unsupported chips can't be used in a broadcast either.

While ALL is selected and a broadcast write isn't possible (chip types differ, an unsupported chip, or no chips at all), the write and erase buttons are greyed out. A click explains why, with a list of the chips, before asking for anything. For chips that differ, use one-by-one.

While ALL is selected, a one-by-one option appears in the settings. With it on, write sends the same image to each socket in turn instead of to all at once:

• You pick the image and confirm once. HydraFlasher then queues one normal write per socket (blank check, write and verify, as for a single socket). The first starts right away; the cards of the others show ◷ queued.
• The chips may differ. Each socket is checked on its own when its turn comes. A chip the image doesn't fit fails alone ("Image is 32.0 MiB but CS1 is 16.0 MiB – nothing written.") and the others go on. Unsupported chips are skipped.
• If a chip matches several flashprog definitions, you're asked once per chip type, while the jobs are queued (see Chip Detection).
• The ALL card says N chips · in turn, and the footer target ALL (one-by-one).

It's slower than a broadcast, which writes identical chips in parallel, but it works for any mix of chips. The setting is remembered. It affects write and erase: with one-by-one on, erase on ALL also queues one erase per socket instead of a broadcast. Read and verify on ALL already go socket by socket.

■ stop or Esc asks for confirmation, then stops the running job. Interrupting an erase or write leaves the chip partially programmed: write it again before using it. With jobs in the queue you can also clear the queue (see Job Queue).