Wrapping this up: worst of all, I had a totally and unforgivably silly mistake in the RMS function that merged the FFT's real and imaginary output, which is why I was getting the same strange output from both a local FFT implementation and the (better, but not universally-bundled) FFTW.
Fixing it so that the time domain display has an integer-number of (25-sample) divisions but the FFT always sees an integer power of 2 samples, fixing the RMS problem, and with few other changes of significance, I can get things like the attached which is the output of a pretty-but-noisy USB PSU.
For a cheap and pocketable scope I feel that's a bit better than adequate. Frequency (measuring its own calibration signal) is a bit suspect, but I can fairly easily check that against a pulse-per-second GPS signal.
Anybody who wants a copy is welcome, but I'm not sticking it onto Github yet. The issue is that the project can use dynamic linkage between the frontend (generic) and backend (device-specific) parts, and while the frontend could call the backend I was having problems with calls from the backend to frontend. The worrying thing is that it worked properly with 32-bit code (on a 64-bit Linux system with multiarch, FPC 3.0.4) but not with 64-bit code, and when I last looked at this I got bemired a long way into the runtimes and standard libraries.
MarkMLl