[ruckusman]

Great thread.
Some clues that may assist you with this.

If you get the datasheet for the atmel prom chip you will likely see that it has a protected mode which can be switched back off - in fact there was a SGI patch for the O2 PROM, as the previous PROM version allowed resetenv -f to rewrite the protected region, WHOOPSEE, I pity the poor user that discovered that bug, anyway...

I consider that there's a boot code which is processor independent which loads first, at least on the O2 for certain - then it obviously moves to higher regions of the chip and does the further testing and initialisation - this is where things like your full CPU setup reside.

Some of the PROM flash commands from the patches can be enlightening if you look at the entry points specified in those commands.

There's also good clues to be gained by just using binwalk on PROM image files - there's usually several easily identifiable elements which have clearly identified regions of where they flash to the atmel prom chip.
Binwalk doesn't work the same way on all PROM image files BTW.

I suspect, but cannot yet prove that because the atmel chips are written in segments with the extra space potentially loaded with zeros, they are after all designated as 8 x 512K.

So although a PROM image file for flashing may be 1.6MB on disk, it may likely occupy more space than that on the PROM chip - it would make it easier to code for a PROM if the code and data segments stay put and a change to one element (increasing size, or for instance adding support fo the 1600SW in the case of the O2) didn't necessitate re-writing the entire PROM code due all of the bits and pieces residing in different memory locations on the chip.

The binwalk output is also more revealing on the IPXX.ide files in this regard, than it is for many prom images as that protected code segment isn't in that image at all, so no file header information is there either.

A further clue is looking at the flash commands themselves, which usually specify an entry point for the code, so there's always the original 'boot' code remaining untouched, otherwise you've got a brick if it goes pear shaped.

Binwalk is also useful to look at the stand IPXX.ide files as these seem to be most of what would execute at boot with the diagmode set - thorough hardware tests.

The standalone tests do after all (re)initialise much of the hardware and run tests on that hardware.
Many that I have examined quickly have ESP32 flash images - potentially these are things like SCSI controller and graphics firmware.

Anyway, if you're looking to flash new chips then solder them, it would likely be necessary to read out an entire prom chip with an actual reader to obtain that first loaded 'boot' code.

Has anyone compared a prom.image with a dump obtained via the flash -D command to see if there's any 'extra' in the dump?

Also worth noting there's some worthwhile threads on eevblog regarding TSOP readers/burners - they're nowhere near as expensive as they used to be, with some of the reader/writer hardware and software, plus a set of clips that can be secured to a PROM in situ you may be able to write a chip as it exists - soldered onto the board.