[Gmecm] $58 F29/F29E VE lookup weirdness
Rob Handley
Robin
Fri Aug 24 17:51:16 UTC 2007
Many thanks. :-)
I've no plans to go over 256 bytes ATM, but you never know !
Robin
----- Original Message -----
From: "Dig" <turbodig at yahoo.com>
To: <gmecm at diy-efi.org>
Sent: 24 August 2007 15:46
Subject: Long: Re: [Gmecm] $58 F29/F29E VE lookup weirdness
Not sure this will come through right... needs a proportional font.
Anyway, the gist of the table bug is that it won't support a table larger
than 256 bytes.
Maybe not so much a bug, but an acknowledged limitation.
So, as long as you stay under 256 bytes, the stock code is ok. You can go up
to a 16x16
without trouble; we wanted to maintain the same table separation (~10kpa)
that the original
table had, which necessitated a bigger table.
This was the "repaired" routine that we ended up using. The meat of the
problem is
the abx instruction (commented out, here). The row start offset was being
limited to a
8-bit value... we upped it to a 16-bit value. This allows for some
potentially huge tables!
(Not like you 'd wanna get much larger than we have; it's a lot of data to
follow)
If you wanna see how this works, you can pretty much run the whole thing
within Wookie.
Step through with various values in A and B, and watch it work.
Hope that helps...
Dig
;************************************************************************
; 3D Lookup Routine, Interpolates between rows as well as columns.
;
; Enter with:
; R = number of rows in table
; Q = minimum value of columns
; RNUM = Number of Q values, (columns) Rnum must be $20!
;
; Max Value Diff between talbe entries = 255
; Call With:
; A = Row Arg; B = Col Arg
; X = Tbl Addr
;
; rtsurns with:
; ACCA = Result, Comments added by Dig, 5/17/06
; Revisions: Changed ABX to addd 0,x, fixes overflow problem
with large tables.
; Changed column size to 32
;*************************************************************************
NLF5E6 subA 0, X ; subtract the starting offset from RPM
pshB ;save map
pshx ;save start of table
bcc NLF5ED
clrA ;check to see if A was less than the offset + clear
if necessary
NLF5ED subB 1, X ;subtract the column offset from MAP
bcc NLF5F2
clrB ;again, check to see if it's less, and clear if
necessary.
NLF5F2 pshB ;save that result
ldaB #$10 ;Load 16, the number of rows.
mul ;multiply corrected column value * number of rows.
pshB ;save the low (fractional part) upper part has row
index?
ldaB 2, X ;load column length from table
pshB ;save column length
mul ;multiply column length * what's in A.. row index?
;let's try something....
pshx ;save X to stack.
tsx ; get the stack pointer in X
addd 0,x ; adds all of D to the start addr
pshb
psha ;puts what's in D, in X... D
pulx ;pull d back into x
ins
ins ;fix our stack shennanigans
;aBX ;add to x... to get a row start... ahh, but row
start is in A+B! fixed 5/17/06
inx
inx
inx ;add 3 to row start to account for the 3 bytes at the
start of the table
pshx ;save the row lookup address
tSX ;put the stack pointer in X... we're gonna get some
stuff back.
ldaA 4, X ;load the corrected (minimum applied) map
ldX 0, X ;load the correct row start address
jsr NLF5BC ;do the 2D lookup
psha ;save the result of the 2D call
tSX ;move the stack pointer to X... we're getting stuff
back again.
ldaA 5, X ;limited-applied map
ldaB 4, X ;fractional remainder
staB 5, X ;storing the remainder where limited-applied map
was
ldaB 3, X ;column length from table
ldX 1, X ;This is the previous row lookup address
aBX ;add column length to previous lookup to get next row
jsr NLF5BC ;do the second 2D lookup.
tAB ; a returned the second looked-up value, move it to b
pula ;put the previous row lookup into a
pulx ;x now holding row lookup address
pulx ;x now holding length of table in upper part
;there's really no point to pulling these, the interp
doesn't need them. Stack cleanup.
jsr NLF5CC ;call the interpolation routine
ins ;manipulate the stack
pulx ;restore x to what it was when we called
pulb ;restore b to what it was when we called
rts ;a is holding the looked-up data
----- Original Message ----
From: Rob Handley <Robin at FuryWorld.fsnet.co.uk>
To: gmecm at diy-efi.org
Sent: Thursday, August 23, 2007 5:13:01 PM
Subject: Re: [Gmecm] $58 F29/F29E VE lookup weirdness
My approach was to remove the 4000 RPM check limit code and the logic which
uses the F29E table and F30 array, and add 6 more rows to F29, to take it
from 4000 up to 6400. This makes it 15 x 9. I didn't spot a bug in the table
look up code, but I only worked through it with one set of values - to make
it easier. I found it tough going!
I'd be interested to know if the bug would affect my 15 x 9 table. I note
that F1 is 14 x 17 and F2 is 15 x 5. Are these affected? I think, given that
my engine is N/A and I'm only using a 1 BAR MAP sensor, 9 MAP columns is
probably not so bad. I can't imagine where you found space for a 16 x 32
table!
Thanks,
Rob
----- Original Message -----
From: "Dig" <turbodig at yahoo.com>
To: <gmecm at diy-efi.org>
Sent: 23 August 2007 21:47
Subject: Re: [Gmecm] $58 F29/F29E VE lookup weirdness
The problem there becomes the size of the table. There's a bug in the 3d
table lookup that fouls up lookups over a certain size.
Our F29x is 16x32.
Dig
-----
BTW: If I've got it right, conversion of the code to a version of _F29_ that
goes up to 6400 is just a case of NOPing out some lines and using a hex
editor to set up the extended part of _F29_. If it ever stops raining, I
hope to test this out...
Thanks,
Rob
----- Original Message -----
From: "Dig" <turbodig at yahoo.com>
To: <gmecm at diy-efi.org>
Sent: 23 August 2007 17:22
Subject: Re: [Gmecm] $58 F29/F29E VE lookup weirdness
Sort of a well-known bug... The ALDL stream is reporting erroneous data.
It doesn't seem to be real; there is no corresponding fuel hit that I've
ever observed.
I haven't as yet found the cause, but I suspect it has to do with the timing
of the routine involved in sending data and the fuel routine.
It's on our "to do" list for code59.
----- Original Message ----
From: Rob Handley <Robin at FuryWorld.fsnet.co.uk>
To: gmecm at diy-efi.org
Sent: Wednesday, August 22, 2007 2:35:22 PM
Subject: Re: [Gmecm] $58 F29/F29E VE lookup weirdness
Tried it with a code modification to provide a hard-wired 'MAP' value to use
in the F29 look up, and the look up routine still regularly returned zero!
Robin
----- Original Message -----
From: "Rob Handley" <Robin at FuryWorld.fsnet.co.uk>
To: <gmecm at diy-efi.org>
Sent: 22 August 2007 09:03
Subject: [Gmecm] $58 F29/F29E VE lookup weirdness
> I've been looking at VE for the last few days and, after putting test
> values in F29, F29E, and F30 I spotted the VE regularly (every ~6 secs)
> reverting to the F30 only value. Looking back at one of last year's logs
> this was happening then too. It also happens with the ignition on and the
> engine not running !
>
> Has anybody seen this or have any suggestions why the table look up (as
> used for F29 and F29E) should be returning zero every now and then? I find
> the table look up code hard to follow.
>
> Robin
More information about the Gmecm
mailing list