512 kB main loop reference

[turbo_bu]

I found this a while back over on the HPT's forum discussing how the main loops are setup in a 512 kB OS. It was from back in the day when the early tuning packages were still being developed. I hope that it provides some use and insight to those who are smarter than me on how all this stuff works.

https://forum.hptuners.com/showthread.p ... isassembly

[turbo_bu]

FWIW - in the 12202088 OS, the main loops start at $2A1D6 and go through $2A298. I am not 100% sure how / why it starts, but I could at least match up with the code that they were sharing.

I have some vague ideas about how things translate from code into meaningful outputs (like spark, fuel etc..), but haven't figured it all out yet. I am hoping that bread crumbs like these will give others who understand this stuff more a head start on figuring things out.

[NSFW]

Thanks for posting this. I just started working on 12587603 (a P59 operating system that's available in lots of configurations) and the same loops are present in that one.

It's weird that the code looks like a bunch of endless loops. I don't see why the PCM isn't just bricked every time it goes into one of them.

[turbo_bu]

NSFW - I have a similar thought process as well, but my guess is that is how the code functions. It starts when you power it up, (not sure how it originally gets here), and then relies on interrupts to kick it out of certain loops, which then brings it back (again, not sure how it gets back to here either). I am hoping that other people who know a lot more can shed some light on how these basic things happen.

[antus]

The vectors are a list of addresses at the start of the bin. The second address in the list is the reset vector from memory so this is the starting point (i think the first is the stack - should be documented in the processor data sheets). I think the loops are interupt driven by the timing hardware (tpu), so they fire off at given time intervals to process data and calculate times. Typically it'd program timing data in to the onboard helper hardware that does the work to trigger injectors and coils at the right time.

[turbo_bu]

So all these loops are basically calculating things which get loaded into memory, which the helper hardware uses to trigger things like spark and fuel? If this is correct, then the key thing to work backwards from is which memory addresses are the actual ones which are used by the helper hardware.

[Highlander]

What is the main goal?

[turbo_bu]

Goal would be to try and add a new feature to the existing OS. Something like rev limiter using spark instead of fuel. If we knew which address was the main one controlling, then we could try and figure out how to modify it outside of the existing OS. This also implies that we understand which loop(s) are also modifying these same addresses.

Adding other features would most likely follow this same path.

[Highlander]

That shouldn't be too difficult to implement. But based on what? Trigger input? these ECMs have 3 inputs you can use IIRC. but I only know of one ground input which is what EFILive found.

[turbo_v6]

I think going to a spark cut vs. a fuel cut rev limit would be really nice and you wouldn't need any more inputs to do that.