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.