Im working on the $0D ecm at the moment and a math op. in the lag filter routine has me a bit confused...

Heres the code:

The thing thats confusing me is the operations that follow when the old value is greater then the new value and the results of subtracting the old value from the new value are negative.

From there they branch to LF0EO to multiply the negative delta value by the filter coeff and subtract out the filter coeff x 256.

The ultimate function of this is to give the filterd output in D = Old value x 256 + (Filter coeff x (New value - Old value)x256)/256, when the subtraction op. results in a negative delta value.

I know that it does work, and it gives the same results as the above equation, but how? Could somebody maybe give me a walkthrough of how the binary operations work when the code is dealing with the negative values? Is it just creative use of the overflows that will result with a 16 bit accumulator to get the desired result?

 

This "may" help.
Negative binaries hurt my head
http://www.allaboutcircuits.com/vol_4/chpt_2/3.html

 

The thing is that theyre doing operations on negative numbers using an unsigned 16 bit result from the mult. and subtraction operations. Im sure theres a stupid little trick or tricks that allow them to do that and get the right results in the end. Ive been tempted to do something similar with stuff Ive done but not having signed values doesnt seem kosher.

 

Ok, the operation at LF0E0 is equivelent to saying: -filter coeff x (Delta value + 1) for the MSB of the filtered value. Is the "+1" basically to account for the carry that would occur when the negative result is added into a positive value in the later operations?

 

D = Old value x 256 + (Filter coeff x (New value - Old value)x256)/256

is the same as saying

Old value x 256 - (Filter coeff x (Old value - New value)x256)/256

Right?

 

Yes, I just put it as it appears in the code, but why subtract out the filter coeff x 256 after multiplication when the result of the delta is negative? IOW, what operation does that accomplish?

 

Same instruction set as the 68HC11, right?

 

This is on the late model TBI pcm, so its the 68HC11, or something similar. The older procs in the early carb(I think), tbi, and tpi ecms also use the same instruction set, minus some of the more advanced instructions.

 

Well..... When I see these things:

;-General form: D = Old value x 256 + (Filter coeff x (New value - Old value)x256)/256

it sort of drives me nuts. I don't think it helps to explain what is going on very well. Let's take a simpler look. It is really:

New filtered value = old filtered value + (new raw value - old filtered value) * Filter coeff.

So for an example, if the old value was 100, the new raw value is 110 and the filter coeff is 0.50, it looks like this:

New filtered value = 100 + (110-100) * 0.5

New filtered value = 100 + (10) * 0.5 = 105.

Easy to see that way.

Now the problem that you have in trying to "see" what is going on is complicated by the way it is presented in that awful equation. The "new value being higher" case is easy to see from the way it is documented in your code. The "new value being lower" case is not.

Maybe this will make it easier, it is from the new value being lower branch.

In the above case we have a negative hex number after the subtraction. It is represented using two's complement, or in other words, it is one minus the number, or it equals (1-delta)

So from this, implied in the muliplication is:

(1-delta) times the Fc.

The result after the muliplication is:

(Fc-scaled delta).

So the next line after the multiplication is subtracting out the Fc. This results in:

(Fc - scaled delta) - Fc or:

-scaled delta.

The - scaled delta (a negative value) is then added into the old result, resulting in the filter action that we wanted.

If that is not clear, maybe I can try it again....

ScotSea

 

The reason all of it will be represented that way is so I know at a glance exactly how the code flows. It looks like **** as a hack, and led to the same initial self-induced confusion with the 8063, but when it came time to do a massive overhaul, it paid off, for me at least. Having the exact representation allowed me to see at a quick glance how the code fits together without having to trace through it. Itll cause some pain initially, but hopefully it should equate to faster changes in the future. So thats the explanation for that...

And yes, thats perfectly clear. Thank you. I have zero formal training so even when I wrote it out in the human-freindly form above, I still didnt think to think 'two's conpontent'.

 

Aw man, I really feel even more stupid then usual now. I just went to clear the stack of papers off that I was scribbling on the last time I worked on the hack and I had the answer right there: FCx(deltax256-256) = -FC(|delta|) = NEG??? (negate)

Im going to go get some sleep to clear the pea soup fog around my head from squeezing working overtime/trying to fix both of my cars+old mans' car/exercise/sleep/drink beer + watch tv into one day for an entire week.

 

Think of it this way, if it really were binary math you would have to figure it all out with just zero's and one's. Don't you feel better now?