Hmm, interesting point. sub_DE0/sub_C28 is effectively constant-time, but sub_CC6 has to loop over the length of the axis until it has gets a hit. So, for the fuel map, we're introducing a 2x increase in cost on one axis, and a 1.4x increase on the other. Then we're looking at another (smaller) increase in complexity on the ignition table axes.

Can simsh do cycle-counting? (I haven't even installed it yet. ) And if it did, would that number even help us much, realistically speaking? I don't know that we have a good handle yet on the cost of a single run through the main loop on the ECU, and what our real-world timing constraints are, do we? We could probably make a solid educated guess for a given target RPM, though.

I think I'm with tephra, though: this seems like a relatively innocuous change, considering how much other work is going on. I suspect the current sizing of the maps was more a function of maximizing available space than anything else, but that's just a guess.

 

For the fuel map example, I believe the effective hit is 2.0*1.4 = 2.8. I just took another look at the size of sub_CC6, and its much smaller than I remember. It probably is a marginal hit, but it would be interesting to confirm with some cycle counts.

 

Rough out the operations before/after in psuedo code and we can get a rough O(N) of the operations. Without hard timing that will probably be good enough to get in the ballpark.

Edit opps now re-read what was said above. Is it really truly just linear as implied above?

 

Geeky info: most basic SH instructions are executed in a single cycle, with multiplicative instructions taking either 2 cycles (for 32-bit results) or 2-4 cycles (for 64-bit results). For a 7052 or 7055 running at 40MHz, that's 25ns per instruction (cycle).

It's really a rather impressive little CPU, given it's age.

codgi: the table lookup itself is linear, but each axis lookup is a loop over it's length (short-circuiting when a match is found).

 

Now that I think about it again, the hit is additive: 2.0 + 1.4 = 3.4.

logic, don't know if you heard from jcsbanks, but the GTR ECU uses an SH processor.

 

Donated towards hopefully a 94170015 map upscale!

I'm a newb and hardly understand half this ****, but I still am stoked for the idea~!

I wish I had the knowledge/motivation to contribute, but oh well.....

 

That won't happen, all EVO8's run 96530006 ROM now.

 

I tried it but i am getting throttle hang. Switched back to 94170015 and its gone. Any solution?

(i know this is the wrong thread but just trying to get a quick answer)

 

I also noticed the throttle hang as well but I just live with it. I mentioned it to a buddy that has a 9 and he said he has had throttle hang from the factory since day one. So I just deal with it and consider it a deceleration issue that we haven't found the XML definition for yet, which is most likely the case.

 

have u tried fiddling with the ISCStepper table?

 

I still see issues with some 8s running this rom. I have logged ICSV steps and it seems inline with what it should be. on the flip i have never had issues with 94170015

 

I had no idea; they'll be hailing him as the conquering hero over in that community, then.

 

interesting to note that the Axis lookup routine will actually run slower OR faster depending how far into the axis the lookup is.

ie if it's right at the end then the routine will take the longest to run.

is that what you guys think as well?

 

+1 The 8's seems to be more at home with the 94170015 rom for some reason.

 

All 05+ EVOs have that throttle hang. And Im guess since the 0006 ROm is a 05 ROM thats why.

Fiddling with the ISCstepper table can get rid of the hang, at the expense of messing up the cold start.

I believe the key to properly curing throttle hang is in the "Decel fuel cut delay" tables. But a lil hard to test since I have an 04 w/ 96420008 ROM.