understanding table lookups

[steveo]

finally getting back into hacking EE, im having a bit of trouble getting from A to B on this one table that i've always considered a top priority.

i'm trying to figure out how a table lookup is scaling MAP KPA against each column in a 5 column table (ex. is it 20,30,40,50,60kpa or what)

i have a table.


26F2 bt3_26f2_3dlkup_table_sizes:
26F2 db $00, $00, $05
26F5 bt75?_26f5_what_bpw_related_f(cooltmp,load):
26F5 db $45, $56, $5C, $62, $68, $45, $56, $5C, $62, $68
26FF db $45, $56, $5C, $62, $68, $45, $56, $5C, $62, $68
2709 db $40, $50, $56, $5B, $61, $2E, $39, $3E, $43, $48
2713 db $24, $2C, $31, $36, $3A, $1B, $21, $25, $2A, $2E
271D db $17, $1C, $21, $26, $2B, $13, $18, $1D, $22, $28
2727 db $0F, $13, $18, $1E, $23, $0A, $0C, $12, $18, $1E
2731 db $06, $08, $0A, $0C, $0E, $06, $08, $0A, $0C, $0E
273B db $06, $08, $0A, $0C, $0E

it's 5 columns of MAP by 15 rows of coolant temperature (picture attached).


659F B6 01 93 @243 ldaA l_0193_CoolTmp_fltrd_$f0_max_$e0
65A2 F6 01 6B ldaB l_016b_(ADMAP-26)*151*2/256
65A5 54 lsrB
65A6 54 lsrB
65A7 CE 26 F2 ldX #$26F2

and here's the lookup subroutine


;; lkup3d_sub: ; A row, B col, X tbl addr, A returned val
65AA A0 00 subA 0, X ; CALC ROW ARG OFFSET, (LIMITED TO 0)
65AC 24 01 bcc @244
65AE 4F clrA ; ... ELSE
65AF E0 01 @244 subB 1, X ; CALC COL ARG OFFSET, (LIMITED TO 0)
65B1 24 01 bcc @245
65B3 5F clrB ; ... ELSE
65B4 3C @245 pushX ; XFER TABLE ADDR TO Y REG
65B5 18 38 popY
65B7 36 pushA ; SAVE ROW ADDRESS
65B8 86 10 ldaA #$10 ; SPLIT COL ARG INTO TABLE OFFSET
65BA 3D mul ; & INTERP PORTION
65BB 37 pushB ; SAVE INTERP PORTION TO STACK
65BC 16 tAB
65BD 3A aBX
65BE 33 popB
65BF 32 popA ; GET ROW ARG
65C0 37 pushB
65C1 C6 10 ldaB #$10 ; SPLIT ROW ARG INTO R
65C3 3D mul ; TABLE NUMBER
65C4 37 pushB ; (MAX RESULT IS 255D)
65C5 18 E6 02 ldaB 2, Y
65C8 3D mul
65C9 3A aBX
65CA 3C pushX
65CB 18 E6 02 ldaB 2, Y
65CE 3A aBX
65CF 18 30 tSY
65D1 EC 03 ldD 3, X
65D3 10 sBA
65D4 18 E6 03 ldaB 3, Y
65D7 24 06 bcc @246
65D9 40 negA
65DA 3D mul
65DB A9 03 adcA 3, X

(ADMAP-26)*151*2/256 is calculated as:


5891 B6 01 2A ldaA l_012a_ADMAP
5894 80 1A subA #$1A ; ADMAP - 26
5896 24 01 bcc @18 ;br if ADMAP > 26
5898 4F clrA ; else min zero
5899 C6 97 @18 ldaB #$97
589B 3D mul ; (ADMAP-26)*151
589C 05 lslD ; * 2
589D 25 06 bcs @19
589F CB 80 addB #$80
58A1 89 00 adcA #$00 ; round up D to whole msb A ?
58A3 24 02 bcc @20
58A5 86 FF @19 ldaA #$FF
58A7 B7 01 6B @20 staA l_016b_(ADMAP-26)*151*2/256 ; (ADMAP-26)*151*2/256

i can make a very clear assumption on the table rows, being coolant temp against 15 rows, it's the same as every other vs coolant temp table in EE.

but this map thing is throwing me for a loop.

i know once i wrap my head around this more simple table, i'll start making some real sense of some other more mysterious tables.

any ideas?

[RobertISaar]

your new MAP value:

raw A/D - 26 A/D counts(9.59kPa), and the 10.354kPa offset(19.95kPa, so 20kPa).

multiplied with 151 into a 16-bit accumulator, then multiplied by 2 into the same 16-bit accumulator.(effectively, multiplied by 302)

if overflow set to 255, if not add 128 to LSB and check to see if MSB should be rounded up.

now, save only the MSB.

assuming you go into this with a value of 20kPa, you end up at 0.
if you go into this at 40kPa(~53A/D counts), you end up at $20(d32).
100kPa should be $80.

looks to be a normalized MAP value, equation of X * .625 + 20 = kPa.



table lookup code..... new MAP value gets hit with two LSRB before entering, so intervals quadruple from that alone, still appears to start at 20kPa. assumption would favor 20kPa between intervals(especially with it lining up nicely with the maximum value the MAP value can become), but the two LSRB are throwing me for a loop and making me want to say 40kPa intervals, which would run up to 180kPa...... it's too early for this much math.

[steveo]

haha i know the feeling, i woke up in a cold sweat at 3AM for some reason this morning and went "ugh....must...solve...mystery fueling table..."

thanks for looking at it, maybe a bit later we'll both be awake and make something out of it.

of course this is only part of the problem, i still haven't traced the result of the lookup to anything substantial.

what i DID do this morning is find more concrete evidence on that stoich afr constant you spotted earlier.

i followed it all over the place. both open loop 3d afr lookup and that stoich value store an AFR value in the same memory locations, and in the same format, and i tracked them as far as being used with BLM calcs, so i think we got it. im still confused by one part still, but workin' on that.....

[steveo]

i think i have just found the power enrich active flag and marked a couple of references in spark calcs, which is a BIG deal... since i can use it to track down the calculated additional PE spark in EE and patch it out. that one has been a gigantic inconsistent pain in the ass for every dyno queen and 1/4 mile junky shooting for another 0.001; i'd LOVE to get rid of it

[kur4o]

I am glad you are back on ee dissasembly. I am slowly learning to read diss language and recently make some progress in hacking the code.
What you need to do first is to map the ram region, after that it`s easy. Still haven`t found anything related to the PE spark adder.
This is some beta version for xdf based on your latest release. Still nothing is fully confirmed, so no responsibiity is taken.
Shoot me a pm to share more of my work, so we don`t waste time

[steveo]

oh hey! you're still working on it too? awesome, i was just digging up old threads the other day and wondered where you went

i just started again, so i dont have much going yet... but i have a bunch o' little stuff added to mine too, so i'll take the time to diff yours against mine and integrate it, and send it back to you so we're workin on a common copy.

lets keep a common version going; though.. i'd hate to end up with your eex and my eex and nobody willing to put the time into merging. do you know how to use github? i can make a repository we can push/pull changes.

[steveo]

one thing that'd be a huge help as you're going is to set the category of everything you find to 'unknown/research'

i use that category as a filter to keep tested/untested stuff seperate, so new users aren't confused by what works and what doesn't.

[steveo]

damn you did a lot of work on unknown table defining. thanks a lot for that, saves me a bunch of work

[fbody_Brian]

I'm glad this isn't dead and things appear to be moving forward. Thanks for putting in the work guys. :)

[steveo]

as long as my car is running at least i'm motivated. my goals for the end of the year are to put that stupid 'transient fueling' section to bed, find pe added spark, make an open loop idle patch, and finally make my flash tool, at least with read capability completed and tested.

[kur4o]

I arrange everything from hex adress, below the category view. All tables and scalars for e-side are 99% mapped.
I was thinking of hacking xdf file and paste and copy needed parameters, maybe using some xml editor.
I just dig in this transient fuel routine, what it does is substract fuel from base fuel mass. It looks like correction for fuel pressure drop at high vacuum.
The first table is for fuel which is corrected with 2 other lookup tables, than is compared to second table which is used for airflow calculation and finally the result is compared to another table for airflow and some scalars, if it doesn`t meet final comparison, there is no correction made.
I will pm you a link with some usefull stuff, and I will put there the beta versions. I can get yours from your site

[steveo]

i should mention a few well known sources have stated that flag and those tables exist to compensate for charcoal canister purge activity; i've just never believed it.. and you'd figure that would be an enrichment, not enleanment. can't wait to look at it a bit more when i get off work and try to figure out what it does.

do you have any thoughts on the MAP scale of those table columns? i've stared at it a bit more and i'm lost

[kur4o]

It only substract fuel, never adds.
There isn`t any flag for using the routine, or flag set at least on the e-side it`s force loaded below 4000 rpm, above there is some skip routine that i can`t figure out how it works yet
Byte_C0 is base fuel mass
-Byte_C2 is base fuel mass with transient correction
-Byte_C2 is loaded from Byte_C0 if no correction applied
You need to trace this to t-side memory loctaions and check it agains Purge canister enable flags to confirm it. there is no way for e-side to know when purge is enabed. Also all BPW calculations are made from Byte_C2.

My theory is that at low engine load the fuel pressure drops because the fuel pressure regulator is vacuum regulated. And this routine compensate for it.

Also some interesting find is that injector ofsett table is used only If the calculated base BPW is below 1.953152ms.
If it is above there is no corrections made.


I still have no idea how tables are scaled.

[steveo]

but if i'm correct, there's a flag that completely skips lookups in those two tables; 0x12028 bit 6

[steveo]

My theory is that at low engine load the fuel pressure drops because the fuel pressure regulator is vacuum regulated. And this routine compensate for it.

that could be, i was under the understanding that little to no compensation is required for port FI engines with vac referenced regulators due to the fact it's just maintaining equilibrium between rail pressure and manifold vacuum (regulator is calibrated so the extra difficulty in injecting fuel at higher manifold pressures is accounted for).

will be interesting to see what it ends up being, if we ever even manage to find out - might be one of those calibration tables that we'll never truly explain.

the really cool thing is if it does operate in the low MAP ranges, it might be able to be jacked up and used for decel enleanment, which is another BIG HUGE GLARING THING that's missing from EE. right now, you have to jack around with timing to bandaid tune burbling and popping on decel with high overlap cams.

speaking of, could this perhaps be decel enleanment...? the determination of a state of decel should be able to be found easily, as at some point, it must branch on decel to kick into BLM cell 17.

[fbody_Brian]

and finally make my flash tool, at least with read capability completed and tested.

Please tell me this is a *nix flash tool!
If not, and it's windows only I would gladly work on a port.
:)

[steveo]

I will be making the unix libftdi version first. hope you will be a beta tester.

[kur4o]

Hi
I need help.
I know it`s some arithmetic function. I need to know how the result is calculated.





tab
ldx #$80
abx
ldab byte_19A
abx
ldab #$93
clra
fdiv
stx byte_19B

[steveo]

i think this is it? appears to just be a simple division of an 8 bit value by a 16 bit one (which is just some stuff added together).

tab ; b = a
ldx #$80 ; X = 0x80
abx ; x = x + b (so x=a+0x80)
ldab byte_19A ; b = byte_19A
abx ; x = x + b (x=a+0x80+byte_19A)
ldab #$93 ; b = 0x93 (dec147)
clra ; clear a (or the highest 8 bits from D, which is just a and b stuck together to make 16 bits)
fdiv ; divide D by X (actually divide b(0x93) by x) result in X, remainder in d
stx byte_19B ; result byte_19B = 0x93 / ( a + 0x80 + byte_19A )

[steveo]

also if you aren't aware of it, the remainder of that division should be stored in D, just in case it's used after...

[steveo]

I'd be interested to have my work checked as I'm still learning too...

[kur4o]

I think is kind of percentage calculation for $93

$80 is the mid point or 1 so it can use negative values.

I am trying to figure out the formula to convert it to percentage for the a and byte_19a.

The interesting part is the result of this is the AFR for PE mode

[steveo]

definitely could be; that's one thing that's always messed with my head in disassembly is determining signedness.

i think i have some disassembly notes from that calculation now that you mention it; what offset is that? i'll throw you what i have when i get home

[kur4o]

If 00 to FF is 100%
$1 increase will be 0.390625%

$80 is the mid point
everything above $80 will be positive increase >1
everything below $80 will be negative increase <1
with this kind of formula we are limited to +- 50%
If the resolution is correct the formula for pe afr will be like this

14.7/(((((X+Y)-128)*0.39062)+100)/100)
X=converted to decimal pe vs rpm value ( this value can be positive and negative it`s ofsetted by $80)
y=converted to decimal pe vs coolant value( this value is only positive. It should be added to x to function correctly)

But still have no clue how this fractional divide 16x16 is calculated

[steveo]

the description just isn't clear. it's just 16 bit by 16 bit division. divide X by D, store result in X and remainder in D.

your formula does seem to match what conversion values have already been determined for the rpm and coolant PE tables, so i think you got it.

[kur4o]

Finally some insight about that fraction thing.
This is the way PE AFR is calculated


14.7/((($80+X+Y)/2)/128)

X=value from PE table vs coolant
Y=value from PE table vs RPM


The PE AFR value is compared to Overheat AFR, CAT protect AFR and finally to Open loop table AFR and the lowest value is used.
Which means if the PE AFR > OPEN LOOP AFR, the open loop AFR is used.
If the BLM is on and Voltage > 3V than 14.7 is used for AFR

[kur4o]

OK
I must have figure it out now
This is how PE AFR is calculated in $EE code


loc_4174:
tab ; load B with pe vs rpm result
ldx #$80 ; 'À' ; load X with $80
abx ; add PE VS RPM to X
ldab byte_19A
abx ; add PE VS coolant to X
ldab #$93 ; 'Ó' ; load stoich 14.7 for PE
clra
fdiv ; ($9300/($80+$PEvsRPM+$PEvsCOOLANT))/10=PEAFR
stx byte_19B store PE AFR

I guess the formula needs to be updated(hope for the last time)

[steveo]

($9300/($80+$PEvsRPM+$PEvsCOOLANT))/10=PEAFR

i'll have to look at this with a few less beers in me, but i have noticed that the pe afrs in my xdf have been wacky. thanks for the research!