RawDIC-Auto: skip the Start button

What RawDIC does (in one install)

Each WHDLoad Install drawer on whdload.de ships an AmigaDOS script. For many games the script declares install version 0. That block means:

1. Load a small 68000 program beside the drawer: <Game>.islave (“ISlave”) — a recipe listing which tracks to read and how to decode them.
2. Run C:RawDIC with SLAVE=<Game>.islave and a source of raw tracks — usually SOURCE=DF0: while you swap floppies, or INPUT=<file> when the ADF (or MFMWarp/WWarp) already sits on disk and trackwarp.library feeds tracks instead of the physical drive.
3. RawDIC writes intermediate and final files under the install directory — often Disk.* blobs and eventually the runnable *.slave, icons, and tooltypes WHDLoad expects in UserTools/<Game>.

Version 1 installs use C:Patcher instead; our catalog handles both, but RawDIC is the painful GUI case.

Why we want it at all: the NAS and community packs do not contain every title we care about. The legal path is your ADFs + WHDLoad’s own imager. guest_whdload_rawdic.py skips the outer C:Installer menu and runs the same inner command the Install script would have run — after copying the drawer files and inserting disk 1 into UAE’s DF0.

How our scripts invoke RawDIC on quo

This is tier four (puppeteer). vamos never runs this chain; you need it in mind to see what the patch buys you.

1. whdload_install_engine.py selects backend rawdic_batch and calls run_rawdic_batch(plan).
2. host_prepare() mirrors the install drawer to the host path that maps to WHDLoad:UserTools/<prefix>.
3. floppy_insert.py puts the first ADF in DF0 via WinUAE’s named pipe (AmiPilot alone cannot swap disks).
4. run_rawdic_guest() assigns volumes, builds the cmd file with whdload_guest_cmd.build_rawdic_script_body(), uploads SYS:T/whdload-<prefix>.cmd, and Executes it — not a one-line launch("RawDIC …"), which does not open the tool on our rig.
5. drive_rawdic_gui() uses tree("RawDIC"), reads gadget text, clicks Start (AmiPilot with host click fallback), handles “insert disk N” by inserting the next ADF, until *.slave exists on the host mirror.

Canonical cmd body (stock):

CD WHDLoad:UserTools/KillingGameShow
C:RawDIC SLAVE=KillingGameShow.islave SOURCE=DF0:

Step 5 is where nights went. RDP latency, Start gadget coordinates, empty status bodies that still mean “press Start”, and multi-disk titles that need another insert and another click. We wanted unattended batch installs for the catalog, not another manual afternoon per game.

Why stock RawDIC blocks headless automation

The WHDLoad developers publish RawDIC assembler source inside WHDLoad_dev.lha (RawDIC61.lha, Public Domain). The AmigaGuide and source agree: tool types include SLAVE, SOURCE, INPUT, RETRIES, IGNOREERRORS, DEBUG — not HEADLESS.

After RawDIC opens its Intuition window and tells you to insert a disk, the main loop waits on messages. Imaging begins only when the user hits Start (or picks a file). Setting INPUT=Source:…/game.adf avoids needing DF0 for track source, but the GUI loop is unchanged: you still owe a Start click per disk. There is no documented “quiet” mode.

Our options were: keep fighting the GUI with AmiPilot (fragile), copy prebuilt packs when they exist (best), build a host-side reimplementation of every .islave (huge), or fork the official sources minimally and install a second binary C:RawDIC-Auto on the install HDF only.

What RawDIC-Auto changes

Under rawdic-headless/ in amiga-utils we ship a patch (not a republished LHA): when INPUT= is set or a new switch HEADLESS/S is present, the program branches to the same entry point as Start (SM_Start) instead of sitting in WaitIMSG. Stock C:RawDIC stays on the disk for manual installs.

Guest env vars (read by whdload_guest_cmd.py):

WHDLOAD_RAWDIC=C:RawDIC-Auto
WHDLOAD_RAWDIC_HEADLESS=1
# optional — ADF already on Source:
WHDLOAD_RAWDIC_INPUT=Source:WHDLoad-games/adf/…/KGS.ADF

Example cmd with Auto + headless:

CD WHDLoad:UserTools/KillingGameShow
C:RawDIC-Auto SLAVE=KillingGameShow.islave SOURCE=DF0: HEADLESS

drive_rawdic_gui() skips Start clicks only when both WHDLOAD_RAWDIC=C:RawDIC-Auto and WHDLOAD_RAWDIC_HEADLESS=1 are set and the patched binary exists on the HDF. If you set headless but leave stock C:RawDIC, the host script now fails fast instead of moving the mouse. If Auto is missing entirely, AmiPilot preflight errors before Execute.

What we saw on quo (October 2026): the screenshot above is stock RawDIC V4.4 — “Insert disk 1 and press Start.” C:RawDIC-Auto was not on the install HDF yet, so “headless” env vars alone could not work; the old driver still tried Start clicks. That is the gap the patch + HDF install closes.

Git policy: patch, fetch/apply scripts, legal/README only — no WHDLoad binaries in public git. You build on Amiga/Barfly and copy RawDIC-Auto to the acceptance HDF or a private artifact store.

We tried to e2e test RawDIC (and RawDIC-Auto) with vamos — and could not

After the patch work, a natural question was: can tier-two vamos run stock C:RawDIC or C:RawDIC-Auto on a developer laptop and assert the same Disk.* / *.slave files the WinUAE rig would produce? That would have been the cheapest proof that headless Auto “works” before every merge rode RDP to quo.

What we built: scripts/vamos_rawdic_spike.py and scripts/test_vamos_rawdic.sh map host directories to WHDLoad:, Source:, and C:, copy fixture .islave files, optionally fetch the real m68k RawDIC binary from WHDLoad_dev, and invoke vamos with the same argv our guest cmd file uses — including HEADLESS when testing the Auto profile.

What happened: vamos starts the executable, but imaging never completes. Reasons stack on top of each other:

• No trackdisk.device. With SOURCE=DF0:, RawDIC asks the OS for floppy tracks. vamos emulates Exec/DOS, not Paula and the disk controller. There is no DF0 to read.
• No full TrackWarp + file stack. With INPUT=<adf> on real AmigaOS, TrackWarp and libraries on LIBS: satisfy reads from a file. vamos does not replicate that device and library environment end-to-end.
• No Intuition. Stock RawDIC still opens the window even when INPUT is set; under vamos there is no gadget loop at all — which is fine for testing argv, useless for pressing Start (the problem Auto fixes on real OS).
• Silent early exit. With quiet logging, vamos often returns host exit code 0 and an empty log (vamos_silent_exit). That is not success; it means the guest process stopped without producing imaging output on the host mirror.

So VAMOS_INTEGRATION=1 tests are deliberately negative: they guard cmd layout and prove vamos is a poor substitute for UAE. They do not validate RawDIC-Auto imaging. Even a perfect headless patch still needs real track I/O somewhere vamos does not provide.

Headless Auto removes the Start button on Workbench. vamos removes Workbench entirely — including the devices RawDIC needs to read floppies.

Where proof lives instead: tier four — install_whdload_live.sh on the install HDF with WHDLOAD_RAWDIC=C:RawDIC-Auto and WHDLOAD_RAWDIC_HEADLESS=1, watching for *.slave under build/WHDLoad-games/UserTools/. Tier one still locks the cmd text; tier two locks volume/argv; only UAE + DF0 (or INPUT on guest) completes the story.

Practical paths (unchanged)

Approach	Start clicks	Where it runs	Imaging
Prebuilt WHDLoad pack	No RawDIC	Host copy	N/A (already built)
Stock RawDIC + AmiPilot	Yes	WinUAE quo	Yes
Stock + INPUT=	Yes (GUI)	WinUAE quo	Yes
RawDIC-Auto + HEADLESS	No	WinUAE quo	Yes
vamos spike / integration	N/A	Mac/Linux	No (by design)