I went through a similar process recently with an HP/Agilent 54845A scope (1.5 Ghz, 8 Gsa combined) - a great tool if you need reasonably fast rise times and a reasonably fine time base resolution - the only issue is that it has an abysmally low sample memory for today's standards, so you get to see the trigger and "just a bit more". Well the other issue is that it pushes a lot of air... Like a lot, jumbo jet a lot. The scope luckily was in great shape and had a fresh test cert from not long ago.

I was going down the same route as the blog post (MSATA->PATA adapter), but simply imaging the HDD onto flash also didn't work.

The scope had to go into storage so I never finished this, but the SSD was being detected albeit at a lower capacity and no amount of twiddling with LBA and CHS geometry made a difference. My next step is going to be zeroing the drive, booting the scope with it as secondary, and then imagining it from within DOS/Windows. My hope is that the data will just end up at some offset. Or not even imaging it - just partitioning it, formatting it and doing XCOPY + SYS.

You may want to image the drive every so often and accessing the drive is a bit of a bastard (fewer than 32 screws on the HP but it's a pain regardless) - so it might make sense to actually get an SD->PATA adapter and mount it onto a PCI blanking plate, so that you can take it out easily. You may need a longer ribbon cable. There are also some 2.5 inch HDD brackets that mount onto a PCI blanking plate. Possibly a DIY job to replace the FDD with a plate that has the SD card mounted. Mine came with a ZIP drive.

I added the following software extras to the OS which I would recommend to anyone with an old scope like this that has an Ethernet port:

- An SNTP client so that you don't have to worry about the time and date (https://www.timesynctool.com/) - open source, win95 and up, just disable all logging to disk so as not to introduce extra writes and drive wear.

- TightVNC (1.3.10 I think) - a version that works on older Windows. Accessing it while the scope app is running slows things down significantly, so this is only for configuration changes and whatnot, also this particular scope writes directly to the VGA framebuffer, so you don't actually get to see the scope output via VNC!

- Shared some folders from the scope. This required a significant amount of fuckery to mount an SMB1 drive elsewhere without ruining one's existing Samba config, but it helps quite a bit to be able to exchange files with the scope.

Hardware extras that proved useful in a lab setting:

- One of those cheap VGA to USB frame grabber adapter things - they are detected as a video device, don't need drivers and you can watch your scope with VLC or your OS's built-in camera app.

- A remote-controlled power outlet. Speaks for itself - no need to touch the scope to shut down and restart an experiment from wherever you are.

- A GPIB to USB adapter if your scope has a GPIB/IEEE 488 port. Current Linux support is in a bit of a state, but anyway, this will allow you some degree of automation when reading the math / stats / other data, and will sometimes allow you to do more than the scope's UI will. I know for example that with GPIB I can control the signal on the AUX port on my scope, for which the GUI has no options.

- Not tried yet: this scope uses a PS/2 mouse (remember that they are not hot-pluggable) and a DIN keyboard. This bad boy: https://github.com/rasteri/HIDman - will let you plug in your wireless USB dongle and control your scope with your everyday keyboard and mouse.

The above significantly improves the "workflow" so that you hardly need to touch your scope or even swing your chair, or can use it remotely, and applies to most of the late 90s - early 2000s Windows scopes.

Refurbishing a Tektronix TDS7104 Oscilloscope