I've mostly written a patch that I'm going to test soon and then release if it works, but I'm not 100% schooled up on the workings of sub routines in our engine ECU code.

Could someone please explain the difference between these three sections of code that are at the start and end of every sub routine that I've looked at? I'm guessing that they are for saving and retrieving the rom address that the sub branched from? If so, why are there (at least) three ways of doing it?


I won't share what the patch is just in case it doesn't work and to build the surprise for if it does work. You can possibly figure out what I'm up to based on the screenshots, though!

 

Figured it out by reading the superh doc I forgot I needed to read and by reading this old thread: https://www.evolutionm.net/forums/ec...structure.html

Methods 1 & 2 are storing the return address from the procedure register (pr) in a stack specified by the address in r15.This needs to be done because otherwise the code would get lost if it tries to return from jumping into nested subroutines. Method 1 also stores (and later retrieves) the value in r1.

 

Calling Convention...

 

Let's meet at the (dis)assembly ro(o)m.

I'll message you Dow Jhob about the little patch I'm writing if you're happy with that? BTW would love to hear more about all your mods you've done.

 

no, I’m done with “big sports”, you can present your achievements right here, it will be interesting to read

 

I wouldn't say I've achieved anything yet, but I'm not too far off. The mod I'm working on wasn't as easy as first thought, simply because I didn't realise that any branch instruction is delayed - hence the regular use of NOP's in the code. I had thought that I could shuffle the code around by deleting the NOP's and therefore gain some bytes for new code. Instead, I'll be moving a section of code to a different area of the ROM to afford some room. On the scale of programming, I know it's not complex stuff but it helps when I know the rules!

A picture is worth 1000 words, so for anyone interested:


Dow Jhob, are there any tips or tricks you think are worth sharing that might otherwise catch someone out?

On a tangent: I'd love to see any/all of your mods in the wild Having CANBus on a CT9A engine ECU opens up the possibility of using an Evo X ACD ECU on the CT9a chassis to expand its capabilities. It would require additional braking-related hardware, though, so wouldn't be a small job. I suspect this exact setup is how Mitsubishi tested the Evo X S-AWC system on their Evo 9 test mule back in ~2006/2007

 

all jump commands afaik have speculative execution of the next command, that is, while the jump is being calculated, the processor can execute another command, this feature is most likely enabled by the aggressive optimization flags, the evo code is apparently compiled with default settings, so as a rule, after the jump commands there are nops, Well, if you are going to remove them, then what to do with the calculation of relative transition addresses that should be aligned along the 32-bit boundary???

 

Could you please elaborate on " should be aligned along the 32-bit boundary"? I'm not terribly schooled-up on programming, but know enough to just get by.

I suspect that I won't be breaching any rules as I will keep all of the NOP's after the jump commands (and yes, every jump command is delayed). The instruction immediately before each jump command is the setting of the address to jump to and it's illegal to put that after the jump command, despite it being delayed. You'll see in the rom I release (fingers-crossed) that I simply moved sections of code to empty parts of the ROM to give enough space for the additional code.

 

You need to start too far away.. Explanation of the need for leveling is somewhat off-forum topic, too prosaic

 

No worries that you don't want to elaborate; I finished the patch last night and successfully tested it today.

If anyone out there has a Tephra V7 9626-based ROM and wants to adjust their timing based on gear and load, please PM me. This is V1 of the patch and it works fine but I think I should make it a little more customisable.

I'll post up a graph or two based on my log once I make one that's easily digestable.

 

Here we go:

The number in brackets for each trend is the amount of timing advance correction while under high load.

I know my chart isn't great - I didn't have too much time nor clear space to run through the gears, but you can see that 2nd gear has the greatest timing advance and that 5th gear has the greatest retard. Man, did 5th gear feel sluggish.

The load/boost was equal for each gear, so I was tracing roughly the same load/rpm path in the timing 3D timing advance map.

BTW I always wanted to get this going after this thread came out: https://www.evolutionm.net/forums/ec...-per-gear.html
It's only taken me 12 years to give it a go myself! My patch is more advanced than what was attempted in the thread, but it was my starting point.

 

Latest update: I've updated my ROM so the car knows its own engine acceleration apparently some other Mitsubishi's know theirs and now my Evo does, too.

Admittedly, it's not perfect yet but here's a chart:

I only really got to test out 1st, 2nd and 3rd but you can clearly see that the rate of acceleration is highest in 1st and lowest in 5th (I only tested 5th up to 3000 RPM).
Not shown is how it reacted when I experienced knock - the negative acceleration shows up as very high numbers due to two's complement. I'll figure that out next.

After I figure that out, I'll set up a timing trim table that will then be able to add some timing depending on how fast the engine is accelerating while under load. I'll set the cut points for what I'd typically expect the acceleration profiles to be in 1st and 2nd, but hey if I'm in 4th and accelerating down a hill then maybe it'll apply then, too.

 

I arrived at this point after that what should I do

 

What would you like to receive?

 

​​​​​​​Point is I would like open bin file to get address each table for create xml definition for my car to reflash it