Is it possible to rescale tables? I want to get more resolution out of the spark tables. If I were to change the min and max load values at LC10D to 0 and LCEB1/LCEB5 to 90, would the ecm rescale the table increments accordingly or will it only work in increments of 32? This is for $6E.

 

You would have to move the table itself to a new location.
Change the lookup address.
Change the logical shift scalar of the axis you want more resolution for.

 

Why is moving the table needed? And where do I find said scalar?

 

The changes need to be assembly and and then recompiled.

 

I would not attempt this if you're asking these questions.

 

Lol it's part of this project I've been working on for a few years. I don't have a background in programming or electronics and I'm completely self taught, but I've managed to get pretty far with this. I don't use a compiler, where in the code can I find this? Or am I barking up the wrong tree asking this?

 

You need to learn how your bin pulls tables to figure out what to change and where. There is no "scalar" per se. It is done with logical shifts. This isn't something quick and easy to do unless you've already disassembled the rom and if you have the. You should already know this part.
You cant simply add resolution to the current table as you'd have to have more ROM space for more table values. You can't just tack them on so you have to move the entire table to an empty part of the rom and rebuild it with the correct number of values.

 

Ok so I need to study the lookup subroutine... there's no quick & dirty way to change the units from 32 lv8 increments to 16 lv8 increments? I don't necessarily need to double the table for more resolution, I just want to halve the range it covers since I'm using a 3 bar map with a big range. That could be done by changing the # of logical shifts, no? It looks like something similar is already done with an existing option bit for that table.

 

I can't actually help you with addressing or anything truly helpful as that would require me doing it for you and I don't have time, but if you're wanting to limit the range that would probably require reworking the code when it pulls the values prior to a LU routine to make sure it's in range or at minimum reworking the start point of LU values.

If you can find a commented disassembly you can easily find what you need and use a hex editor to tackle the meat and potatoes rather quickly.

 

I have a good dissasembly I've been working off. So looking at the option byte for this table 0 = 32-160 units and 4 = 32-256 units, in which case LSRB gets skipped. Changing the logical shift is what's needed.

 

Ok looking over the code again if the option is 0 then the LSRB is skipped. A right shift is the equivalent of X / 2, correct?

 

If you post up a screenshot or some code I can help, but I can't comment without seeing it.

 

Do you have a test bench? If not get your self one so you can test any code changes before trying them in the car and verify they actually work.

 

I do live on-car testing but I wouldn't recommend it.

 

I have a partially built test bench but I'm still testing on car. Here's what I'm looking at.

 

Any advice?

 

edited
So you can sub nop or a jump instead of the logical shift. Then change the address to point to a custom table you build in an empty rom spot.

I didn't look in detail at your coding since I can't completely follow any of it without everything but that's the gist of what to do assuming I was right.

EDIT: Can't see on my phone.

 

I know nothing about that rom, but is that the main spark table you're working on? Shouldn't it be load/rpm not load coolant?

 

I'm working on the coolant compensation table, not the main table.

 

I see. It's much easier to look at this on a computer than my phone. I noticed that there's clearly only one LU table referenced being that this is the ECT table that makes more sense.
I didn't see anything on my phone...

 

The easiest way to do this I've outlined, but here is how YOU do it.
1 Find big empty ROM space.
2 Copy and paste old table to the new empty spot.
3 Find a table that is scaled how you want it.
4 Edit your XDF in Tunerpro to point to the new table address using identical settings, except the change in the load? axis. Use the table from step 3 to scale the axis for this new table and the number of data cells. Make sure the table looks correct (but the DATA shouldn't at this point. Only the first few top cells will look right, then there should be zeros finishing the row out.)

5 Find the LU routine for the table that is scaled how you want it in the disassembly.
6 Look at how it's scaled when pulled for LU through a logical shift (or not).
7 Make this table scale the same way as the table that's scaled how you want. a nop can be used to delete the instruction altogether. (I've done it).

8 Change the LU address to point to the new table you created.
9 Edit the table in tuner pro so that it looks correct.

10 test it out prior to doing anything in your car. I am not liable for any of your tinkering!

 

Or another way is to cut into the code and make it jump to your own subroutine.
1 Wherever you want the cut to happen put in a jump or branch instruction.
2 Just before you want to jump back to OEM code put a JSR instruction.
3 Make step one point to step 2.
4 In a blank rom space create your subroutine followed by a return from subroutine instruction.

 

Modding the existing code is the way to go. I may have to look at a table from another mask since there's only 3 3d tables in $6E, none are scaled the way I need. Thanks for the help.

 

$8d has plenty to see.