Chrysler 3D Tables explained

[ShelGame]

So, I thought I'd start a new thread to explain how the Chrysler 3D tables work, for those that care (this is kind of an extension of the discussion going on in the Flashing SBECII thread).

OK, first, we'll look at the MAP transfer function as used for the 3D tables.

The MAP transfer functions are only used for the 3D tables. For all of the other 2D tables, the 'regular' MAP signal is used. The same MAP transfer function is used for all of the 3D tables. And, MAP is essentially converted into a 16-bit value, though not as you might think.

Here is the transfer function from 'MAP' to 'Lo-MAP':



You'll notice that the input MAP from -11.7psi to -7.9psi is rescaled over a full 8bits. I call this 'Lo-MAP'. This is the input to a fuel table and a timing table. This gives 1bit = 0.015psi resolution, which is much finer than the 'MAP' variables resolution of 1bit = 0.12psi. The timing table is easier, so I'll look at that first. Here's the 3D timing table:



In this shot, you can see that the Y-axis is MAP and has 9 values (8+1, or 1 for every bit in the Y-Axis input plus the 'end' value). And the X-Axis is RPM and has 17 values (16+1 or 1 for every bit in the X-Axis input + 1 for the end value). But, this table is used ONLY for lo-Map; for both part and full throttle. The key here is that the number of bits in the X or Y axis must be a multiple of the number of points on that axis on the 3D table, +1.

This example was relatively easy because the 'Lo-MAP' value is linear with MAP. But, in the case of Hi-MAP, this is not true:



This is the 'Hi-MAP' transfer function. As you can see, it takes over where Lo-MAP left off - -7.9psi, and goes up to 12.8psi. But, there is a break point in the transfer function. If you'll notice, the breakpoint is at 1.8psi. So, from -7.9 to 1.8 psi, MAP is rescaled from 0x00 to 0x9B. And, from 1.8 to 12.8 psi, MAP is rescaled from 0x9A to 0xFF. For the lo end of the 'Hi-MAP' variable, 1bit = 0.6psi, but for the upper end of the 'Hi-MAP' variable, 1bit = 0.1psi (lower resolution, but still better than the regular 8-bit 'MAP' variable). This 'Hi-MAP' variable is used anytime the MAP is in this range. Here's the Hi-MAP timing table:



You can see that this is a 16x16 3D table (well, 17x17, but the last value doesn't really count - I'll explain the lookup/interpolation in the next post). The difficult thing to get here, is that the Y-Axis is not linear due to the MAP transfer function. The first ~2/3 of the table is linear from -7.9 to 1.8 psi, and the last 3rd is linear from 1.8 to 12.8 psi.

I'll leave it at this for now. I'll post up about how the 3D lookup/interpolation works next. And, then I'll put a little info about the fuel tables, too.

[bakes]

needs to be in the KC

[turbovanman²]

Damn dude, you are simply too SMRT, What do you do for a living? Computer geek?

[ShelGame]

Car geek. And, I can't be that smrt, it's taken me 7 years to figure this $hit out...

[ShelGame]

OK, rather than explaining it on my own, I'm pasting Derek's (Beland, D-cal creator) explanation of the 3D lookup routine. This was originally posted on the CHeM Yahoo group:

I believe I have deciphered how the "3D" tables in SBECs work. The cal I was working with was a 91 T3, which should be in the files section. I'm not positive this is the *only* new table type, or that this is the only look up function, but it's at least one new one. I have not yet looked at any other cals.

I will share what I've learned.

The table processing function seems to be at D418, and it is called in about 5 places in the code that I can see so far. It usually seems to be used as a "modifier" on the output of other tables. In other words a call is made to an 8-bit table lookup, and the output of that table in register A is passed straight through to the 3D lookup. The B register is usually loaded with a value from the RAM area, and is presumably the "control".

The table handles both signed and unsigned data by indicating the type in the third header byte. It really only makes a small difference to the math.

Input to table address are in A and B and are values in the range 0-FF. These values are scaled into the width and height address range of the table and then used to look up the first byte. The fractional value of the table column address is retained and used to interpolate between this first byte and the next byte in the row. The last byte in a row will never be addressed directly, it's there strictly for the interpolation, which is why you see the width being DECremented in places. The last row in the table serves a similar purpose. The process is done a second time at the same column position, but in the next row down. The two column values derived are then interpolated between against the fractional Y address, and this value is returned in A.


The data format is pretty simple:

BYTE 0: Height, number of rows (Y dimension)
BYTE 1: Width, number of columns (X dimension)
BYTE 2: 0 = unsigned data, 80 (Bit 7 set) = signed data

BYTE 3: Width bytes data
BYTE 3+ (Width *1): Width bytes data
BYTE 3+ (Width *2): Width bytes data
...
BYTE (3 + Width * Height - 1): Last byte of data



What follows is the commented disassembly of the lookup function:


; 3D Table Lookup

; Inputs:
; A = 0-FF Y-Axis/Row address
; B = 0-FF X-Axis/Column address

; Output:
; A = Interpolated value from table

; Default is unsigned data
D418 18 CE D4 9B LD418: ldY #$D49B
D41C 1F 02 FF 04 brclr 2, X, #%11111111, LD424

; Signed data interpolation
D420 18 CE D4 97 ldY #$D497

; Making room on the stack for local variables
D424 18 3C LD424 pushY
D426 36 pushA
D427 36 pushA

; Get the number of columns in a row
D428 A6 01 ldaA 1, X

; Decrement because last byte is for interpolation
D42A 4A decA

; Scale input X value into table X-axis (A), save the fractional part (B)
for later
D42B 3D mul

; A = column number, B = fractional column value for interpolation

D42C 36 pushA
D42D 37 pushB

; Setup Y to be our frame for local variables on the stack
D42E 18 30 tSY

; Get input row index A value
D430 18 A6 02 ldaA 2, Y

; First table byte is number rows in table
D433 E6 00 ldaB 0, X

; Decrement because last row is for interolation only
D435 5A decB

D436 3D mul

; A = row number, B = fractional row value for interpolation

; Store the fraction for later
D437 18 E7 03 staB 3, Y

; Get number of columns in table, store for later
D43A E6 01 ldaB 1, X
D43C 18 E7 02 staB 2, Y

; Multiply row number by the width of a row to get byte-offset into table
D43F 3D mul

; Bump up X pointer past header to start of data
D440 08 incX
D441 08 incX
D442 08 incX

; Add offset into table to X
D443 3A aBX

; If offset is less than 0x100 (IE high byte = 0) then skip next bit
D444 4D tstA
D445 27 04 beq LD44B

; Add 100H to table offset pointer
; Note that this effectively limits the table to 0x1ff entries
D447 08 incX
D448 C6 FF ldaB #$FF
D44A 3A aBX

; Get interpolated column position
D44B 18 E6 01 LD44B ldaB 1, Y

; Add to table offset
D44E 3A aBX

; Get fractional portion of column address
D44F 18 E6 00 ldaB 0, Y

; We need Y for some calcs ahead, save it's value on the stack
D452 18 3C pushY

; Load the pointer to the interpolation entry point chosen at the beginning
D454 18 EE 04 ldY 4, Y

; Get the first data byte indexed from the table
D457 A6 00 ldaA 0, X

; Subtract the next byte in the row
D459 A0 01 subA 1, X

; Call the interpolator
D45B 18 AD 00 call 0, Y

; A contains the return value

; Restore local variable frame
D45E 18 38 popY

; Store interpolated table X value
D460 18 A7 01 staA 1, Y

; Get number of columns per row
D463 18 E6 02 ldaB 2, Y

; Advance table offset pointer to next row, same column
D466 3A aBX

; Get fractional column address from stack
D467 33 popB

; Save local variable frame pointer
D468 18 3C pushY

; Get interpolation function pointer
D46A 18 EE 04 ldY 4, Y

; Interpolate the value between the two points
D46D A6 00 ldaA 0, X
D46F A0 01 subA 1, X
D471 18 AD 00 call 0, Y
; A contains the interpolated value

; Restore local variable frame
D474 18 38 popY

; X now contains the local variable frame pointer
; This is done because the interpolation function expects
; X to point to the two point values, which for this last
; operation are stored on the stack in our local variable area
D476 30 tSX

; Store the row+1 interpolated value
D477 A7 01 staA 1, X

; Get the row address fraction
D479 E6 02 ldaB 2, X

; Get the interpolation function pointer
D47B 1A EE 03 ldY 3, X

; Perform a final interpolation of the values from the two rows
D47E A6 00 ldaA 0, X
D480 A0 01 subA 1, X
D482 18 AD 00 call 0, Y

; Clean up stack frame
D485 33 popB
D486 38 popX
D487 38 popX

; Return value is A
D488 39 ret



; Appears to be dead code? No references to it I can find
D489 E6 00 LD489: ldaB 0, X
D48B 5A decB
D48C 3D mul
D48D 37 pushB
D48E 16 tAB
D48F 5C incB
D490 3A aBX
D491 EC 00 ldD 0, X
D493 10 sBA
D494 33 popB
D495 20 04 jr LD49B


; This function interpolates the absolute value of the
; difference between two points
;
; Inputs:
; A = Delta between two points
; B = Fractional value 0-FF
; X = Pointer to first point
; Carry Flag = Result of Point1 - Point2
;
; Outputs:
; A = interpolated value

; Interpolation function, signed math entry point
; Branch if first byte was less than second
D497 2D 0A LD497: blt LD4A3
D499 20 02 jr LD49D

; Interpolation function, unsigned math entry point
; Branch if first byte was less than second
D49B 25 06 LD49B bcs LD4A3


; First byte was bigger than second
; Multiply delta x fraction
D49D 3D LD49D mul
; Round up
D49E 89 00 adcA #$00
; Negate result so that value subtracts from first byte
D4A0 40 negA
D4A1 20 04 jr LD4A7

; Second byte was bigger than first
; Get abs value of the delta
D4A3 40 LD4A3 negA
; Interpolate
D4A4 3D mul
; Round up
D4A5 89 00 adcA #$00

; Add the base value to the interpolated delta value
D4A7 AB 00 LD4A7 addA 0, X

; A returns the interpolated value
D4A9 39 ret

[ShelGame]

There is also a 2nd 3D table format used in the '92 and later code alongside this 3D table format/lookup. I'll have to check my notes on that table style and post about it later.

[zin]

my brain hurts now!

Mike

[wowzer]

thanks alot rob. i do have a couple more questions for you (imagine that!) that i'll pm you on once i digest this some more.

[risen]

Damn, dude. Nice work. I'll be looking at this thread plenty in the coming months, I'm sure.

I have one quick Q and one long Q. Quick one: is there a check before each lookup that checks whether the raw (non-scaled) map is in the high or low area? It looks like plugging a high map into the low map xfer will come out with a 254 (or close, it's hard to tell), probably not the desired result.

Long one:
There's always been 1 item that sort of bugs me about this rescaling. I don't understand how the output resolution for map can be any greater than the input resolution. So you have a 0-255 bit value to start with, which has a definite minimum granularity: 1. It almost seems to me that there would be large swaths of the transfer slope that could never be touched because the input isn't granular enough.

For example say you have line that is y=5x, where x must be a positive integer. So for each x point the y point is equal to 5 times it. This means that, for this example, you can only ever have points on intervals of five. You would never be able to get to the point y=22 because it would require a fractional x which is not possible. So how does this make things any better? Wouldn't it mean that there's bits in the 3d table that will never be used because the measurement of the map signal wasn't granular enough in the 1st place?

Or is it only do to achive greater granularity in the output of the 3d tables?

I'm going to need a whole lunch hour just to read through (nevermind understand) Derek's reversing of the lookup funciton.

[ShelGame]

Damn, dude. Nice work. I'll be looking at this thread plenty in the coming months, I'm sure.

I have one quick Q and one long Q. Quick one: is there a check before each lookup that checks whether the raw (non-scaled) map is in the high or low area? It looks like plugging a high map into the low map xfer will come out with a 254 (or close, it's hard to tell), probably not the desired result.

Long one:
There's always been 1 item that sort of bugs me about this rescaling. I don't understand how the output resolution for map can be any greater than the input resolution. So you have a 0-255 bit value to start with, which has a definite minimum granularity: 1. It almost seems to me that there would be large swaths of the transfer slope that could never be touched because the input isn't granular enough.

For example say you have line that is y=5x, where x must be a positive integer. So for each x point the y point is equal to 5 times it. This means that, for this example, you can only ever have points on intervals of five. You would never be able to get to the point y=22 because it would require a fractional x which is not possible. So how does this make things any better? Wouldn't it mean that there's bits in the 3d table that will never be used because the measurement of the map signal wasn't granular enough in the 1st place?

Or is it only do to achive greater granularity in the output of the 3d tables?

I'm going to need a whole lunch hour just to read through (nevermind understand) Derek's reversing of the lookup funciton.

Yes, there's a check before the lookup to decide which 2D/3D combination to use.

About the re-scale, that's a good point - that I hadn't considered. It may simply be that they wanted the added resolution in the 3D table and this was the simple way to get it. But, in that case, I really don't understand the reasoning behind making the Hi-MAP variable non-linear.

[janus]

wow, nice progress there it will take me some time to understand and follow as well.. thanks for your effort.

OK, rather than explaining it on my own, I'm pasting Derek's (Beland, D-cal creator) explanation of the 3D lookup routine. This was originally posted on the CHeM Yahoo group

aaah, that's where i found this though i don't understand much of this anyways.

btw, not completely on-topic, but.. did you already get a chance to upload the '92 2.5 T1 .bin? anyone know if there is a high-torque and a standard variant of this?

[Aries_Turbo]

dang.... its going to be a while before i can wrap my mind around that enough that i could tune with it

Brian

[turbo_III]

dang.... its going to be a while before i can wrap my mind around that enough that i could tune with it

Brian

I'll definitely 2nd that! But I'm glad someone knows how to figure this stuff out, it's simply amazing Rob