A couple of clarifications...
Looking carefully at the two photos again and reading Howardlong's description, they are of the same saved data but with the vertical scale changed.
If you're referring to the two following two screenshots, then they were two different single shot acquisitions, each taken at the displayed vertical resolution. There is a relay click between the 200mV and 500mV setting (with 1X probe), I was suggesting that a different signal path at the front end has different filtering characteristics. I tried other vertical resolutions that didn't click any relays and the rise time wasn't significantly affected.
It is true, however, that on captured acquisitions, changing the vertical resolution
after the capture also shows aberrations, although the difference is nowhere near as much.
Wasn't there an issue with protocol decoding where only what is on the display can be decoded? That might fit with this.
I think that is probably a red herring: the problem with serial decoding is that (a) the scope will only decode what's on the screen (not in memory) and (b) as you slow timebase in real time, or equally zoom out on a capture, the underlying sample rate used to decode also decreases to such an extent that it will no longer properly decode, and although the decoder's sample rate is shown, it doesn't appear to be changeable by the user.
There appears to be a "feature" on the firmware I'm using: I cannot turn off sin(x)/x unless I have at least three channels running (weird!).
FWIW, with sin(x)/x on, with the 3dB points with a 1Vpp signal when using an RF signal generator, terminated at the scope:
1Ch 109MHz (1GSa/s)
2Ch 105MHz (500MSa/s)
3Ch 106MHz (250MSa/s, using averaging [128] due to aliasing artifacts)
4Ch 106MHz (250MSa/s, using averaging [128] due to aliasing artifacts)
With sin(x)/x on:
3Ch 64MHz (250MSa/s)
4Ch 64MHz (250MSa/s)