I'm late to the party, but this is my new favorite thread.
Nice work, bubba!
For the 7603, it would be easy to have PCM Hammer treat any of the unused memory ranges as a calibration range. For the near term, you can just tell PCM Hammer to do an OS write - it will only erase and rewrite the memory ranges that have changed. That's the approach I've been planning to take when I start playing with custom code.
For a custom boost OS, I think it might be simpler (for the tuner, not necessarily for the custom OS developer) to get rid of the PE idea, and just use a fuel table that has MAP on one axis and RPM on the other axis. Which could be done by changing the temperature axis on the existing open loop commanded fuel table so that it's an RPM axis, and then change the MAP axis so that it goes up to 2 or 3 bar. Then there's no need for PE switching conditions, because you'd just enrich the cells that are above whatever MAP and RPM range you want. And no need for a "boost enrichment" feature, because again you just enrich the cells in the fuel table.
Since there would no longer be a temperature axis on the fuel table, we'd need a separate table that enriches in cold weather and when the engine gets hot... and that table already exists. The stock OS only enables it for PE, but I suspect it would not be hard to make it active all the time.T
This approach to fuel tuning isn't really my idea, it's just the way fueling is tuned in Subaru ECUs. I'm used to that approach, so PE seemed weird to me (and I'm told that HPT uses "boost enrichment" which seems even weirder) so I started looking for ways to make the GM OS code work more like Subaru... I haven't tested any of these changes, but I'm guessing it would work.
It sound like EGR could be used to drive a boost control solenoid. If that really works, it could turn out fantastic... Open loop boost control would make a good first step, based on a table that has accelerator pedal position on one axis, and RPM on the other axis, and duty cycle in the table cells. If that works out, then all it takes to go closed loop is a second table with the same axes and target MAP values in the cells, plus a feedback loop (and a few misc parameters to tune the feedback loop).
The feedback loop itself is not much code. You can see one that I used for an Arduino project here:
https://github.com/LegacyNsfw/AvcsContr ... edback.cpp
You can ignore the bucket / rolling-average stuff at the end. That was an idea to collection data to help with tuning, but I never actually used it.
Hand-written assembly is probably the right approach for repurposing factory tables, but if we get to the point of implementing boost control, we should figure out how to get a C compiler involved. That was very very useful in getting custom code working with Subaru ECUs.