I tried to install XP but the problem is that the drivers for the acquisition card are not available. The Windows98 drivers won't work on XP because XP is completely different when it comes to drivers.
Do you know what the VIDs/PIDs are for the acq card? Maybe in the range 15BC:0500 to 15BC:0507?
No, according to the list from the BIOS I think it is 103C:1020 (that is the only unknown PCI device listed)
I don't know if you are aware of this, but on webarchive there's an old dump of Keysight's FTP site containing something that looks like N5383A installation ISOs. Four files named M815G-T3A-Disk1.iso, M815G-T3A-Disk2.iso, M815G-T3A-Disk3.iso and M815G-T3A-Disk4.iso contains ghost image of Windows XP installation, together with drivers for graphics card and acq board - probably all revisions, including the oldest one, I see the following VEN/DEVs (acq boards olny):
VEN_15BC&DEV_0508
VEN_15BC&DEV_0507
VEN_15BC&DEV_0503
VEN_15BC&DEV_0501
VEN_15BC&DEV_0500
VEN_103C&DEV_1020
xml file found in the root dir of the first CD states:
<!-- All 548xx Infiniium Models-->
<FrameDescription>
<Device VendorID="103C" DeviceID="1020"/>
</FrameDescription>
so it explicitly lists first version of acq board (the one shipped with first Infiniiums, W95-based). That comment: "<!-- All 548xx Infiniium Models-->" is even more promising.
Anyway, I think it should work on 54832B with either acq board. I cannot test this myself, as I don't own 54832B.
However, in reality, the "All 548xx Infiniium Models" promise might be false, as I couldn't make it to work.
I had to use Atlas III based 54810 scope with lowly K6 200 MHz, upgraded to 96 MiB of RAM (I had a hard time getting my two pairs of 32 MB EDO sticks to work with each other - on each (re)boot I had a different size of ram. Of course the two pairs on their own worked just fine separately. So in the end I've used one pair of two 32MB sticks and another pair of two 16 MB sticks totaling 96 MiB). I've also used 6,5 GiB 2,5 IDE HDD from some old laptop, that was competing in terms of noise generated with the scope itself (prior to this I've used 40G hdd, but I had issues as it was recognized as 8 GB by old Atlas III mobo.).
This configuration is even below XP minimum requirements (when it comes to CPU speed). 96 MiB of RAM is a bit low for even bare XP from 2001, lest for XP SP2 loaded with tons of Agilent bloatware. However I had no choice, as my K6-2 400 MHz based 54815 that takes SDRAM DIMM sticks decided to die, when I was trying to power it up (after not using it for some two years - but neither I used that lowly 54810 during this time).
So I restored the ghost image to the HDD, put XP setup bootstrap files on it (WinMBoardMig.zip that I got from some chasms of the internet did not help here - only turned bootlooping XP installation into hanging one - just after it loaded everything and switched to 32-bit protected mode), then I did repair install of provided WinXP SP2 (it is in WinXPFiles directory or something like that).
The good thing is that I had no unrecognised/unknown devices in device manager. Now the bad.
After reboot, I've installed latest version (5.71) of scope software ... which crashed on some SSE instruction (well, it was intended for those PIII based boards it seems...). a4sse, a sse emulator, BSOD'ed right after executing provided exe file.
As I imagined that rewritting scope app to not use SSE might be a major task on its own, I've tried the oldest scope app from Keysights website (4.21) which only barked that "Low physical memory detected. Check physical memory size in the control panel and reboot", then caused some driver to allocate 1 GiB of memory (mostly in pagefile...) and hung afterwards.
After noping out that memory error it had shown another one: "The scope vxd is not registered or is out of date." - lol, they didn't updated that string for XP version. And it looked like it is not working anyway (all self tests failed, unable to calibrate, togle LEDs, read knobs etc).
I've decided to try Win'95 scope app instead, since it was destined for my scope and certainly it shouldn't expect it to be 5483x instead, hoping that interface between the driver and scope app didn't changed in the meantime.
(Both scope apps, after a quick look, seems to share their codebase.)
Win'95 app used file "\\.\hp548xx.vxd" to communicate with the acq board driver, whereas the XP one used "\\.\Scope0" instead. So I hexedited w'95 HP5481X.EXE accordingly, only to discover that it is working just like XP one (albeit with no message about wrong vxd and not eating 1 GiB of RAM). It couldn't read my scope s/n, was detecting it as 54855, couldn't find calibration data (despite it being where it should be) and of course no communication with front panel controls. Should I also say it didn't measured anything?
After a reboot to w'95 it turned out that on w'95 directly launching HP5481X.EXE produces the exact same result as directly launching it under XP. It turned out that on Windows 95 another exe is launched first - hp548Ldr.exe - which apparently tried to establish scope type and then launch either HP5481X.EXE or HP5484X.EXE with some magic parameters.
hp548Ldr.exe had at least one bug in it - if it failed to open file exposed by acq board driver, it didn't send IOCTL and didn't initialise some variable, but afterwards it tries to access memory pointed by that variable, like that not placed IOCTL call was successfull. So it crashed on XP, since it apparently failed to open that \\.\Scope0.
I've downloaded a little utility by the name of "DosDeviceInspector" to see if there is really \\.\Scope0 device (or maybe other devices of interest). Of course it also crashed on SSE instruction (file is dated 2016-01-12, so probably they used compiler recent enough to enable SSE by default). The instruction seemed to be irrelevant to the function of the program, as noping it out was enough to make it working and make sure that indeed, there is device called \\.\Scope0. Also there's another device of interest - \\.\Tombstone0 ("Tombstone" seems to be code name/nickname of first version of acq board - VEN_103C&DEV_1020 - thus tstone.inf/tstone.sys pair). However this device couldn't be opened on Windows XP by hp548Ldr.exe as well.
Having issues getting hp548Ldr.exe to work, I've tried to figure out whether it is really important, looking like just a launcher for either HP5481X.EXE or HP5484X.EXE.
The magic done by hp548Ldr.exe takes a form of some magic
spellparameters which turned out to be:
HP5481X.EXE /scope /hpib
When launched this way, scope software just works - on win'95 of course.
Equiped with magic parameters, I've swapped HDDs to boot Win XP and try starting scope app new way.
It turned out to be a mess - now it started crashing with unprivileged instruction. W'95 app was writing directly to registers of (I suppose) graphic card! I've tried noping the entire function that did ins and outs but then it started to crash in other places.
This time I gave up. Maybe I will try something more in the future, preferably after fixing my other scope (MOBO not working - no sign of life, I've even tried running it off external power supply; but that a good sign anyway as it is easier and probably cheaper to get equivalent AT MOBO, if I couldn't fix this one). Doing anything on that low-end XP machine is an exercise in patience (if not in futility) - even turning it on (or off) takes several minutes. Imagine running scope app under the debugger...
Hypothesis: in that particular configuration XP driver does not work. Maybe there were different VEN_103C&DEV_1020 (with different interface to the PC I mean, as there were PCB revisions anyway, as cards from 54810 & 54815 looks different) and the XP driver was tailored only to the acq card that was shipped in XP scopes, or maybe the drivers are checking for certain characteristic of VP22 motherboard (unlikely, since folks have changed their MOBOs - but maybe tstone.sys checks for that, where drivers for newer acq boards don't?). I can also imagine different revisions of acq board firmware. Or maybe something is misconfigured (for example some service occupies the driver and latest scope knows how to deal with it, while older ones do not). Or my repair reinstallation had broken something important.
There are plenty of debug strings in at least Mesa.sys. Printing them via DbgPrint seems to depend on a value of some variable. I've tried changing it to expected 2 in driver binary, but no luck, maybe I misread something.
Or maybe I'm missing something major. Just before writing this post I believed that tstone/tombstone is a codename for acq board. But in tstone.inf file it is described as "Infiniium Display" which does not seem to make much sense for me (also I vaguely remember something about some PCI-PCI bridges? maybe "tombstone" acq card is just an one piece needed in case of later scopes, whereas on previous generations it was the only one?). Maybe there were some major changes between Win9x based Infiniiums and XP based one, despite retaining the same VEN/DEV of acq board?
Update: For explanation, why it failed, see my
latest post here.