86GT wrote: ↑Sun Jun 30, 2019 4:10 pm
...I dont have a full understanding of the 8061 op code. I have not spent the time to learn it, so I leave that up to the experts
But more to the point, the improvement in execution from a more optimized patch code logic just isn't going to resonate with anybody without detailing how that translates to a benefit to them. And I can't say that I have a solid grasp on this. Some of my knowledge may be inaccurate, but here's my stab at explaining it AND my opinion on how valuable I think it'd be.
Lets say you've update your tune's Spark table to differentiate between RPM Load values above 4000RPMs (as opposed to the last column being 4000) and you shift the rows around so your top row represent 160% and the 2nd to top row, maybe 110%. This way, you change the spark advance as RPMs go from 4000-6000 and as Load goes up to 160. Looks good on paper until you go datalogging and start noticing that some of the values you are getting for spark advance aren't what should be produced, but in other places it is. Then you start noticing that at high RPMs, you get these long stretches where the advance value just doesn't change, but it changes quite frequently at lower RPMs. What gives?
What you are seeing is the affects of background loop starvation. The less often the background loop gets to execute, the less often you get a new advance value. And the faster the engine spins, the more the higher priority code (aka ISRs) are getting run. At 5000RPMs, you might not get a complete background loop for an entire second on a GUFx era EEC!!! At 6500, they may not exist because the ISRs are dominating the processor. Somewhere around 6800 RPMs, the processor may not even keep up with the ISRs and then things like Spark and Injector fire calculations don't get calculated as fast as their results are needed...and the engine falls on its face with random misfires either due to lack of fuel or bad/no spark or both.
For N/A applications where advance doesn't need to change much and the engine stays below 6000RPMs, there's little harm done. It's not an ideal situation, but it's not horrible. However boosted applications where boost could be making big changes through this high load and rather critical region, you don't want to be commanding a spark advance associated with 110% Load as the instantaneous load is creeping into the 140s and 150s. Yet that's what you might get...and see in your datalog. So the only safe thing to do is sacrifice power in the lower RPM/Loads and set them to values that are safe for MAX RPM/Load so you don't command spark advance that's too high for the engine conditions.
All that said, I get the desire to minimize what all happens during background loops in order to make them more efficient and get more passes through during these high RPM crunch-times. What I'm doubting is the result. At idle, the background loop updates are numerous. It's when the RPMs are high that the efficiency begins to count for something. But it's not the background loop's efficiency that is really causing problems. And a minor optimization like this will likely not get noticed in ANY practical sense. It's simply that an 80s era microcontroller is undersized for the task of accurately and optimally running a V8 at really high RPMs.
So unless you are having a problem with getting the background loops you need during these time periods, I don't really see the practical benefits of messing with this unless it's just for giggles and something to do on your personal vehicle. But I'm not yet convinced it's going to improve anything enough to justify updating the defs for it.
And if you are running a race car and notice problems getting background loop execution consistency, then my recommendation would be to buy a modern aftermarket EEC setup like the Holley EFI setup they use to replace GM factory computers. They have modern day processors that are not even close to being challenged by a V8's real-time engine management requirements at 10,000 RPMs. At the very least, update to one of the 24MHz EEC-Vs. But my guess is the time and money it'd take to go from a GUFx era EEC to a 2000 era EEC just wouldn't be worth it over buying a complete aftermarket EEC replacement rig like a MegaSquirt or Holley Terminator/Dominator setup.