If you are servicing or owning some older test equipment (or arcade games, or similar), I highly recommend to take copies of the internal program, usually stored on a PROM, EPROM, or mask ROM. As long as these are socketed, no problem – still we need to be careful because old integrated circuits may have brittle legs, but in general, it is easiest to remove the memory from the board, and then read it with some good EPROM reader.

One of the early late 1970 versions of the 4274A CPU assy (part number 04274-66617) has this feature, easy to remove 16k EPROMs:

The above board, I never had one in my hands, it is a picture from the web, and as per Keysight’s website, there were several later versions. So far I had two 4274A’s in my workshop for repair, and both had the later 04274-66529 board. I can only speculate that these board were made in a larger set, because is features mask ROMs rather than EPROMS, and there is high cost to only make a handful of mask ROMs (one would rather use programmable memory)

Many times, for test equipment, it seemed that in the 80s the program code was considered like something that will never change or need update, and the memory chips were directly soldered to the board. This had clear reliability advantages (cost at this level was no argument for that kind of equipment, but sure it is great to just solder in the memory by automated assembly rather than manually programming them, and putting them into sockets), and time showed that the engineers of HP were right, very rarely the ROMs fail, and if they fail, it is because of some catastrophic other issue, like a massive power supply failure. Only in one case, the single-time programmable EPROMs used in the 3562A, these fail all too often and too early, probably this memory design or specific series has reliablity issues.

Despite all this reliability, we want to keep copys of the ROMs, but how to get access to the chips soldered to the board. Unsoldering is no option. Soldering in general, on old digital boards, we want to avoid – because it may take days to get it back to service if something goes wrong.

So, how can we proceed? Pretty easily, we just pretend to be the CPU, and read the data by replacing it with a microcontroller that sends the address and data information for each accessible memory location (16 bit), 65536 bytes.

The test cables, can be shop-made from some resistors with thin legs, and some jumper cables, and some heatshrink tubin.

Some of the CPU signals need to be set appropriately to get access to the memory, like the VMA and R/W signals.

The setup, a simple Mega128A board that has plenty of ports, a USB to RS232 converter (running at 250 kbaud).

The Mega128A continuously cycles through all the addresses, and transmits the data to a host PC.

After some cycles captures, i.e., with all adressess read several times, is is only a matter of a seconds for a small console application to generate the memory dump.

But then – some time consuming observation. From the Agilent forum, I have a copy of 4275A ROMs (hte 4275A is the higher frequency companion of the 4275A, and the first 3 ROMs are supposedly identical).
ROMs 2 and 3 were found identical to my copies – but ROM 1 has 2 different bytes. How come? Maybe a corrupted byte? -these are generally rare to non-existent for mask ROMs.

To resolve it, I had to wait for a 2nd 4274A to show up here, and very recently it did, so I took another ROM dump (you can also recognize it from the color of the lithium battery above). As it turns out, the two 4274A I had in my hands have identical ROM images, so either there is an issue with the image of the 1818-1134 = 04274-85041 so far found on the web(taken from a 4275A), or these two ROMs are not identical for the 4274A vs. 4275A, against common knowledge. Any case, below you have the validated 4274A ROM images.

hp4274a 4275a ROM 04274-66529