Visually, that looks great, Ian. Thanks!
I didn’t even have to drag out fossils like Tandy Model II/XENIX Multiplan! 
(We’d put 10 ASCII terminals on systems smaller than a BusPirate!)
What do you really consider the use case here? I’m sure you’d shame my use of PROM editors but since my primary interface was a hex keypad and a fluorescent calculator dispdisplay,ever really went beyond tweaking a few strings/copyright dates here and there, adding a few opcodes to the end, patching some jumps to call those, and back and so on. So in MY usage - which, admittedly, was about when CUA was in vogue, the total bytes changed was a very small percentage of the PROM (or else I’d justfire up the UV light, erase the chips, reassembler, re-split the bin across PROM, and march on. It wasn’t like insert and delete byte ranges were a think that made sense on my ‘186s or whatever.
Isn’t 100K enough to hold a copy of any EPROM that would make sense to modify totally in RAM? Reading it into RAM, modifying it, and then writing it back to the device is legit.
I did work once on a MIPS (?) system that allowed “patching” boot ROMs when they were read, though it was strictly changing and appending, not inserting and deleting. worked by keeping an internally SORTED list of pairs of offsets/words (could probably do bytes if you cared) that was like a patch list. So taking your second list, it might have an array of
rec[0] = 0002,0405
rec[1] = 0100, 0304
rec[2] = 0102, 0506
When it was time to write the file, it would look at the first entry in the list (I’m typing this as an array, but it was effectively a stack or a circular queue that never wrapped, which is kind of a stack) and see how far it could go. Could copy the first word (a memcpy of 2 bytes is still a memcpy and not a special case) from the source. Then it would start pulling from the patch list until the address jumped. Write the 0405 to address 2, and then go back to reading the flash. How far? Well, now the “head” was at 0x100 so we could copy 0x253 (?) bytes until we got to 0x100. Now we switch to sourcing data from the patch array. Pull the 0304. Next? 0102 is in the deck AND is our next destination, so we pull the 0506. Next entry? We were at the end (I don’t know if it was a special marker or a tail pointer or some other indicator that we were at the end of the patch list, but from there, we’d finish the memcpy sourcing from 0104 and running to the end.
Maybe that’s too limiting and maybe it doesn’t help with the problem at hand.
Good luck!
It was definitely a limited form of editing, but it matched the real world of what we ever expected to do with a PROM burner (reasonable expectations/needs of tools have surely changed in the last 40 years, as you, our reigning toolsmith to the toolmakers, would well know). but you could hold the original AND the “patched” (via some slight of hand because you were generating the patched one on the fly) in some smaller amount of memory than we had. It was early in my career, and I remember being impressed then by the clever data structure. For all I remember, it might have even been changing the source pointer via self-modifying code or double indirection or something masochistic - whether it was on our programmer or the boot loader of the system I was thinking of, resources were really paltry compared to what we have today.
